Микросервисы, которые долгое время считались подходом де-факто к архитектуре приложений для облачных сервисов, начали подвергаться рефакторингу со стороны таких облачных гигантов, как Amazon и Google, сообщает портал The New Stack.
Может быть, мы готовим микросервисы неправильно? Таков основной тезис доклада «О современной разработке облачных приложений», представленного группой из Google (во главе с инженером-программистом Майклом Уиттакером) на июньской конференции «HOTOS ’23».
Проблема, как отметили авторы, заключается в том, что микросервисы в основном неправильно организованы с архитектурной точки зрения. Они смешивают логические границы (как написан код) с физическими (как развернут код). И именно здесь начинаются проблемы.
Инженеры Google предложили другой подход. Создавать приложения как логические монолиты, но передавать их автоматизированным средам выполнения, которые принимают решения о том, где запускать рабочие нагрузки, исходя из того, что приложениям нужно и что доступно. Благодаря этому, по их словам, удается снизить латентность систем в 15 раз, а стоимость — в 9 раз.
«Если люди просто начнут с организованного модульного кода, мы сможем сделать архитектуру развертывания деталью реализации», — прокомментировал эту работу известный в мире программирования специалист Келси Хайтауэр.
Что пошло не так с микросервисами?
Несколькими месяцами ранее команда инженеров Amazon Prime Video опубликовала в своем блоге сообщение, в котором объяснила, что, по крайней мере, в случае с видеомониторингом монолитная архитектура дает более высокую производительность, чем микросервисы и бессерверный подход.
Фактически, перейдя на архитектуру микросервисов, Amazon сэкономила 90% операционных расходов. Для поколения инженеров и архитекторов, воспитанных на превосходстве микросервисов, это утверждение прозвучало шокирующе.
«Этот пост — абсолютный позор для Amazon как компании. Полная неспособность выстроить внутреннюю согласованность или скоординированные коммуникации», — написал аналитик Донни Беркхольц, который недавно основал свою собственную отраслевую аналитическую компанию Platify.
«Уникальность этой истории заключается в том, что Amazon изначально была плакатом для сервис-ориентированных архитектур, — заметил создатель Ruby-on-Rails и соучредитель Basecamp Дэвид Хайнемайер Ханссон. — Теперь, наконец, получены реальные результаты всей этой теории, и стало ясно, что на практике микросервисы представляют собой, возможно, самое большое сладкое обещание, которое заставляет вас без необходимости усложнять систему. А бессерверные вычисления только усугубляют ситуацию».
Опыт Amazon Video в использовании микросервисов
Задача инженеров Amazon заключалась в мониторинге тысяч видеопотоков, которые Prime доставлял клиентам. Изначально эта работа выполнялась набором распределенных компонентов, оркестрованных бессерверным сервисом AWS Step Functions.
Теоретически использование бессерверного сервиса позволило бы команде масштабировать каждый сервис независимо. Однако оказалось, что, по крайней мере в том виде, в котором команда реализовала компоненты, она уперлась в жесткий предел масштабирования при нагрузке всего в 5% от ожидаемой. Масштабирование для мониторинга тысяч видеопотоков также было бы неоправданно дорогим из-за необходимости пересылать данные через множество компонентов.
Первоначально команда попыталась оптимизировать отдельные компоненты, но это не принесло значительных улучшений. Тогда она объединила все компоненты в единый процесс, разместив их на Amazon Elastic Compute Cloud (Amazon EC2) и Amazon Elastic Container Service (Amazon ECS).
«Микросервисы и бессерверные компоненты — это инструменты, которые действительно работают в больших масштабах, но вопрос о том, стоит ли использовать их вместо монолита, должен решаться в каждом конкретном случае», — заключила команда Amazon.
Недостатки микросервисов
Пожалуй, термин «микросервисы» был придуман Питером Роджерсом в 2005 г., хотя он называл их «микро-веб-сервисы». Он дал имя идее, над которой многие задумывались, особенно в эпоху веб-сервисов и сервисно-ориентированной архитектуры (SOA), набиравших в то время популярность.
«Основной движущей силой „микро-веб-сервисов“ в то время было разбиение единых крупных „монолитных“ проектов на множество независимых компонентов/процессов, что делало кодовую базу более гранулированной и управляемой», — поясняет инженер-программист Аманда Беннетт.
В последующие десятилетия эта концепция получила широкое распространение, особенно благодаря облачным вычислениям, и только сейчас начала подвергаться критике в некоторых кругах.
В своей работе инженеры Google перечисляют ряд недостатков микросервисного подхода, в том числе:
- Производительность. Сериализация и отправка данных по сети удаленным сервисам снижает производительность и, если приложение становится достаточно сложным, может даже привести к узким местам.
- Понимание. Известно, что в распределенных системах сложно отследить ошибки, учитывая множество взаимодействий между микросервисами.
- Проблемы управления. Считается преимуществом, что различные части приложения могут обновляться по собственному расписанию. Но это приводит к тому, что разработчикам приходится управлять огромным количеством двоичных файлов, каждый из которых имеет свой собственный график выпуска. И в проведении сквозного тестирования с помощью локально управляемого сервиса не помешает удача.
- API становятся хрупкими. Ключ к совместимости микросервисов заключается в том, что после создания микросервиса API не может измениться, а значит, не может сломать любой другой микросервис, который опирается на этот API. Таким образом, API можно расширять только за счет других API, что приводит к раздуванию.
Новый вид микросервисов?
Когда Amazon впервые рассказала о своих открытиях, многие быстро обратили внимание на то, что архитектура, которую использовали разработчики видеосервиса, тоже не совсем монолитная.
«Это определенно не история превращения микросервисов в монолит, — заметил Адриан Коккрофт, бывший вице-президент по стратегии облачной архитектуры AWS, а ныне советник Nubank. — Это история применения Step Functions к микросервисам. И я думаю, что одна из проблем заключается в неправильном обозначении».
Он отметил, что во многих приложениях, особенно внутренних, стоимость разработки превышает стоимость выполнения. В таких случаях Step Functions имеют большой смысл для экономии времени разработчиков, но могут дорого обойтись при больших нагрузках.
«Если вы знаете, что в конечном счете собираетесь делать что-то в определенном масштабе, — пояснил Коккрофт, — вы можете изначально построить это по-другому. Вопрос в том, знаете ли вы, как сделать эту вещь, и знаете ли вы, в каком масштабе вы собираетесь ее использовать?».
В материале Google предложено решение этой проблемы, облегчающее жизнь разработчикам и позволяющее инфраструктуре выполнения определить наиболее экономически эффективный способ запуска приложений. «Делегируя все обязанности по выполнению приложений среде выполнения, наше решение способно обеспечить те же преимущества, что и микросервисы, но с гораздо более высокой производительностью и меньшими затратами», — пишут исследователи.
Год переосмысления
В этом году было много пересмотров базовых архитектур, и микросервисы — не единственный идеал, который подвергается сомнению.
Облачные вычисления, например, также оказались под пристальным вниманием.
В июне компания 37signals, которая управляет Basecamp и почтовым приложением Hey, приобрела парк серверов Dell и покинула облако, нарушив сложившуюся десятилетиями традицию переноса операций офпремис ради нечетко определенного повышения эффективности.
«Это главный обман облачного маркетинга — что все будет настолько проще, что вам почти никто не понадобится для управления, — объясняет Дэвид Хайнемайер Ханссон. — Я никогда этого не видел. Ни у 37signals, ни у кого-либо еще, кто управляет крупными интернет-приложениями. У облака есть некоторые преимущества, но они, как правило, заключаются не в сокращении численности операторов».
Похоже есть и другие, готовые поддержать эту ставку. Позже в этом году компания Oxide Computers выпустила свои новые системы, надеясь, что они будут служить людям с похожими настроениями: выполнять рабочие нагрузки облачных вычислений, но более экономично в собственных дата-центрах.
И, похоже, теперь об этих настроениях задумываются все чаще, изучая счета за облачные вычисления. FinOps стал заметным явлением в 2023 г., когда все больше организаций обращаются к таким компаниям, как KubeCost, чтобы контролировать свои расходы на облачные вычисления. А сколько людей были ошеломлены новостью о том, что клиент DataDog получил счет на 65 млн. долл. за мониторинг облака?
Возможно, затраты в 65 млн. долл. на мониторинг и оправданы для компании, получающей миллиардные доходы. Но если главные архитекторы внимательно посмотрят на инженерные решения, принятые за последнее десятилетие, они могут решить внести некоторые коррективы. И микросервисы не станут исключением.
