Черные пятницы и киберпонедельники – источники радости для покупателей и периоды наибольшей занятости для многих продавцов. В компании Hudson’s Bay Company (HBC), которой принадлежат торговые марки Lord & Taylor, Saks 5th Avenue и ряд других, прошлогодняя предпраздничная лихорадка стала самым подходящим поводом для испытания новых функций веб-сайтов.
HBC использует типичный сервер приложений Oracle WebLogic и платформу электронной коммерции Blue Martini, предлагаемую разработчиками RedPrairie. Общий ее стек создавался и совершенствовался на протяжении многих лет. «Она работала, но были проблемы с ее развертыванием, сложно было вносить изменения и обновления», – указал Мэтью Пик, управляющий в HBC командой инженеров по инфраструктуре.
Инженеры HBC стали выяснять, как можно решить эти вопросы. Для решения проблемы были предложены микросервисы и контейнеры.
Для начала реализации своего проекта по смене платформы Пик выбрал Product Detail Page (PDP). PDP представляет собой часть приложения электронной коммерции, в котором содержатся описания и фотографии товаров. Вместо того чтобы встраивать PDP в приложение, разработчики из HBC разбили его на 12 отдельных микросервисов, размещавшихся в контейнерах приложения (один из них загружал изображения, другой обслуживал текстовую часть и т. д.).
В микросервисной архитектуре Пик увидел целый ряд преимуществ: разрабатывать и внедрять обновления стало проще, а преодолевать трудности теперь можно более рационально. Если, к примеру, перестает работать функция отчетов о ценах, проблема (теоретически) укладывается в рамки одного сервиса и команда, отвечающая за это, должна ее устранить. Внедрение контейнеров и микросервисов является частью более широкой стратегии, направленной на поддержку мобильных устройств и адаптивного дизайна.
Запуская PDP в прошлогодние черную пятницу и киберпонедельник, HBC решила подстраховаться и направила на микросервисы PDP лишь часть трафика. В случае возникновения нештатных ситуаций их можно было бы отключить и вернуть весь трафик в традиционное русло. «Мы не стали рисковать всем сайтом, – вспоминал Пик, следивший за ситуацией на протяжении всего запуска новых технологий, с пятницы и до понедельника. – Но рано или поздно настает момент, когда нужно просто сказать: “Давайте попробуем”».
HBC пополнила собой растущее число организаций, экспериментирующих с приложениями, построенными на основе архитектур микросервисов. В последние пару лет эта тенденция привлекла к себе большое внимание, оно вызвано желанием разработчиков приложений ускорить написание нового кода и упростить управление сложными приложениями. Но, как и любая другая новая технология, микросервисы ставят перед разработчиками и новые задачи.
Что такое микросервисы?
Эксперты описывают микросервисы по-разному, и согласованного их определения пока не существует. По сути, идея заключается в том, чтобы вместо монолитных приложений проектировался набор компонентов, из которых и будут складываться приложения. Аналитик IDC Эл Хилуа описывает микросервисы как «децентрализованную программную архитектуру, в которой компоненты приложений проектируются и развиваются независимо друг от друга». Связь между отдельными компонентами поддерживается через общие API. Таким образом, приложение или сервис разбиваются на множество компонентов, которые взаимодействуют с помощью API.
Звучит знакомо? Несложно предположить, что микросервисы восходят к модному термину прошлых лет – сервисно ориентированной архитектуре (SOA), воплощавшей идею создания независимых отдельных компонентов приложения.
«Заинтересованность предприятий в микросервисах объясняется поиском нового подхода к построению сервисно ориентированной архитектуры, а также к использованию микросервисов с контейнерами», – пояснил старший вице-президент консультационной компании Cloud Technology Partners Дэвид Линтикум.
Большинство экспертов подчеркивают, что возможности SOA, как правило, ограниченны из-за использования единого языка программирования и среды разработки с традиционными инфраструктурными компонентами. Микросервисы же представляют собой более гибкую методологию разработки сложных приложений, состоящих из небольших и независимых процессов. Микросервисы, образующие приложение, могут быть написаны на разных языках, взаимодействуют друг с другом с помощью стандартных API и размещаются в инфраструктуре нового поколения – виртуальных средах или публичных облаках, в которых используются контейнеры приложений.
Преимущества
Микросервисный подход дает следующие преимущества:
Гибкость. Благодаря разбиению приложения на компоненты каждая отдельная его часть разрабатывается независимо. «Вам больше не нужно беспокоиться о синхронизации действий разработчиков», – заметил Сид Сиджбрандидж, генеральный директор стартапа GitLab, предлагающего репозитарий кода, который составляет конкуренцию GitHub. Вместо того чтобы собирать команду из 100 человек, которые будут работать над одним приложением, вы формируете 10 команд по 10 человек, проектирующих отдельные компоненты и внедряющих новые функции по мере их готовности. Не нужно составлять расписание обновлений и собирать приложение полностью – новые функции появляются сразу, как только они будут готовы.
Частичные нарушения. Если какой-то компонент приложения перестает работать, нет опасности того, что откажет все приложение полностью. «Цель заключается в том, чтобы сузить круг неисправностей и минимизировать их последствия», – пояснил аналитик 451 Research Донни Беркхольц. Например, если банковский сайт создан с использованием микросервисного подхода, при отказе функции перевода денег возможность проверить свой баланс у клиентов все равно остается.
Уменьшение усилий, направленных на синхронизацию действий разработчиков. Команды разработчиков создают компоненты, которые включаются в приложение независимо от деятельности других команд. Интеграция компонентов осуществляется с помощью общих API. Поскольку усилия всей команды сосредоточены только на одном компоненте, ее эффективность повышается. Участники коллектива, разрабатывающие только одну функцию, становятся экспертами в соответствующей области.
Однако на словах разработка приложений на основе микросервисов выглядит гораздо проще, чем на деле.
Задачи
По мнению Беркхольца, у команд, исповедующих agile-проектирование или концепцию DevOps, больше шансов преуспеть в создании микросервисов. DevOps – это объединение функций разработчиков и операционных функций, повсеместное или в каких-то отдельно взятых командных проектах.
В таких средах код пишется, тестируется и внедряется быстрее. Многие предприятия, придерживающиеся концепции DevOps, имеют автоматизированную инфраструктуру с самообслуживанием – например, виртуализированные или облачные среды для тестирования и разработки или для поставки уже готовых приложений. Исследования, проведенные 451 Research, показывают, что две трети организаций применяют при разработке приложений методологию agile-проектирования, а около 40% – концепцию DevOps. Именно в таких организациях вероятность успешного внедрения микросервисов наиболее высока. У компаний, не придерживающихся тенденции разработки следующего поколения, процесс перехода к микросервисам будет протекать сложнее.
На предприятиях, использующих agile-проектирование и DevOps, как правило, создаются контейнеры приложений. Пик говорит о симбиозе контейнеров и микросервисов. Когда вы разбиваете монолитное приложение на компоненты, запуск сервисов в контейнерах помогает разработчикам приложений и команде, выстраивающей инфраструктуру, действовать слаженно. Разработчики знают, что им нужно упаковать приложение в контейнер, а команды, занимающиеся операционной деятельностью, готовят инфраструктуру к запуску этих контейнеров.
Инфраструктура оказывает на микросервисы и другое воздействие. Аналитик Forrester Дэйв Бартолетти утверждает: когда разработчики в организациях начинают следовать новым тенденциям, роль ИТ-инфраструктуры меняется.
«Разработчики, выстраивающие микросервисы, не идут в ИТ-службу оформлять заявку на новую виртуальную машину, – пояснил он. – При agile-проектировании разработчики вправе ожидать, что инфраструктурные ресурсы будут автоматически выделяться им по требованию через API и эластичное масштабирование».
| О контейнерах говорят сегодня повсюду, но что они представляют собой на самом деле? Для понимания технологии контейнеров приложений лучше всего выяснить, насколько повышаются эффективность и скорость развертывания приложений в случае использования контейнеров по сравнению с характерным для прошлых лет традиционным размещением приложений на серверах. |
Для поддержки инфраструктурной среды такого рода существует множество различных инструментов. Строить внутреннее облако можно при помощи программного обеспечения для частных облаков, предлагаемого VMware или OpenStack. Если ИТ-служба не хочет заниматься построением инфраструктуры самостоятельно, она может обратиться к платформам публичных облаков Amazon, Microsoft, Google и других поставщиков. Автоматизировать управление инфраструктурой можно при помощи платформ PaaS Cloud Foundry или Red Hat. Для приложений, управляемых событиями (например, для сценариев Интернета вещей), идеально подходят так называемые бессерверные вычислительные платформы. Каждая такая платформа меняет роль ИТ-службы – теперь перед ней могут ставиться разные задачи, начиная от поставок инфраструктуры и заканчивая построением среды, где разработчики самостоятельно будут развертывать микросервисы.
Для чего микросервисы подходят лучше всего
Архитектура микросервисов оказывает положительное влияние не на все приложения. Приложение должно быть достаточно сложным, для того чтобы его можно было разбить на компоненты. Если приложение предназначено для выполнения только одной функции (например, для проведения в течение нескольких недель маркетинговой кампании по раскрутке веб-сайта), потребности в микросервисах, как правило, нет. А вот сложное приложение, состоящее из множества компонентов (например, ПО для управления потоками данных Интернета вещей), заметно выигрывает при разработке отдельных компонентов и последующем управлении ими.
Для HBC переход на микросервисы оказался успешным, хотя процесс этот шел медленно. В обозримом будущем здесь планируется использовать сочетание приложений, построенных на основе контейнеров и микросервисов, с другими системами, в том числе с базами данных и прочими унаследованными платформами, перевод которых на новые рельсы займет слишком много времени. «После успешного опыта PDP мы будем выстраивать все новые приложения на базе микросервисов, – заявил Пик. – Но для этого потребуется время».
Важно понимать также, какие функции приложения имеет смысл разбивать на компоненты, а какие – нет. По мнению вице-президента консультационной компании DISYS по глобальным сервисам Ахмара Аббаса, различные компоненты микросервисов должны работать относительно независимо друг от друга. Компоненты, которые нуждаются в совместном использовании данных или в их передаче, замедляют создание приложений в стиле микросервисов.
«Если на межкомпонентное взаимодействие уходит больше времени, чем на обработку внутри компонента, вы теряете в эффективности, – пояснил Аббас. – Лучше всего проектировать систему таким образом, чтобы ни один из компонентов не зависел от других. Это даст повышение эффективности и позволит независимо масштабировать каждую функцию как в сторону увеличения, так и в сторону уменьшения».
По словам Беркхольца, ограничение сферы применения микросервисов созданием новых приложений или новых компонентов обусловлено одной простой причиной. Дело в том, что стоимость перевода уже существующих приложений на новую платформу может оказаться слишком высока. И получить выигрыш от новой концепции гораздо проще, когда вы не связаны по рукам дополнительными затратами на проведение необходимых преобразований.
– Brandon Butler. What you need to know about microservices. Network World. November 9, 2016
