Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Эта заметка является переводом поста в блоге Дэвида Ханссона под заголовком «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 году:
"Мы собираемся разрушить [монолит] и каким-то образом найти инженерную дисциплину, которой у нас никогда не было... Теперь вы перешли от написания плохого кода к созданию плохой инфраструктуры.
Поскольку это приводит к большим новым расходам, это приводит к большому количеству новых сотрудников… Так что многие люди становятся зависимыми от всего этого изобилия денег и маркетинга, и это просто шумиха, с которой люди связывают своё назначение, хотя, честно говоря, это не обязательно решит их проблему ".
Бинго. Замена вызовов методов и разделения модулей сетевыми вызовами и разделением служб в рамках единой, согласованной команды и приложения является безумием почти во всех случаях.
Я счастлив, что мы отбили натиск зомби этой ужасной идеи в третий раз на моей памяти, но нам всё равно нужно сохранять бдительность, чтобы в конечном итоге нам не пришлось делать это снова. Некоторые плохие идеи просто отказываются умирать, независимо от того, сколько раз вы их убиваете. Всё, что вы можете сделать, это распознать, когда они снова восстанут из мёртвых, и держать свой риторический дробовик заряженным.
