Бывший инженер компании Uber объясняет, кому микросервисы пригодятся, а кому — не очень.
Архитектура микросервисов подойдет не всем. Для компаний с ограниченными ИТ-ресурсами ее использование может оказаться нерациональным. Для компаний, в которых более или менее приемлемо работают существующие системы, идея не стоит таких усилий, чтобы взять и разобрать свои системы на отдельные микросервисы. Возможно, она даже не особо вписывается в культуру DevOps.
Именно так считает Сьюзен Фаулер, автор книги «Production-Ready Microservices», бывший инженер в отделе микросервисов Uber, ныне работающая инженером в Stripe. Недавно она заявила, что самыми подходящими кандидатами для разработки проектов микросервисов являются компании, в которых наметились проблемы масштабирования. Микросервисы могут помочь управляться с приложениями, в которых «ограничения масштаба привели к настолько серьезным проблемам с производительностью и стабильностью, что над приложением стало просто невозможно работать, и скорость разработки упала до нуля».
(По стечению обстоятельств, другой Фаулер, а именно Мартин Фаулер, заложил в 2014 г. фундамент для микросервисов и дал им следующее рабочее определение: «Архитектурный стиль микросервисов представляет собой подход к разработке единого приложения в виде набора небольших сервисов, каждый из которых работает в своем собственном процессе и взаимодействует посредством упрощенных механизмов, часто с помощью API по протоколу HTTP».)
Многим организациям будет нелегко построить у себя хорошо налаженную архитектуру микросервисов. «Большинство систем разрабатывались без учета появления в будущем архитектуры микросервисов», — говорит Сьюзен Фаулер. В результате многие микросервисы проектируются либо обособленно, либо в изолированных средах.
К тому же микросервисы далеко не гладко сопрягаются с DevOps-окружением, отмечает Фаулер. Чаще всего, особенно в крупных дата-центрах, существует очевидный разрыв между работой разработчиков (Dev) и работой технических специалистов в поддержке (Ops). В то же время архитектура микросервисов подразумевает «десятки, сотни, если не тысячи микросервисов и, соответственно, групп разработчиков этих микросервисов, так что с точки зрения организации нерационально укомплектовывать каждую рабочую группу и разработчиками, и инженерами техобслуживания».
И все же микросервисы можно эффективно встроить в работу организации. Фаулер ратует за четырехуровневый подход:
· Аппаратный уровень: средства управления конфигурацией, базы данных, сервера, запись в лог и мониторинг на уровне хоста, операционные системы, изоляция ресурсов, абстрагирование ресурсов.
· Коммуникационный уровень: конечные точки DNS, балансировка трафика, отправка сообщений, сеть, удаленный вызов процедур, обнаружение сервисов, реестр сервисов.
· Уровень приложений: конвейер развертывания, среда разработки, запись в логи и мониторинг на уровне микросервисов, внутренние средства самостоятельной разработки, тестирование, компоновка, компиляция и инструменты для подготовки релизов.
· Уровень микросервисов: собственно, микросервисы.
