На сегодняшний день Netflix — один из самых крупных в мире потоковых медиасервисов по требованию, эксплуатирующий свои онлайн-сервисы в облаке. Компания была основана в 1997 году в Скоттс-Валли, штат Калифорния, Ридом Хастингсом (Reed Hastings) и Марком Рэндольфом (Marc Randolph). Изначально Netflix предоставляла интернет-сервис по прокату DVD, позволявший клиентам вносить фиксированную ежемесячную плату за подписку на не ограниченные прокатные видео без дополнительной платы. Клиенты получали DVD по почте после выбора их изображения из списка и помещения в очередь с помощью сайта Netflix.
В 2008 году компания пережила серьезное повреждение своей базы данных, помешавшее доставке DVD клиентам. В те времена Netflix уже приступила к развертыванию сервисов потокового видео, предназначенных для обслуживания клиентов. Команда, занимавшаяся в Netflix потоковым видео, поняла, что аналогичный отказ в их сфере услуг подорвет будущее их бизнеса. В результате в компании было принято важное решение: нужно переходить к другому способу разработки и сопровождения ПО, гарантирующему постоянную доступность их сервисов клиентам.
Частью решения Netflix по предотвращению сбоев ее интернет-сервисов стал отход от вертикально масштабируемой архитектуры и единых точек отказов. Такая позиция была вызвана повреждением базы данных в результате использования вертикально масштабируемой реляционной базы данных. Компания переместила данные клиентов в распределенную базу данных NoSQL, а именно в проект Apache Cassandra с открытым кодом. Это было началом становления Netflix в качестве компании «облачного направления», запускающей все свои программные приложения в виде отказоустойчивых облачных сервисов с высокой степенью распределения. Netflix решила повысить надежность своих интернет-сервисов, добавляя избыточность к своим приложениям и базам данных в масштабируемой модели инфраструктуры.
Частично решение компании по переходу в облако потребовало переноса развертывания больших приложений на системы с высокой степенью распределенности. При этом специалисты компании столкнулись с серьезной проблемой: командам Netflix при переходе от собственного дата-центра к использованию публичного облака пришлось заниматься перепроектированием своих приложений. В 2009 году компания приступила к переходу на Amazon Web Services (AWS) и сконцентрировалась на достижении трех основных целей: масштабируемости, производительности и доступности.
В начале 2009 года стало ясно, что спрос резко возрастает. Известен такой факт: Юрий Израилевский (Yury Izrailevsky), вице-президент по проектированию облачных вычислений и платформ (Cloud and Platform Engineering) компании Netflix, на презентации в рамках конференции AWS reflnvent, состоявшейся в 2013 году, сказал, что спрос с 2009 года возрос в 100 раз. «Мы не смогли бы справиться с масштабированием наших сервисов, если бы пользовались своим внутренним решением», — сказал Израилевский.
Кроме того, он заявил, что преимущества масштабируемости в облаке на фоне его быстрого глобального расширения стали еще более очевидными. Израилевский сказал: «Чтобы сократить время ожидания для наших европейских клиентов, мы запустили второй облачный район в Ирландии. На развертывание нового
дата-центра на другой территории ушло бы много месяцев и миллионы долларов. Это были бы громадные вложения».
Как только Netflix начала размещать свои приложения на Amazon Web Services, сотрудники стали делиться впечатлениями в блоге компании. Многие поддерживали переход к новой архитектуре, сконцентрированной на горизонтальной масштабируемости на всех уровнях стека ПО.
Джон Цианкутти (John Ciancutti), занимавший тогда должность вице-президента технологий персонализации (Personalization Technologies) компании Netflix, в конце 2010 года выложил в блог сообщение, что «облачная среда идеально подошла для горизонтально масштабируемых архитектур. Нам не нужно гадать на месяцы вперед, какими будут наши потребности в оборудовании, хранилище и сетевой аппаратуре. Мы можем практически мгновенно программным способом получить доступ к большему объему этих ресурсов из общих пулов в Amazon Web Services».
Под возможностью «программного доступа» к ресурсам Цианкутти подразумевал, что разработчики и операторы сопровождения могут получить программный доступ к конкретным API управления, открываемым Amazon Web Services с целью предоставить клиентам средства управления для подготовки виртуализированной вычислительной инфраструктуры. RESTful API позволяют разработчикам создавать приложения, управляющие виртуальной инфраструктурой и подготавливающие ее для их основных приложений.
Слоеный пирог, показанный на рис. 1, изображает параметры облака, характеризуемые различными уровнями абстракции.
Рис. 1. Стек облачных вычислений
Предоставление управленческих услуг для управления виртуализированной вычислительной инфраструктурой — одна из основных концепций облачных вычислений и называется инфраструктурой как услугой (Infrastructure as a Service), чаще всего обозначаемой IaaS.
В той же публикации в блоге Цианкутти признался, что Netflix не всегда удавалось правильно спрогнозировать рост клиентуры или объемы привлечения дополнительного оборудования. Эта тема выходит на первый план для компаний, ориентированных на использование облачных технологий. В силу своих особенностей облачные технологии формируют сознание, допускающее невозможность надежных предсказаний того, где и когда понадобятся дополнительные объемы ресурсов.
На презентации, проводимой Юрием Израилевским в рамках конференции AWS re:Invent, состоявшейся в 2013 году, было сказано, что «в облаке в случае повышения объема трафика емкость хранилища можно поднять за считаные дни. Начинать можно с малых объемов, постепенно увеличивая их по мере роста трафика».
Далее он заявил: «По мере превращения нашей компании в транснациональную мы пользовались преимуществами того, что могли положиться на несколько областей присутствия Amazon Web Services по всему миру с целью дать нашим клиентам превосходные ощущения интерактивности независимо от их местонахождения».
Экономия на масштабировании, предопределившая успешное распространение AWS по всему миру, также принесла пользу и компании Netflix. По мере того как для AWS расширялись зоны доступности за счет регионов за пределами США, Netflix получала возможность распространять свои сервисы по всему миру, задействуя только те API управления, которые предоставлялись AWS.
Израилевский процитировал главный аргумент, высказываемый по поводу внедрения облачных вычислений в корпоративные информационные технологии: «Конечно, облако — это замечательно, но слишком дорого для нас». Его ответом на него стало следующее заявление: «В результате перехода Netflix на облачные технологии стоимость операций упала на 87 %. Наши затраты составляют одну восьмую от того, что нам приходилось тратить на содержание дата-центра».
Израилевский объяснил далее, почему облако дало такую экономию: «Из возможности роста, не беспокоясь о емкости буферной памяти, мы извлекаем реальную пользу. По мере роста мы можем проводить масштабирование, соответствующее нашим потребностям».
Микросервисы
В этой книге вопрос микросервисов будет рассматриваться много раз. Хотя книга не посвящена исключительно микросервисам, вы еще не раз сможете убедиться в том, что приложения, оптимизированные для работы в облачной среде, и микросервисы идут рука об руку. Один из основных замыслов, положенных в основу создания микросервисов, заключается в возможности организации как самих команд разработчиков функций, так и приложений вокруг конкретных бизнес-возможностей. Этот подход никоим образом не претендует на особую новизну. Создание системы из небольших распределенных компонентов, хорошо взаимодействующих и раздробленных таким образом, чтобы свести к минимуму все мешающее вводу отдельных функций в эксплуатацию, было доступно уже многие десятилетия. Почему же об этом говорится сейчас? Почему такая разновидность архитектуры приобрела популярность именно в настоящее время? Может ли это иметь какое-то отношение к облаку?
Создание ПО всегда давалось с трудом. Разница между разумными действиями и простой работой зачастую есть результат того, что кто-то другой избавляет вас от ваших собственных неудачных решений. Технические решения, принятые вчера, помешают принятию правильных архитектурных решений завтра. Теперь не секрет: всем нам хочется начать все с чистого листа — tabula rasa — и микросервисы предоставляют способ взять неудачные вчерашние решения и разложить их на новые и, надеемся, лучшие варианты на завтра.
Легко понять что-нибудь небольшое, но гораздо труднее осмыслить влияние его отсутствия. Если детально исследовать качественно спроектированное монолитное приложение, то можно заметить те же стремления к достижению модульности, простоты и слабой связанности, которые наблюдаются в сегодняшних архитектурах микросервисов. Конечно, одно из главных отличий — последовательность событий. Нетрудно понять, как наслоения предпочтений превратили удачную конструкцию в большое и ужасное месиво. Если кто-то принял неудачное решение в отношении одного небольшого сменного блока архитектуры, то этот вариант со временем можно будет просто разбить на части. Но если тот же самый человек привлекался к работе над множеством отдельных модулей качественно спроектированного монолита, то дополнительная предыстория способна позже отрицательно повлиять на чью-либо возможность выбора желаемых решений. Поэтому мы вынуждены идти на компромисс и принимать не самые удачные решения, исходя из скудного выбора, возможность предопределения которого нам никогда не предоставлялась.
ПО, предназначенное для внесения изменений, становится подобием живого существа, которое всегда преобразуется под влиянием последовательности событий и никак не застраховано от ветров перемен в вопросах выживания. Как следствие, мы вынуждены выстраивать процесс создания с учетом будущих изменений. Мы обязаны принимать изменения, сопротивляясь при этом побуждению использовать архитектуру с заделом на будущее. В конечном счете готовность к предстоящим изменениям — генеральный план, преподносимый как адаптивная разработка. Неважно, насколько нам удастся проявить прозорливость в вопросах согласованных упреждающих усилий по созданию совершенной системы. Мы не сможем с высокой степенью надежности предсказать, как характер ее работы изменится впоследствии, так как зачастую от нас абсолютно ничего не зависит. Судьбу продукта, как правило, решает рынок. Поэтому разработку можно вести только с позиции сегодняшнего дня.
Микросервисы в настоящее время не более чем замысел. Модели и приемы создания микросервисов пребывают пока в изменчивом состоянии, продолжая колебаться в разные стороны, в то время как мы терпеливо дожидаемся стабильного определения.
Существует две основные силы, влияющие на скорость архитектурных изменений: микросервисы и облако. Последнее привело к резкому снижению затрат и усилий, необходимых для управления инфраструктурой. Сегодня у нас есть возможность использовать средства самообслуживания для предоставления инфраструктуры нашим приложениям по требованию. С этого момента началось быстрое внедрение новых, инновационных инструментов; и это постоянно побуждает нас переосмыслять и изменять наши предыдущие соглашения. То, что еще вчера было справедливо в отношении создания ПО, сегодня уже может утратить актуальность, и в большинстве случаев истина приобретает весьма туманные очертания. Теперь нужно принимать нелегкие решения на основе трудно предсказуемых предположений о том, что наши серверы являются физическими объектами. Что наши виртуальные машины обладают свойством постоянства. Что наши контейнеры не используют состояния. Наши предположения насчет уровня инфраструктуры находятся под постоянным шквалом атак от бесконечного выбора новых вариантов.
Разбиение монолита на части
Специалисты Netflix ссылаются на два основных преимущества перехода от монолита к архитектуре распределенных систем в облаке: адаптивность и надежность.
До перехода на облачную среду архитектура Netflix включала одно монолитное приложение виртуальной машины Java (Java Virtual Machine, JVM). Хотя развертывание одного большого приложения приносило массу преимуществ, основной недостаток заключался в том, что командам создателей приходилось снижать темпы работы из-за необходимости координировать вносимые ими изменения.
При создании и сопровождении ПО повышение централизованности снижает риск сбоев и повышает затраты на согласование. На координацию уходит время. Чем более централизованной является архитектура приложения, тем больше времени уходит на согласование изменений в любой его части.
Монолитные программы также страдают не слишком высокой надежностью. Когда компоненты задействуют одни и те же ресурсы на той же самой виртуальной машине, сбой в одном из них может распространиться на другие элементы, вызывая простой в работе пользователей. Риск внесения разрушительного изменения в монолит увеличивается с ростом объема усилий, необходимых командам для координации вносимых ими преобразований. Чем больше изменений, вносимых за один цикл выпуска, тем выше риск внесения разрушительного преобразования, вызывающего простой в работе пользователей. Разбивая монолит на мелкие сервисы с узкой специализацией, развертывания могут выполняться с помощью пакетов меньшего объема с циклами выпусков, независимыми от результатов деятельности других команд.
Netflix пришлось изменить не только способ создания и сопровождения своего ПО, но и культуру его организации. Компания перешла к новой модели работы, которая называется Dev Ops. В соответствии с ней каждая команда стала группой, нацеленной на конечный результат, отходя при этом от традиционной структуры группы проектирования. В группе, нацеленной на конечный результат, команды составляли вертикальную структуру, возлагая на себя функции управления производством и сопровождением конечного продукта. У таких команд было все необходимое для создания и сопровождения их ПО.
Netflix OSS
С превращением Netflix в компанию, ориентированную на использование облачной среды, в ней также стали проявлять активность в создании программ с открытым кодом. В конце 2010 года Кевин Макэнте (Kevin McEntee), будучи тогда вице-президентом по системам и электронной торговле (Systems & Ecommerce Engineering), объявил в блоге о грядущей роли компании в разработке ПО с открытым кодом.
Макэнте заявил: «Замечательным качеством проекта с открытым кодом, решающим общую задачу, является то, что он дает импульс своему собственному развитию и долгое время поддерживается действенным циклом непрерывного совершенствования».
В последующие годы компания Netflix перевела в разряд продуктов с открытым кодом более 50 своих внутренних проектов, каждый из которых стал частью бренда Netflix OSS.
Руководящие сотрудники Netflix позже подтвердят желание компании сделать открытым исходный текст многих внутренних инструментов. В июле 2012 года директор по разработке облачных платформ (Director of Cloud Platform Engineering) компании Netflix Руслан Мешенберг (Ruslan Meshenberg) опубликовал в технологическом блоге компании сообщение Open Source at Netflix («Открытый код в Netflix»), где говорилось о том, что она предприняла весьма смелый шаг, переведя в разряд продуктов с открытым кодом столь большой объем своих внутренних инструментов.
Мешенберг написал в блоге, аргументируя принятый курс на открытие исходного кода, что «Netflix была одной из первых компаний, внедривших облачные технологии, переведя все свои потоковые сервисы на работу поверх AWS-инфраструктуры. Нам пришлось расплачиваться за право быть первопроходцами столкновением со множеством вопросов, острых проблем и ограничений, с которыми мы сумели справиться».
Культурная мотивация Netflix на содействие сообществу открытого кода и развитию технологической экосистемы считается тесно связанной с принципами, положенными в основу концепции микроэкономики, известной как экономия за счет масштабов (Economies of Scale). Мешенберг продолжил развивать свою мысль: «Мы увлеклись типовыми решениями, работающими на компонентах нашей платформы и средствах автоматизации... Мы воспользовались эффектами экономии за счет масштабов, проявившимися в результате внедрения таких же типовых решений другими пользователями AWS, и продолжим взаимодействие с сообществом по созданию экосистемы».
В начале того, что было названо облачной эрой, мы видели: ее первопроходцами не были такие высокотехнологичные компании, как IBM или Microsoft, это были компании, возникшие благодаря развитию Интернета. И Netflix, и Amazon запускались в конце 1990-х годов как интернет-компании. Обе начали с предложения интернет-сервисов, нацеленных конкурировать с противниками, занимающимися традиционными формами ведения бизнеса.
Со временем и Netflix, и Amazon превзошли по оценке рыночной стоимости своих конкурентов, придерживавшихся традиционных форм ведения бизнеса. При выходе на рынок облачных вычислений Amazon превратила свой коллективный опыт и внутренние инструменты в набор сервисов. Затем, с опорой на сервисы Amazon, то же самое сделала Netflix. Наряду с этим она перевела в разряд средств с открытым кодом все свои наработки и инструменты. Это превратило Netflix в компанию, ориентированную на использование облачных технологий, основанных на сервисах виртуализированной инфраструктуры, предоставляемой средой AWS компании Amazon. Именно так экономия за счет масштабов привела к революции в индустрии облачных вычислений.
В начале 2015 года в отчетах о доходе за первый квартал компания Netflix отрапортовала о размере своей рыночной стоимости 32,9 млрд долларов. В результате этой новой оценки размер рыночной стоимости Netflix впервые превзошел аналогичный показатель сети CBS.
Облачная Java-платформа
В результате перехода в разряд компаний, ориентированных на применение облачных технологий, Netflix предоставила индустрии разработки ПО свой богатый опыт. В этой книге уроки Netflix и проектов с открытым кодом будут применяться в качестве примеров в двух основных темах:
- создание устойчивых распределенных систем благодаря Spring и Netflix OSS;
- использование непрерывной поставки для обеспечения работы приложений, ориентированных на применение облачной среды, с помощью платформы Cloud Foundry.
Первым пунктом в нашем путешествии станет усвоение понятий и концепций, которые будут использоваться во всей книге для описания хода создания и практического применения облачных приложений.
