Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Питер
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Russisch
Хотите потягаться с гигантами современных облачных технологий? Работать как Amazon, Netflix или Etsy? Ответ очевиден: вам нужна облачная разработка под Java/JVM, позволяющая освоить новейшие технологии, открывающие путь к облакам - в первую очередь, Spring Boot и Cloud Foundry. Всему этому вы научитесь, прочитав фундаментальную книгу "Java в облаке". Вы не только узнаете, как устроены современные облачные технологии для серьезных решений, но и освоите основы микросервисной архитектуры, непрерывной интеграции и доставки, сможете целиком переработать накопившийся унаследованный код и достойно отвечать на самые сложные вызовы, которые ставит перед нами современная Java-экосистема
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 675
Veröffentlichungsjahr: 2022
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Переводчик Н. Вильчинский
Технические редакторы Н. Гринчик, Т. Радецкая, Н. Хлебина
Литературный редактор Н. Хлебина
Художники Н. Гринчик, С. Заматевская , Г. Синякина (Маклакова)
Корректоры Е. Павлович, Т. Радецкая
Верстка Г. Блинов
Джош Лонг, Кеннет Бастани
Java в облаке. Spring Boot, Spring Cloud, Cloud Foundry . — СПб.: Питер, 2018.
ISBN 978-5-4461-0713-1
© ООО Издательство "Питер", 2018
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.
Оглавление
Посвящается Еве и Макани.
С любовью от дяди Джоша
Посвящается моему дедушке Аббасу, который ждал появления своего имени на обложке книги целых сто лет.
Кенни
Предисловие Джеймса Уоттерса
В одну и ту же реку невозможно войти дважды.
Гераклит
Когда летом 2015 года я сидел с Джошем Лонгом в кафе на Венис-Бич, у меня появилось ощущение, что мы находимся на пороге чего-то большого. В то время наша платформа, ориентированная на работу в облачной среде, Pivotal Cloud Foundry, быстро набирала популярность в качестве среды выполнения облачных приложений, и разработчики очень хотели побольше узнать о нашей новой технологии — Spring Boot. В сочетании с набиравшей популярность Spring Boot выход на сцену Spring Cloud обещал произвести настоящий фурор. Я заметил: «Они будут прекрасно сочетаться, и это уже происходит».
К работе были привлечены неимоверные силы. В тот самый момент, когда ИТ-директора отчаянно искали пути повышения производительности труда проектировщиков, среда Spring Boot предлагала микросервисы и вполне приемлемый подход DevOps к разработке корпоративных приложений. Развивающаяся интеграция Spring Boot и PCF превратила развертывание в производственной среде в простой конвейер, API был отозван, Spring Cloud поставила первую в мире сеть микросервисов, и появился стандартный облачный подход к Java.
Изменение в порядке разработки, которое совсем не казалось поверхностным, уникальная комбинация этих технологий изменили структуру поставки продукта большими организациями. Слишком долго разработчикам не удавалось выполнять развертывание в производственной среде из-за эксплуатационной сложности устаревших серверов приложений и шаблонов Java. Нередко можно было услышать мрачные клиентские истории о многодневных развертываниях. Мы знали, что наша платформа изменит жизнь клиентов. После внедрения Spring Boot на PCF они стали присылать нам благодарственные письма с описаниями обновлений в производственной среде, занимающих минуты, а не месяцы.
С 2015 года мы наблюдаем отличные результаты, и организации, перешедшие на эту технологию, отмечают как минимум 50-процентное повышение скорости создания программ, более чем двойное улучшение показателей наработки на отказ и времени простоя при восстановлении после сбоев, а также возможность управления десятками тысяч JVM-машин с небольшими командами обслуживания платформы. Самое главное, что организации, внедрившие технологии, рассмотренные в данной книге, больше времени уделяют решению вопросов, связанных с клиентами и рынками, и существенно меньше времени тратят на переживания по поводу сложностей разработки и сопровождения программ.
Страница за страницей эта книга подробно описывает наиболее важные модели современной разработки корпоративного программного обеспечения (ПО). С большим трудом накопленный Джошем и Кенни практический опыт взаимодействия со многими ведущими предприятиями в сфере производства сквозит во множестве приведенных здесь примеров.
Я призываю каждого проектировщика и ИТ-руководителя, готового воспользоваться всей мощью адаптивности и гибкости в своих организациях, получить удовлетворение от этой работы.
Джеймс Уоттерс (James Watters), первый вице-президент Pivotal Cloud.Foundry, Pivotal, @wattersjames
Предисловие Рода Джонсона
Мы становимся живыми свидетелями одного из самых перспективных преобразований в истории нашей отрасли: перехода от старых архитектур к облаку и от традиционного разделения на разработчиков и операторов к унифицированному понятию DevOps. Задача преобразования решается в данной книге путем объяснения возможностей и проблем написания приложений, ориентированных на работу в облачной среде, и предоставления четкого руководства относительно того, как это делается.
Преобразования не происходят в одночасье. Одна из самых сильных сторон данной книги — ее акцентированность на том, как добраться до облака оттуда, где вы оказались сегодня, опираясь на имеющийся опыт. В частности, в разделе о достижении паритета сервисов предоставляется замечательный материал о том, как перейти от традиционных методов работы к облачным.
Эта книга предлагает выверенный баланс теории и практики, объясняя и принципы построения архитектуры современных приложений, и эффективные, опробованные способы ее реализации. Практика требует выбора не только языка программирования, но и первичной среды с открытым кодом, поскольку современные приложения неизменно создаются с опорой на оправдавшие себя решения, имеющие открытый код. Если ваш выбор пал на язык Java — данная книга для вас.
Слухи о моей смерти сильно преувеличены.
Марк Твен
Несколько лет назад сообщения о «смерти» Java были обычным явлением. Сегодня же Java процветает, и эта книга напомнит вам причину данного явления. Язык Java обрел новую жизнь отчасти потому, что Java-технологии привели к созданию современных приложений, готовых к работе в облачной среде. Двумя решающими факторами стали проекты с открытым кодом Netflix и Spring. В этой книге проделана замечательная работа по охвату обоих факторов.
Первоначально задуманные для упрощения сложностей Java EE минувшей эпохи, основные идеи Spring выдержали испытание временем и отлично зарекомендовали себя применительно к облачным приложениям. Более десяти лет назад мы говорили о Spring-треугольнике: внедрении зависимостей, абстракции переносимых сервисов и AOP. Все это в равной степени актуально и сегодня, когда чистое разобщение бизнес-логики и ее среды стало важнее, чем когда-либо.
Основа данной книги — освещение Spring Boot, нового способа использования Spring в эпоху микросервисов, который сегодня активно внедряется на производствах. Spring Boot упрощает создание новых сервисов Spring любой степени детализации и их развертывание в современной контейнеризированной среде. В то время как традиционное «корпоративное» Java-приложение было монолитным, запускаемым на все еще большом сервере приложений, среда Spring Boot развернула все в сторону упрощения и повышения эффективности: сервис должным образом становится центральной фигурой и развертывается с сервером, обладающим ресурсами, которых вполне хватает для его запуска.
В данной книге рассматривается последняя работа команды Spring — Spring Cloud Stream и усовершенствованная поддержка комплексного тестирования, а также развивающаяся интеграция с проектами Netflix с открытым кодом.
Я рад отметить продолжение нововведений Spring и концентрацию этой среды на упрощении труда проектировщиков. Хотя последние пять лет я работал со средой Spring только в качестве пользователя, мне радостно видеть, как она процветает и побеждает все новые источники сложности. Сегодня я продолжаю решение этой задачи упрощения в среде Atomist, где мы стремимся сделать для команд разработчиков и процесса создания ПО все то, что Spring сделала для приложений Java, предоставляя возможность автоматизировать все важные процессы. Среда Spring обеспечивает простую производительную структуру и абстракцию для работы со всем, чем занимается Java-разработчик. Среда Atomist нацелена на решение тех же задач в отношении исходного кода проекта, построения систем, отслеживания проблем, развернутой среды и т.д. Сюда же включена мощная автоматизация разработки: от создания новых проектов до усовершенствования сотрудничества команд с помощью Slack и отслеживания событий развертывания.
Фундаментальный строительный блок автоматизации — тестирование. В данной книге мне особенно понравилось всестороннее освещение этого процесса, проливающее свет на сложные проблемы, которые касаются тестирования микросервисов. Мне также понравилось наличие большого количества листингов программ, снабженных подробными комментариями.
Приятно писать предисловие для книги, сотворенной друзьями и посвященной любимой мною технологии. Те, кто знаком с Джошем, знают, что он отличный собеседник. Он так же хорош во владении печатным словом, как и в живом программировании. Джош и Кенни — страстные, любознательные и хорошо информированные экскурсоводы, и я с удовольствием путешествую с ними. Я многому научился на этом пути и уверен, что и вам это удастся.
Род Джонсон (Rod Johnson), создатель, генеральный директор Spring Framework, Atomist, @springrod
Введение
Быстрее! Быстрее! Быстрее!!! Всем хочется двигаться быстрее, но не все знают, как этого добиться. Требования рынка растут все быстрее, появляются и новые возможности, но некоторые из нас просто не в состоянии идти в ногу со временем! Чем отличается обычное предприятие от таких, как Amazon, Netflix и Etsy? Нам известно, что эти компании разрослись до неимоверных масштабов и все же каким-то образом сохраняют свое преимущество, опережая конкурентов. Как?
Довести идею от концепции до клиента, понять, что идея превратилась во что-то полезное и ценное, можно, проделав большой объем работы. На своем пути к вводу в эксплуатацию любой продукт проходит через множество различных этапов: доведение пользовательского восприятия до проектировщиков, разработка, тестирование, запуск в производство. Исторически сложилось так, что работа замедлялась на каждом из этих пунктов. Со временем общими усилиями мы оптимизировали различные части процесса. У нас имеются облачные вычисления, поэтому отпала необходимость в многоярусных сервисах. Мы используем разработку на основе тестирования и непрерывную интеграцию, предназначенную для автоматизации проверок. Программы выпускаются в небольших пакетах — микросервисах, что позволяет сократить область изменений и их стоимость. Мы принимаем идеи, заложенные в devops, чтобы способствовать всестороннему охвату системы и чувству товарищества между разработчиками и операторами, сокращая тем самым неоправданные затраты, связанные с рассогласованностью приоритетов. Все собранное вместе и есть то, что мы подразумеваем под облачными технологиями.
Разработчики программных продуктов, являясь специалистами и практиками в своей отрасли, оказались сегодня на перепутье. Существуют надежные, стабильные самообслуживающиеся решения с открытым кодом для инфраструктуры, тестирования, связки, непрерывной интеграции и поставки, сред разработки и облачных платформ. Эти элементы позволяют организациям сосредоточиться на менее затратной поставке ценностей более высокого порядка и в более широком масштабе.
Для кого эта книга
В основном данная книга предназначена для разработчиков Java- и JVM-машин, которые ищут способы создания более качественного ПО в короткие сроки с помощью Spring Boot, Spring Cloud и Cloud Foundry. Она для тех, кто уже слышал шум, поднявшийся вокруг микросервисов. Возможно, вы уже поняли, на какую стратосферную высоту взлетела среда Spring Boot, и удивляетесь тому, что сегодня предприятия используют платформу Cloud Foundry. Если так и есть, то эта книга для вас.
Зачем мы ее написали
В компании Pivotal мы помогаем клиентам превращать их компании в передовые организации цифровых технологий, обучая их непрерывной поставке и применению Cloud Foundry, Spring Boot и Spring Cloud. Мы видим, что срабатывает (а что — нет), и хотим зафиксировать состояние дел, как это определено нашими пользователями, и поделиться своим опытом. Мы не претендуем на всесторонний охват, но при этом стараемся затронуть ключевые понятия — те области мира облачных вычислений, в которых вы собираетесь работать, и дать о них ясное представление.
Структура книги
Книга имеет следующую структуру:
• в главах 1 и 2 рассказывается, чем хорошо «облачное» мышление, а затем предоставляется краткий экскурс в Spring Boot и Cloud Foundry;
• в главе 3 представлены способы конфигурации приложения Spring Boot; позже на этот навык мы будем опираться повсеместно;
• в главе 4 рассматриваются способы тестирования Spring-приложений, от самых простых компонентов до распределенных систем;
• в главе 5 описана незначительная реструктуризация, которую можно выполнить для перемещения приложения на такую облачную платформу, как Cloud Foundry, что позволит получить ряд ценных свойств от самой платформы;
• в главе 6 освещается вопрос создания HTTP- и RESTful-сервисов с помощью среды Spring; большей частью это будет делаться в API и в мире, ориентированном на предметную область;
• в главе 7 представлены общие способы контроля точек выдачи и поступления запросов в распределенных системах;
• в главе 8 описаны способы создания сервисов, действующих в качестве первого порта вызова для запросов, поступающих из внешнего мира;
• в главе 9 рассматриваются способы управления данными в среде Spring с помощью Spring Data, тем самым закладываются основы для мышления с прицелом на ориентацию в предметной области;
• в главе 10 изучаются методы интеграции распределенных сервисов и данных с использованием имеющейся в среде Spring архитектуры, управляемой событиями и ориентированной на рассылку сообщений;
• в главе 11 описаны способы применения возможностей масштабирования такой облачной платформы, как Cloud Foundry, для того, чтобы справиться с долговременными рабочими нагрузками;
• в главе 12 освещаются некоторые способы управления состоянием в распределенных системах;
• в главе 13 рассматриваются методы создания систем, поддерживающих отслеживаемость и оперативное реагирование;
• в главе 14 изучаются способы создания сервис-брокеров для платформ, подобных Cloud Foundry; сервис-брокеры подключают к облачной платформе такие сохраняющие состояние сервисы, как очереди сообщений, базы данных и блоки кэш-памяти;
• в главе 15 описаны творческие идеи, заложенные в непрерывную поставку. Это, может быть, и последняя глава, но для вас это всего лишь начало вашего путешествия.
Если вы похожи на нас, то не станете читать книгу от корки до корки. Если вы действительно похожи на нас, то, скорее всего, вообще не станете читать введение. Однако предположим, что вы видите эти строки. На такой случай хотим дать упреждающие советы.
• Чем бы вы ни занимались, прочтите главы 1 и 2. Они заложат основы для усвоения всего остального материала.
• В главах с 3-й по 6-ю вводятся такие понятия, которые должен знать любой проектировщик, работающий со средой Spring. Они актуальны как для прежних, так и для новых Spring-приложений. Фактически глава 5 посвящена вопросам превращения старых приложений (как ориентированных на использование среды Spring, так и не ориентированных на это) в новые приложения.
• В главах 7 и 8 вводятся понятия, применяющиеся в микросервисных системах, основанных на использовании протокола HTTP, например безопасность и маршрутизация.
• В главах с 9-й по 12-ю дается материал, помогающий лучше справляться с управлением и обработкой данных в распределенных системах.
• В главе 13 фактически изложена основная концепция, которая должна была быть освещена в этой книге значительно раньше, при рассмотрении ключевых концепций и тестирования, если не принимать во внимание тот факт, что она зависит от технических концепций, которые ранее не вводились. Эксплуатируемые приложения должны быть отслеживаемыми. Эту главу следует прочитать как можно раньше. Для ее понимания достаточно знания основ. Или же перечитайте ее еще раз, добравшись до нее обычным порядком.
• В главе 14 рассматривается вопрос использования Spring, среды разработки облачных приложений, с целью создания компонентов для платформ, для облака. Материал, описанный в данной главе, прежде всего приобретает остроту в свете усилий открытых сервис-брокеров.
• И наконец, в главе 15 уточняются вопросы, связанные с непрерывной поставкой. Вся эта книга написана в понятиях непрерывной поставки, и последний раздел имеет такую фундаментальную значимость для всего, что мы стараемся сделать, что мы вынесли рассмотрение данного вопроса в заключение. Прочитайте эту главу одной из первых, а затем перечитайте ее в последнюю очередь.
Интернет-ресурсы
В Интернете имеется множество превосходных ресурсов, которые помогут продолжить ваши исследования и будут содействовать в работе:
• в GitHub-репозитории (https://github.com/cloud-native-java/) можно найти код для данной книги;
• сайт Spring (https://spring.io/) может послужить для вас универсальным магазином для всего, что касается Spring, включая документацию, форум технических вопросов и ответов и др.;
• сайт Cloud Foundry (https://www.cloudfoundry.org/) — центр притяжения той работы, которая проделана всеми соавторами учреждения Cloud Foundry. Здесь вы найдете видеоклипы, учебники, сводки новостей и др.
Условные обозначения
В этой книге используются следующие условные обозначения.
Курсив
Курсивом выделены новые термины и слова, на которых сделан акцент.
Моноширинный шрифт
Применяется для листингов программ, а также внутри абзацев, чтобы обратиться к элементам программы вроде переменных, функций и типов данных. Им также выделены имена и расширения файлов.
Полужирный моноширинный шрифт
Показывает команды или иной текст, который пользователь должен ввести самостоятельно.
Курсивный моноширинный шрифт
Показывает текст, который должен быть заменен значениями, введенными пользователем, или значениями, определяемыми контекстом.
Шрифт без засечек
Служит для указания URL, адресов электронной почты.
Этот рисунок указывает на совет или предложение.
Этот рисунок указывает на общее замечание.
Этот рисунок указывает на предупреждение.
Использование примеров кода
Загрузить дополнительные материалы (примеры кода, упражнения и т.д.) можно с сайта http://github.com/Cloud-Native-Java.
Книга нацелена на оказание помощи в решении практических задач. В целом, если пример кода предлагается вместе с книгой, то его можно использовать в ваших программах и документации. Вам не нужно обращаться к нам за разрешением, кроме тех случаев, когда вы воспроизводите весьма существенный объем кода. Например, написание программы, задействующей несколько фрагментов кода из этой книги, не требует разрешения, в отличие от продажи или распространения компакт-диска с примерами из книг издательства O’Reilly. Ответы на вопросы с цитированием материала данной книги и приведением примеров кода разрешения не требуют, чего не скажешь о вставке существенного объема примеров кода из этой книги в документацию по вашему программному продукту.
Если есть сомнения по поводу правомерности использования примеров кода в рамках вышеизложенного, вы можете свободно обратиться к нам за консультацией по адресу [email protected].
Благодарности
Прежде всего хочется поблагодарить наших невероятно терпеливых и участливых редакторов из O’Reilly: Нана Барбера (Nan Barber) и Брайана Фостера (Brian Foster).
Спасибо всем рецензентам и тем, кто нас вдохновлял, снабжал аналитическими выводами и идеями. Хочется выразить компании Pivotal и в целом всей ее экосистеме огромную признательность за поддержку. Особая благодарность каждому рецензенту, предоставившему технические отзывы, среди которых Брайан Дюссо (Brian Dussault), доктор Дэйв Сиер (Dave Syer), Эндрю Клей Шафер (Andrew Clay Shafer), Роб Уинч (Rob Winch), Марк Фишер (Mark Fisher), доктор Марк Поллак (Mark Pollack), Уткарш Надкарни (Utkarsh Nadkarni), Сабби Анандан (Sabby Anandan), Майкл Хангер (Michael Hunger), Бриджит Кромхаут (Bridget Kromhout), Расс Майлз (Russ Miles), Марк Хеклер (Mark Heckler), Мартен Дейнум (Marten Deinum), Натаниэль Шутта (Nathaniel Schutta), Патрик Крокер (Patrick Crocker) и многие другие. Спасибо вам!
И последними в списке, но не последними по значению хотелось бы поблагодарить Рода Джонсона и Джеймса Уоттерса. Вы проявили щедрость, не будучи ничем нам обязанными; вы дали нам все. Огромное вам спасибо за ваши предисловия, отзывы и напутствия.
Эта книга была написана с помощью инструментария Asciidoctor, разработанного под руководством Дэна Аллена (Dan Allen) (https://twitter.com/mojavelinux) и Сары Уайт (Sarah White) (http://twitter.com/carbonfray) из OpenDevise. Управление исходным кодом всех примеров выполняется в открытых хранилищах GitHub (https://github.com/). Код постоянно интегрировался в Travis CI (https://travis-ci.org/cloud-native-java). Компоненты сборок хранились и управлялись в личной учетной записи хранилища Artifactory, любезно предоставленной нам JFrog (https://jfrog.com/). Все примеры запускались на Pivotal Web Services, где располагался экземпляр Cloud Foundry, управляемый Pivotal. Эти инструменты, без которых написание данной книги было бы сильно затруднено, относятся либо к программам с открытым кодом, либо запускаются сообществом единомышленников, не вынуждая нас ни к каким затратам. Огромное вам спасибо! Надеемся, что вы их присмотрите для своих следующих проектов и поддержите их, как они поддержали нас.
Теперь обращаемся к команде Spring (https://spring.io/team) и командам Cloud Foundry (https://www.cloudfoundry.org/): большое спасибо за весь созданный и протестированный вами код, которым нам не пришлось заниматься.
Джош Лонг
Хочу поблагодарить моего соавтора Кенни за то, что стал моим попутчиком в этом путешествии! Хочу выразить благодарность коллективу издательства O’Reilly за возможность работать с ними и за их невероятное терпение в условиях поджимающих сроков и нашего карабканья вверх в стремлении удержаться на вершине постоянно разрастающейся экосистемы Pivotal. Спасибо доктору Дэйву Сиеру (Dave Syer) (https://twitter.com/david_syer) за добрые слова о книге и за то, что он был моим вдохновителем. Меня носило по городам, часовым поясам, странам и континентам, а команды Spring и Cloud Foundry в Pivotal неизменно проявляли поддержку, независимо от дня или часа, — спасибо вам!
Кенни Бастани
В первую очередь хочу поблагодарить моего друга, наставника и коллегу Майкла Хангера (Michael Hunger), он был первым, кто привил мне страсть к написанию и обсуждению программ с открытым кодом. Хочу сказать спасибо и моему безмерно талантливому соавтору Джошу Лонгу (Josh Long), пригласившему меня поработать с ним над этой книгой, в то время как я запустил в эксплуатацию свои первые микросервисы Spring Boot более двух лет назад. Совместная работа над книгой была для меня невероятным приключением. С того времени как нашими совместными с Джошем усилиями на бумагу легли первые слова, мы увидели, что среда Spring Boot разрослась и стала одним из наиболее успешных когда-либо созданных проектов с открытым кодом. Сегодня рост ее популярности представлен почти 13 миллионами скачиваний в месяц, сочетанием новых приложений и непрерывного потока производственных развертываний. Достижением этого успеха команда Spring Engineering обязана 50 штатным инженерам. При этом скромном количестве специалистов Spring поддерживает более 100 проектов с открытым кодом, в числе которых компоненты среды, образцы приложений и документация, и все это под крылом любезного спонсора — компании Pivotal. Все, что достигнуто нами в данной книге, не было бы возможным без невероятной самоотверженности разработчиков, которые в настоящее время ежегодно создают около трех миллионов новых приложений Spring Boot, готовых к работе в производственной среде.
С 2004 по 2017 год только в рамках проекта Spring Framework 381 Java-разработчик открытого кода внес 36 412 зафиксированных изменений, что составляет примерно 339 лет объединенных трудозатрат.
Часть I. Основы
1. Приложение, оптимизированное для работы в облачной среде
Приемы разработки программного обеспечения как в составе команд, так и в индивидуальном порядке постоянно совершенствуются. Разработка программ с открытым кодом обеспечила производство ПО чем-то похожим на Кембрийский взрыв инструментов, сред программирования, платформ и операционных систем, и все это сопровождается растущим вниманием к гибкости и автоматизации. Основная масса современного наиболее популярного инструментария с открытым кодом сфокусирована на функциональных особенностях, позволяющих командам разработчиков безостановочно поставлять программное обеспечение как никогда ранее быстрыми темпами, на любом уровне, от создания до практического применения.
История компании Amazon
В течение двух десятилетий, с начала 1990-х годов, книжный интернет-магазин Amazon.com со штаб-квартирой в Сиэтле превратился в крупнейшее в мире предприятие данного профиля. Теперь эта компания, известная в наши дни просто как Amazon, продает гораздо более широкий ассортимент товаров. В 2015 году Amazon превзошла по объему торговли компанию Walmart — наиболее заметного розничного торговца в США. Самая интересная часть истории беспрецедентного роста Amazon может быть сведена к одному вопросу: каким образом сайт, начинавшийся с простого книжного интернет-магазина, превратился в одного из мировых гигантов розничной торговли, не открыв при этом ни одной торговой точки?
Нетрудно было заметить, что мир торговли переместился и выстроился вокруг цифровых коммуникаций, чему поспособствовал бурный рост возможностей подключения к Интернету в любых уголках планеты. По мере уменьшения размеров персональных компьютеров и их превращения в повсеместно используемые в наши дни смартфоны, планшеты и часы мы стали свидетелями грандиозного роста доступности каналов распространения, преобразивших способы ведения торговли по всему миру.
Техническим развитием компании Amazon от весьма успешного книжного интернет-магазина до одной из наиболее влиятельных технологических компаний в мире, занимающихся розничной торговлей, управлял ее технический директор Вернер Фогельс (Werner Vogels). В июне 2006 года Фогельс дал интервью компьютерному журналу ACM Queue по вопросу быстрой эволюции технологий, которая привела к взлету компании Amazon. В нем директор рассказал об основном движущем факторе этого прогресса.
В основном техническое развитие Amazon.com обуславливалось обеспечением непрерывного роста, чтобы при исключительно высокой масштабируемости сохранялись доступность и производительность.
Вернер Фогельс. A Conversation with Werner Vogels, ACM Queue 4, № 4 (2006): 14–22
Фогельс продолжает утверждать, что компании Amazon для достижения высокой масштабируемости понадобился переход к другой структуре архитектуры ПО. Он напомнил, что сначала Amazon.com использовала монолитное приложение. Со временем, по мере того как над одним и тем же приложением стало трудиться все больше и больше команд, границы принадлежности кода стали размываться. «Отсутствие изолированности привело к отсутствию четко выраженной принадлежности», — сказал Фогельс.
Фогельс отметил, что совместно используемые ресурсы, такие как базы данных Vogels, затрудняют расширение всего бизнеса. Чем больше объем совместно применяемых ресурсов, будь то серверы приложений или базы данных, тем слабее контроль за работой при вводе компонентов программ в эксплуатацию.
Вы создаете этот продукт, вам и обслуживать его работу.
Вернер Фогельс, технический директор компании Amazon
Фогельс затронул общую тему, имеющую отношение и к приложениям, оптимизированным для работы в облачной среде: команды должны быть владельцами того, что они создают. Далее он сказал: «Традиционная модель заключается в следующем: ПО перетаскивается через барьер, отделяющий создание от практического применения, работа над ним прекращается, после чего о нем забывают. Но это не про Amazon. Вы создаете этот продукт, вам и обслуживать его работу».
Слова, которые чаще всего цитировались основными докладчиками на отдельных ведущих конференциях по программному обеспечению («вы создаете этот продукт, вам и обслуживать его работу»), позже стали слоганом популярного движения, известного сегодня просто как DevOps.
Ряд приемов, о которых говорил Фогельс в 2006 году, дал начало многим популярным движениям в области разработки ПО, ныне процветающим. Можно установить связь таких подходов, как DevOps и разработка микросервисов, с идеями, высказанными Фогельсом более десяти лет назад. Идеи, аналогичные этим, вырабатывались в крупных интернет-компаниях, подобных Amazon, однако на создание соответствующих инструментов, позволяющих добиться их развития и становления в виде предложения конкретных услуг, ушло бы немало лет.
В 2006 году в Amazon был запущен новый продукт под названием Amazon Web Services (AWS). Идея, положенная в его основу, заключалась в предоставлении платформы, аналогичной той, что использовалась внутри Amazon, и выпуске ее в виде сервиса для открытого применения. Компания была заинтересована в развитии идей и инструментов, на которых основывалась эта платформа. Многие из выдвинутых Фогельсом идей уже были внедрены в платформе Amazon.com; выпуская платформу в качестве сервиса для открытого использования, компания стремилась выйти на новый рынок, названный публичным облаком.
Были озвучены идеи, положенные в основу этого облака. Виртуальные ресурсы могут предоставляться по требованию, при этом исключается необходимость беспокоиться относительно основной инфраструктуры. Разработчики могут просто арендовать виртуальную машину для размещения своих приложений, не нуждаясь в приобретении инфраструктуры или в управлении ею. Такой прием представлял собой вариант самообслуживания с низкой степенью риска, повышающий привлекательность публичного облака с технологией AWS, прокладывающей путь к внедрению.
Пройдут годы, прежде чем технология AWS превратится в полноценный набор сервисов и шаблонов для создания и запуска приложений, написанных для работы в публичном облаке. Хотя для создания новых программ к инжинирингу этих сервисов было привлечено множество разработчиков, многие компании с уже существующими приложениями по-прежнему испытывают сложности с переходом на новые технологии. Имеющиеся у них программы были созданы без расчета на переносимость. К тому же многие приложения все еще зависят от устаревших разработок, несовместимых с публичным облаком.
Чтобы самые крупные компании воспользовались публичным облаком, им нужно внести изменения в способ разработки их приложений.
Надежды, связанные с платформой
Платформа воспринимается сегодня как избитое понятие.
Когда речь заходит о платформах в компьютерном деле, чаще всего имеется в виду набор возможностей, помогающих либо создавать, либо запускать приложения. Лучше всего платформы обобщаются по требованиям, которые предъявляются к способам, используемым разработчиками при создании приложений.
Платформы позволяют автоматизировать решение задач, не играющих существенной роли в поддержке бизнес-требований, предъявляемых к приложению. Это помогает командам разработчиков действовать оперативно, позволяя поддерживать только функциональные компоненты, имеющие особую ценность для делового применения.
Та команда, которая написала сценарии оболочки либо наштамповала контейнеры или виртуальные машины для автоматизации разработки, уже создала своеобразную платформу. Вопрос заключается в следующем: что может дать эта платформа, каким ожиданиям соответствует? Какой объем работы потребуется для поддержки основных (или даже всех) требований для непрерывной поставки нового ПО?
При построении платформ создается инструмент, автоматизирующий набор повторяющихся приемов; последние складываются из набора требований, которые превращают ценные идеи в план.
•Идеи: каковы основные замыслы платформы и в чем их ценность?
• Требования: каковы требования, соблюдение которых необходимо для превращения наших идей в приемы?
• Приемы: как автоматически перевести требования в набор повторяющихся приемов?
В основу любой платформы закладываются простые идеи, которые в случае их реализации повышают дифференцированную деловую ценность за счет использования автоматизированного инструментария.
Возьмем, к примеру, платформу Amazon.com. Вернер Фогельс заявил: «Повышая изолированность компонентов программ друг от друга, команды будут иметь больше возможностей контроля тех функций, которые вводятся ими в производство».
Идея
Повышение изолированности компонентов программ друг от друга позволяет доводить части системы до практического применения независимо и в более сжатые сроки.
Закладывая эту идею в основу платформы, мы получаем возможность сформировать из нее набор требований. Они принимают форму взгляда на то, как основная идея будет воплощена на практике при автоматизации. Следующие утверждения представляют собой категоричные требования к способам повышения изолированности компонентов.
Требования
•Компоненты программ должны разрабатываться в виде независимо развертываемых сервисов.
• Вся бизнес-логика в сервисе инкапсулируется с теми данными, с которыми она работает.
• За пределами сервиса не должно быть прямого доступа к базе данных.
• Сервисы должны предоставлять веб-интерфейс для обращения к их бизнес-логике со стороны других сервисов.
На основе этих требований складывается весьма категоричный взгляд на приемы усиления изолированности компонентов программы. Обещания, связанные с выполнением приведенных требований в виде автоматизированных механизмов, сулят командам предоставление более действенного контроля над функциями, поставляемыми для эксплуатации. Следующим шагом станет описание того, как эти требования могут быть сведены к набору повторяющихся приемов.
Приемы, выведенные исходя из этих требований, должны быть заявлены в виде коллекции обещаний. Указывая приемы в виде обещаний, мы задаем ожидания пользователей платформы относительно способов, которые они могут задействовать при создании и эксплуатации своих приложений.
Приемы
•Командам предоставляется интерфейс самообслуживания, позволяющий обеспечить инфраструктуру, требуемую для функционирования приложений.
• Приложения помещаются в пакет, представляющий собой полный комплект, развертываются в среде с помощью интерфейса самообслуживания.
• Базы данных предоставляются приложениям в виде сервиса и должны вводиться в действие с использованием интерфейса самообслуживания.
• Приложение снабжается всем необходимым для регистрации в базе данных в виде переменных среды, но только после объявления явного отношения к базе данных в виде привязки к сервису.
• Каждому приложению предоставляется сервисный реестр, применяемый в качестве манифеста местоположений внешних сервисных зависимостей.
Каждый из вышеперечисленных приемов принимает форму обещания для пользователя. Таким образом, суть идей, закладываемых в основу платформы, реализуется в виде требований, предъявляемых к приложениям.
В основе приложений, оптимизированных для работы в облачной среде, лежит набор требований, позволяющих сократить время, затрачиваемое на однообразную трудоемкую деятельность.
Когда технология AWS была впервые представлена публике, Amazon не заставляла ее пользователей придерживаться тех же требований, которые применялись в самой компании. Оставаясь верным своему названию Amazon Web Services, сама по себе технология AWS не является облачной платформой, а представляет собой коллекцию независимых инфраструктурных сервисов, из которых может быть составлена автоматическая оснастка, напоминающая платформу обещаний. Спустя годы после первого выпуска AWS компания Amazon начала предлагать коллекцию управляемых сервисов платформы с вариантами использования, начиная от Интернета вещей (IoT, Internet of Things) и заканчивая машинным самообучением.
Если какой-либо компании понадобится создать свою собственную платформу с нуля, время поставки приложений откладывается до полной сборки платформы. Компании, ставшие ранними пользователями AWS, должны были вместе собрать некую разновидность автоматизации, похожую на платформу. Каждой компании пришлось бы выработать набор обещаний, охватывающих основные идеи создания и ввода ПО в эксплуатацию.
Совсем недавно производство ПО ориентировалось на идею существования основного набора общих обещаний, исполняемых каждой облачной платформой. Эти обещания будут исследоваться в нашей книге с применением платформы в виде сервиса (Platform as a Service, PaaS) под названием Cloud Foundry. Основным предназначением последней является предоставление платформы, вбирающей в себя набор общих обещаний, касающихся быстрой разработки и применения приложений. Cloud Foundry дает эти обещания, одновременно сохраняя возможность переносимости между облачными инфраструктурами нескольких различных поставщиков.
Основное внимание в данной книге мы уделим вопросам создания Java-приложений, оптимизированных для работы в облачной среде. В первую очередь это будет касаться инструментов и сред, позволяющих сократить время, затрачиваемое на однообразные трудоемкие действия за счет использования преимуществ и обещаний платформы, оптимизированной для работы в облаке.
Принципы
Новые принципы создания ПО позволяют уделять больше внимания обдумыванию поведения наших приложений в ходе их применения. В совместных усилиях разработчиков и операторов делается более серьезный акцент на понимании характера поведения их приложений в процессе эксплуатации, с меньшим уровнем доверия к тому, как за счет сложности можно разрешить ситуацию при сбое.
Как и в случае с Amazon.com, архитектура ПО начала отходить от крупных монолитных приложений. Теперь основное внимание в вопросах архитектуры уделялось достижению высокого уровня масштабируемости без ущерба для производительности и доступности. Разбивая монолит на компоненты, инженерные организации предпринимали усилия по децентрализации управления изменениями, предоставляя командам больше контроля над тем, как функции вводятся в эксплуатацию. Повышая изолированность между компонентами, команды создателей ПО начали вступать в мир разработки распределенных систем, фокусируясь на написании менее крупных, более специализированных сервисов с независимыми циклами выпуска.
В приложениях, оптимизированных для выполнения в облаке, используется набор принципов, позволяющих командам более свободно оперировать способами ввода функций в эксплуатацию. По мере роста распределенности приложений (в результате повышения степени изолированности, необходимой для предоставления большего контроля над ситуацией командам, владеющим приложением) возникает серьезная проблема, связанная с повышением вероятности сбоя при обмене данными между компонентами приложения. Неизбежным результатом превращения приложений в сложные распределенные системы становятся эксплуатационные сбои.
Архитектуры приложений, оптимизированных для работы в облачной среде, придают этим приложениям преимущества исключительно высокой масштабируемости, притом гарантируя их всеобщую доступность и высокий уровень производительности. Хотя такие компании, как Amazon, пользовались преимуществами высокой масштабируемости в облаке, широко доступного инструментария для создания приложений, оптимизированных для работы в облачной среде, еще не появлялось. В конечном итоге инструменты и платформа будут представлены в виде коллекции проектов с открытым кодом, поддерживаемых первопроходцем в мире открытых облачных вычислений — компанией Netflix.
Масштабируемость
Чтобы ускорить разработку ПО, нужно заранее продумывать возможности масштабирования на всех уровнях. В самом общем смысле масштаб обуславливается издержками, приносящими пользу. Уровень непредсказуемости, сокращающий этот полезный эффект, называется риском. В таких условиях приходится определять границы масштабирования, поскольку создание программ сопряжено с рисками. Риски, заложенные создателями ПО, не всегда известны операторам, то есть тем, кто занимается его эксплуатацией. Выдвигая разработчикам требования по скорейшему вводу функций в дело, мы добавляем риски к процессу эксплуатации этих функций, не испытывая никакого сочувствия к проблемам операторов.
В результате со стороны операторов возрастает недоверие к ПО, произведенному разработчиками. Дефицит доверия между обеими сторонами создает практику обвинений: люди предъявляют друг другу претензии вместо того, чтобы рассматривать системные проблемы, которые привели к возникновению или к ускорению появления проблем, оказывающих отрицательное влияние на ведение дел.
Для снятия напряженности, возникающей в традиционных структурах ИТ-организаций, следует переосмыслить порядок взаимодействия команд, занимающихся поставкой и эксплуатацией ПО. Общение операторов с разработчиками способно влиять на возможность масштабирования, поскольку со временем цели каждой из сторон расходятся. Чтобы добиться успеха в решении данного вопроса, необходимо перейти к более надежному способу разработки ПО, при котором основное внимание внутри процесса создания уделяется опыту команды операторов и который способствует взаимообучению и совершенствованию.
Надежность
Ожидания, возникающие во взаимоотношениях команд (относительно порядка разработки, режима эксплуатации, алгоритма взаимодействия с пользователем и т.д.), выражаются в виде соглашений. Заключаемые командами соглашения подразумевают предоставление или получение определенного уровня услуг. Наблюдая за тем, как команды предоставляют услуги друг другу в процессе создания ПО, можно прийти к более глубокому пониманию того, каким образом отсутствие надлежащего уровня общения способно повлечь возникновение рисков, приводящих к сбоям при дальнейшей совместной работе.
Соглашения об услугах между командами заключаются с целью уменьшить риск неожиданного поведения в общих функциях масштабирования, которые создают ценность для бизнеса. Данные соглашения носят конкретный характер, чтобы гарантировать соответствие поведения ожидаемой стоимости операций. Таким образом, услуги позволяют отдельным частям бизнеса довести до максимальных показателей его общую отдачу. Здесь целью для бизнеса, относящегося к производству ПО, является надежное прогнозирование создания ценности за счет затрат, то есть то, что мы называем надежностью.
Модель услуг для бизнеса — та же самая модель, которая используется при создании ПО. Именно так гарантируется надежность системы, неважно, к чему именно это относится: к программному продукту, производимому для автоматизации бизнес-функции, или к людям, обучаемым выполнению ручных операций.
Адаптивность
Мы начинаем понимать, что больше не существует лишь одного способа разработки и практического применения программного обеспечения. Благодаря внедрению адаптивных методологий и продвижению в направлении к бизнес-моделям ПО как услуги (или сервиса) — Software as a Service (SaaS) — комплект корпоративных приложений становится все более распределенным. Создание распределенных систем — весьма непростая задача. Переход к более распределенной архитектуре приложений обуславливается необходимостью сокращать сроки поставки программ с меньшим риском возникновения сбоев.
Возможно, кто-то воскликнет: «Адаптивность? Она все еще актуальна?» (https://www.linkedin.com/pulse/agile-dead-matthew-kern). Адаптивность в нашем понимании относится как к целостному, общесистемному устремлению к незамедлительной поставке новой ценности, так и к замыслу по поводу быстрого реагирования на смену обстановки. Мы просто говорим о малом — об адаптивности, не касаясь при этом понятий управленческой практики. Существует множество путей, приводящих к эксплуатации продукта, и нас не интересует, какой именно методики управления вы будете придерживаться на своем пути. Главное, вам нужно усвоить, что адаптивность — полезное свойство, а не самоцель.
Современный бизнес, ориентированный на производство ПО, стремится реструктурировать процессы разработки, чтобы получить возможность более быстро внедрять программы и непрерывно вводить приложения в эксплуатацию. Компании хотят увеличить не только скорость разработки программ, но и количество создаваемых и сопровождаемых ими приложений, чтобы обслуживать различные бизнес-подразделения организации.
ПО все чаще становится для компаний конкурентным преимуществом. Все более совершенные инструменты позволяют бизнес-специалистам открывать новые источники дохода или оптимизировать бизнес-функции таким образом, чтобы можно было обеспечить быстрое внедрение инноваций.
И в центре всего этого движения находится облако. Когда о нем заходит речь, подразумевается весьма специфичный набор технологий, позволяющий разработчикам и операторам сопровождения пользоваться преимуществами веб-сервисов, существующих для предоставления виртуализированной вычислительной инфраструктуры и управления ею.
Компании начинают переходить от дата-центров к применению публичных облаков. Одной из таких является Netflix, популярная компания по предоставлению потокового мультимедиа по подписке.
История 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 re:Invent, состоявшейся в 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.
Рис. 1.1. Стек облачных вычислений
В той же публикации в блоге Цианкутти признался, что 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 пришлось изменить не только способ создания и сопровождения своего ПО, но и культуру его организации. Компания перешла к новой модели работы, которая называется DevOps. В соответствии с ней каждая команда стала группой, нацеленной на конечный результат, отходя при этом от традиционной структуры группы проектирования. В группе, нацеленной на конечный результат, команды составляли вертикальную структуру, возлагая на себя функции управления производством и сопровождением конечного продукта. У таких команд было все необходимое для создания и сопровождения их ПО.
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.
Первым пунктом в нашем путешествии станет усвоение понятий и концепций, которые будут использоваться во всей книге для описания хода создания и практического применения облачных приложений.
Двенадцать факторов
Методология 12 факторов представляет собой популярный набор принципов создания приложений, составленный создателями облачной платформы Heroku. Twelve-Factor App — сайт, изначально созданный Адамом Виггинсом (Adam Wiggins), соучредителем Heroku, в виде манифеста с описанием SaaS-приложений, разработанных с целью получить преимущества от использования приемов, свойственных современным облачным платформам.
На сайте https://12factor.net/ методология начинается с описания набора ключевых основополагающих идей по созданию приложений.
Ранее в данной главе шла речь об обещаниях, которые платформа дает пользователям, создающим приложения. В табл. 1.1 представлен набор идей, точно определяющих ценные предложения по созданию приложений и следующих методологии 12 факторов. Идеи разбиваются еще и на набор требований — на 12 отдельных факторов, выделяющих суть этих ключевых идей в коллекцию советов по способам создания приложений.
Таблица 1.1. Ключевые идеи 12-факторных приложений
Использование декларативных форматов для автоматизации установок и настроек в целях сведения к минимуму времени и усилий присоединяющихся к проекту новых разработчиков
Заключение четких соглашений с базовой операционной системой, предусматривающих максимальную переносимость между средами выполнения
Обеспечение должного развертывания на современных облачных платформах, избавляющего от необходимости использовать серверы и системное администрирование
Сведение к минимуму отступлений развертывания от эксплуатации с целью предоставить возможность непрерывного развертывания, позволяющего достичь максимальной адаптации к новым условиям
Предоставление возможности масштабирования без существенных изменений архитектуры, а также практики применения оснастки или развертывания
Все 12 факторов, перечисленных в табл. 1.2, описывают требования, способствующие созданию приложений, использующих идеи, изложенные в табл. 1.1. Двенадцать факторов — базовый набор требований, которые могут применяться в целях создания приложений, оптимизированных для работы в облачной среде. Поскольку факторы охватывают широкий круг вопросов, касающихся самых распространенных приемов во всех современных облачных платформах, создание 12-факторных приложений есть общая отправная точка в разработке облачных приложений.
Таблица 1.2. Приемы создания 12-факторных приложений
Кодовая база
Использование одной кодовой базы, отслеживаемой в системе контроля версий при множестве развертываний
Зависимости
Явное объявление и изолирование зависимостей
Конфигурация
Сохранение конфигурации в среде
Вспомогательные сервисы
Отношение к вспомогательным сервисам как к подключенным ресурсам
Сборка, выпуск, практическое применение
Четкое разделение стадий сборки и практического применения
Процессы
Выполнение приложения в виде одного или нескольких процессов, не использующих состояния
Привязка портов
Экспорт сервисов через привязку портов
Многопоточное выполнение
Горизонтальное масштабирование с помощью модели процесса
Утилизируемость
Максимальная надежность за счет быстрого запуска и корректного завершения работы
Функциональная совместимость разработки и практического применения
Максимально возможная схожесть разработки, доводки и практического применения
Ведение регистрационных записей
Отношение к регистрационным записям как к потокам событий
Процессы администрирования
Запуск задач администрирования и управления в виде разовых процессов
Кроме информации на сайте, посвященном 12-факторным приложениям, подробно описывающей каждый из них, дальнейшему раскрытию каждого требования были посвящены целые книги. Методология 12 факторов теперь используется в отдельных прикладных средах, чтобы помочь разработчикам выполнить требования некоторых или даже абсолютно всех 12 факторов.
В данной книге методология 12 факторов будет применяться для описания конкретных особенностей Spring-проектов, реализованных с целью следовать данному стилю разработки приложений. Так что сейчас важно предоставить краткое изложение каждого из этих факторов.
Кодовая база
Одна кодовая база, отслеживаемая в системе контроля версий при множестве развертываний
Репозиториям исходного кода приложения надлежит содержать одно приложение с манифестом зависимостей этого приложения. Приложению не следует требовать перекомпиляции или пакетирования для различных сред. Как показано на рис. 1.2, все уникальное для каждой среды должно содержаться вне кода.
Рис. 1.2. Исходный код создается один раз и развертывается для каждой среды
Зависимости
Явное объявление и изолирование зависимостей
Зависимости приложения необходимо объявить явным образом, и все без исключения зависимости должны быть доступны из репозитория компонентов, который может загружаться с помощью такого диспетчера зависимостей, как Apache Maven.
Двенадцатифакторные приложения никогда не полагаются на существование подразумеваемых общесистемных пакетов, требуемых в качестве зависимостей для запуска приложений. Все зависимости приложения объявляются в явном виде в файле манифеста, в котором приводится четкое описание всех подробностей каждой ссылки.
Конфигурация
Сохранение конфигурации в среде
Код приложения нужно полностью отделить от конфигурации. Последняя должна определяться средой.
Такие настройки приложения, как строки подключения, учетные данные или имена хостов зависимых веб-сервисов, должны храниться в виде переменных среды, чтобы их можно было легко изменить без развертывания конфигурационных файлов.
Как показано на рис. 1.3, любое отклонение в вашем приложении от среды к среде рассматривается в качестве конфигурации среды и должно быть сохранено в среде, а не с приложением.
Рис. 1.3. Выделение конфигурации, специфичной для среды, в саму среду
Вспомогательные сервисы
Отношение к вспомогательным сервисам как к подключенным ресурсам
К вспомогательному относится любой сервис, используемый 12-факторным приложением в качестве части его обычной работы. Примерами таких сервисов могут послужить базы данных, веб-сервисы RESTful, управляемые через API, SMTP- или FTP-сервер.
Вспомогательные сервисы считаются ресурсами приложения. Эти ресурсы подключены к приложению в течение всего периода его практического применения. Развертывание 12-факторного приложения должно быть рассчитано на замену встроенной базы SQL в среде тестирования внешней базой данных MySQL, размещенной в среде доводки, без внесения изменений в код приложения.
Сборка, выпуск, практическое применение
Четкое разделение стадий сборки и практического применения
В 12-факторном приложении имеется четко выраженное разделение стадий сборки, выпуска и практического применения.
•Стадия сборки. Происходит либо компиляция исходного кода приложения, либо его сборка в пакет. Созданный пакет называется сборкой.
• Стадия выпуска. Сборка объединяется со своей конфигурацией. Затем выпуск, созданный для развертывания, готов для работы в среде выполнения. Каждый выпуск должен иметь уникальный идентификатор, использующий либо семантическое обозначение версии, либо метку времени. Каждый выпуск нужно добавить к каталогу, который может использоваться инструментами управления выпусками для отката на предыдущий выпуск.
• Стадия практического применения. На данной стадии, зачастую называемой временем выполнения (runtime), приложение в виде выбранного выпуска запускается в среде выполнения.
Разбиение этой стадии на отдельные процессы позволяет устранить возможность изменения кода приложения во время выполнения. Единственным способом изменить код остается запуск стадии сборки для создания нового выпуска или запуск отката для развертывания предыдущего выпуска.
Процессы
Выполнение приложения в виде одного или нескольких процессов, не использующих состояния
Двенадцатифакторные приложения создаются без расчета на использование состояния и с прицелом на архитектуру без совместно используемых ресурсов. Этим приложениям присуща лишь возможная зависимость от вспомогательного сервиса. Примерами таких сервисов, предоставляющих средства сохранения данных, могут послужить базы данных или хранилища объектов. Все ресурсы подключаются к приложению во время выполнения в качестве вспомогательного сервиса. Лакмусовой бумажкой, показывающей, применяет ли приложение состояние, является возможность демонтажа и повторного создания среды выполнения без какой-либо потери данных.
Двенадцатифакторные приложения не сохраняют состояние на локальной файловой системе в среде выполнения.
Привязка портов
Экспорт сервисов через привязку портов
Двенадцатифакторные приложения полностью автономны, то есть им в ходе выполнения для внедрения в среду выполнения с целью создания интернет-сервиса веб-сервер не требуется. Каждое приложение откроет к себе доступ через порт HTTP, который привязан к приложению в среде выполнения. В ходе развертывания уровень маршрутизации будет обрабатывать поступающие из открытого имени хоста входящие запросы, направляя их к среде выполнения приложения, в привязки HTTP-порта.
Джошу Лонгу, одному из соавторов этой книги, в сообществе Java приписывается изречение: «Make JAR not WAR» («Создавайте не WAR, а JAR»). Джош использует данное выражение, чтобы объяснить, как в сборочном JAR-файле самые новые Spring-приложения могут встраивать такой сервер Java-приложения, как Tomcat.
Многопоточное выполнение
Горизонтальное масштабирование с помощью модели процесса
Приложения должны быть пригодны к масштабированию процессов или потоков для параллельного выполнения работы по требованию. JVM-приложения могут автоматически справляться с оперативным распараллеливанием с помощью нескольких потоков.
Приложениям следует распределять работу параллельно, в зависимости от выполняемых действий. Сегодня большинство прикладных сред JVM имеют соответствующую встроенную возможность. Некоторые сценарии, требующие заданий по обработке данных, которые выполняются в виде продолжительных задач, должны задействовать управляющие программы, способные осуществлять асинхронную диспетчеризацию параллельного функционирования по доступному пулу потоков.
Двенадцатифакторные приложения должны также иметь возможность горизонтального масштабирования и обработки запросов по сбалансированности нагрузки между несколькими идентичными выполняемыми экземплярами приложения. Отказ от использования состояний в конструкции приложений позволяет справляться с более тяжелыми нагрузками с помощью горизонтального масштабирования приложений по нескольким узлам.
Утилизируемость
Максимальная надежность за счет быстрого запуска и корректного завершения работы
Процессы 12-факторных приложений спроектированы с прицелом на утилизируемость. Приложение в ходе выполнения процесса может быть остановлено в любое время и при этом достойно справиться с утилизацией процессов.
Процессы приложения должны максимально сократить время запуска. Приложениям следует запускаться за несколько секунд и приступать к обработке входящих запросов. Быстрые запуски сокращают время масштабирования экземпляров приложений в ответ на увеличение нагрузки.
Если процессы приложения запускаются долго, то могут ограничить доступность при большом объеме трафика, который способен перегрузить все доступные нормально действующие экземпляры приложения. При уменьшении времени запуска приложений до нескольких секунд его вновь вводимые в общую работу экземпляры получают возможность быстрее реагировать на непредсказуемые резкие скачки трафика без снижения доступности или производительности.
Функциональная совместимость разработки и практического применения
Максимально возможная схожесть разработки, доводки и эксплуатации
Двенадцатифакторные приложения не должны допускать расхождений между средами разработки и применения. Существует три типа расхождений, которые следует иметь в виду.
•Расхождение по времени. Разработчики должны рассчитывать на то, что изменения, внесенные в процессе создания, будут быстро введены в эксплуатацию.
• Расхождения в персонале. Разработчики, вносящие изменение в код, привлекаются непосредственно к его внедрению в производство и тщательно отслеживают поведение приложения после внесения изменений.
• Расхождение в инструментарии. В каждой среде должно быть зеркальное отображение технологии и режимов работы среды, чтобы ограничить возможность неожиданного поведения из-за незначительных несоответствий.
Ведение регистрационных записей
Отношение к регистрационным записям как к потокам событий
Двенадцатифакторные приложения ведут регистрационные записи в виде упорядоченного потока событий в стандартное устройство вывода stout. Приложениям не следует пытаться управлять хранилищем собственных регистрационных файлов. Вместо этого сбором и архивированием регистрационных записей для приложения должна заниматься среда выполнения.
Процессы администрирования
Запуск задач администрирования и управления в виде разовых процессов
Иногда у разработчиков приложения возникает потребность запустить разовые административные задачи. К таковым могут относиться миграции баз данных или запуск одноразовых сценариев, зарегистрированных в репозитории исходного кода приложения. Они считаются процессами администрирования. Подобные процессы для поддержания согласованности между средами должны запускаться в среде выполнения с помощью сценариев, зарегистрированных в репозитории.
Резюме
В этой главе рассматривались мотивы, побудившие организации принять конкретные требования и смену архитектуры. Мы постарались ознакомить вас с некоторыми ранее появившимися толковыми идеями, в частности с манифестом 12-факторных приложений.
