Эта заметка является переводом поста в блоге Дэвида Ханссона под заголовком «Even Amazon can't make sense of serverless or microservices». Здесь минимум редактуры для сохранения оригинальной авторской подачи.
Команда Prime Video из Amazon опубликовала довольно примечательное тематическое исследование, посвящённое их решению отказаться от своей микросервисной serverless-архитектуры и заменить её монолитом. Этот шаг сэкономил им ошеломляющие 90% (!!) эксплуатационных расходов, а также упростил систему. Какая победа!
Но помимо восхваления их здравого смысла, я думаю, что здесь есть более важный момент, который применим ко всей нашей отрасли. Вот что говорит само за себя:
«Мы разработали наше первоначальное решение как распределённую систему с использованием serverless-компонентов... Теоретически, это позволило бы нам масштабировать каждый компонент сервиса независимо. Однако то, как мы использовали некоторые компоненты, привело к тому, что мы достигли жёсткого предела масштабирования — около 5% от ожидаемой нагрузки».
Это действительно подводит итог большому увлечению микросервисами, которое какое-то время охватывало технологическую индустрию: ТЕОРЕТИЧЕСКИ. Теперь, наконец, получены реальные результаты всей этой теории, и ясно, что на практике микросервисы представляют собой, пожалуй, величайшую «песнь сирен» за ненужное усложнение вашей системы. А serverless только усугубляет ситуацию.
Что делает эту историю уникальной, так это то, что Amazon был тем самым эталонным дитя с рекламного плаката сервис-ориентированных архитектур. Гораздо более резонных допрежь микросервисов. Того организационного подхода для внутрикорпоративного взаимодействия на бешеном масштабе, когда вызовы API побеждают созыв координационных совещаний.
SOA совершенно логична в масштабах Amazon. Никакая отдельная команда никогда бы и надеяться не могла на знание и понимание всего необходимого для управления таким флотом супертанкеров. Заставить команды координировать свои действия с помощью опубликованных API-интерфейсов было гениальным ходом.
Но, как и во многих хороших идеях, этот шаблон стал токсичным, как только был принят вне своего первоначального контекста, и посеял хаос, начав внедряться во внутренности архитектур одиночных приложений. Вот так у нас появились микросервисы.
Во многих отношениях микросервисы — это зомби-архитектура. Ещё один штамм интеллектуальной заразы, которая просто отказывается умирать. Она разъедает мозги со времён мрачных дней J2EE (remote server beans, кто-нибудь??), мелькнув бессмыслицей WS-Deathstar, а теперь в виде микросервисов и serverless.
Но эта третья волна, похоже, наконец достигла апогея. Я написал оду Величественному Монолиту ещё в 2016 году. Келси Хайтауэр, один из ведущих разработчиков Kubernetes, прекрасно сформулировал это в 2020 году:
«Мы собираемся разрушить [монолит] и каким-то образом открыть техническую дисциплину, которой у нас вообще никогда не было... Теперь вы перешли от написания плохого кода к созданию плохой инфраструктуры.
Поскольку это провоцирует больше новых затрат, это приводит к большим объёмам найма… Так что многие люди становятся зависимыми от всего этого изобилия денег и маркетинга, а это попросту шумиха, которую люди связывают со своим назначением, тогда как, честно говоря, всё это не обязательно решит их задачу».
Бинго. Замена вызовов методов и разделения модулей сетевыми вызовами и разделением служб в рамках единой, слаженной команды и приложения является безумием почти во всех случаях.
Я рад, что мы отбили зомбонатиск этой ужасной идеи в третий раз на моей памяти, но нам всё равно нужно сохранять бдительность, чтобы в итоге нам не пришлось делать это снова. Некоторые плохие идеи просто отказываются умирать, независимо от того, сколько раз вы их убиваете. Всё, что вы можете сделать, это распознать, когда они снова восстанут из мёртвых, и держать свой риторический дробовик в боевой готовности.