Home » Даже Amazon не может разобраться в бессерверных технологиях или микросервисах

Даже Amazon не может разобраться в бессерверных технологиях или микросервисах

«Мы разработали наше первоначальное решение как распределенную систему с использованием бессерверных компонентов… Теоретически это позволило бы нам независимо масштабировать каждый сервисный компонент. Однако то, как мы использовали некоторые компоненты, привело к тому, что мы достигли жесткого предела масштабирования около 5%. предполагаемой нагрузки».

Это действительно резюмирует так много повального увлечения микросервисами, которое какое-то время разрывало технологическую индустрию: В ТЕОРИИ. Теперь, наконец, получены реальные результаты всей этой теории, и становится ясно, что на практике микросервисы представляют собой, возможно, самую громкую песнь сирен для ненужного усложнения вашей системы. А бессерверность только усугубляет ситуацию.

Что делает эту историю уникальной, так это то, что Amazon был первым детищем сервис-ориентированных архитектур. Гораздо разумнее до микросервисов. Организационная модель для взаимодействия внутри компании в сумасшедшем масштабе, когда вызовы API превосходят планирование координационных совещаний.

SOA имеет смысл в масштабах Amazon. Ни одна команда не могла надеяться знать или понимать все, что необходимо для управления таким парком супертанкеров. Заставить команды координировать свои действия с помощью опубликованных API-интерфейсов было гениальным ходом.

Но, как и в случае со многими хорошими идеями, этот шаблон стал токсичным, как только он был принят за пределами своего первоначального контекста, и сеет хаос, когда его внедряют внутрь архитектур с одним приложением. Вот так у нас появились микросервисы.

Во многих отношениях микросервисы — это зомби-архитектура. Еще один штамм интеллектуальной заразы, который просто отказывается умирать. Он поедал мозги с темных дней J2EE (удаленные серверные компоненты, кто-нибудь??) через WS-Звезда Смерти бред, а сейчас в виде микросервисов и бессерверных.

Но эта третья волна, похоже, наконец достигла своего пика. Я написал оду Величественный монолит еще в 2016 году. Келси Хайтауэр, одна из ведущих фигур, стоящих за Kubernetes, скажи красиво в 2020 году:

«Мы сломаемся [the monolith] и каким-то образом найти инженерную дисциплину, которой у нас никогда не было… Теперь вы перешли от написания плохого кода к созданию плохой инфраструктуры.

Потому что это приводит к большим расходам, к найму новых сотрудников… Так что многие люди становятся зависимыми от процветания денег и маркетинга, и это просто шумиха, к которой люди привязывают свое назначение, когда честно говоря, это не обязательно решит их проблему».

Бинго. Замена вызовов методов и разделения модулей сетевыми вызовами и разделением сервисов в рамках единой согласованной команды и приложения почти во всех случаях является безумием.

Я счастлив, что мы в третий раз на моей памяти отразили натиск зомби этой ужасной идеей, но нам все еще нужно сохранять бдительность, потому что в конечном итоге нам придется сделать это снова. Некоторые плохие идеи просто отказываются умирать, сколько бы раз вы их ни убивали. Все, что вы можете сделать, это распознать, когда они снова восстанут из мертвых, и держать свой реторический дробовик запертым и заряженным.

Read more:  Пайе может выйти в стартовом составе Васко на матч с «Флуминенсе»

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.