История успеха Netflix и Облачная Java-платформа

Облачная Java-платформа компании NetflixНа сегодняшний день 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.

Первым пунктом в нашем путешествии станет усвоение понятий и концепций, которые будут использоваться во всей книге для описания хода создания и прак­тического применения облачных приложений.

Вас заинтересует / Intresting for you:

Надежды, связанные с платформо...
Надежды, связанные с платформо... 1405 просмотров Илья Дергунов Thu, 27 Sep 2018, 12:34:48
Версии операционной системы Ci...
Версии операционной системы Ci... 111 просмотров Валерий Павлюков Wed, 09 Oct 2019, 17:24:12
Подключение и настройка сетево...
Подключение и настройка сетево... 270 просмотров Doctor Sat, 11 May 2019, 08:32:20
Способы подключения сетевых ка...
Способы подключения сетевых ка... 255 просмотров Doctor Sat, 11 May 2019, 08:40:23