Монолиты не динозавры Перевод

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

Архитектуры программного обеспечения не похожи на архитектуры мостов и домов. После того, как мост построен, трудно, если вообще возможно, изменить то, как он был построен. Программное обеспечение совсем другое: как только мы запустим наше программное обеспечение, мы можем получить представление о наших рабочих нагрузках, которых у нас не было, когда оно было разработано. И если бы мы поняли это с самого начала и выбрали развивающуюся архитектуру, мы могли бы менять компоненты, не влияя на качество обслуживания клиентов. Мое эмпирическое правило заключается в том, что с каждым порядком роста вы должны пересматривать свою архитектуру и определять, может ли она поддерживать следующий уровень роста.

Я всегда призываю разработчиков учитывать эволюцию своих систем с течением времени и убедиться, что основа такова, что вы можете изменять и расширять их с минимальным количеством зависимостей. Для этого хорошо подходят архитектуры, управляемые событиями (EDA) и микросервисы. Однако, если есть набор сервисов, которые всегда вносят свой вклад в ответ, имеют одинаковые требования к масштабированию и производительности, одинаковые векторы безопасности и, что наиболее важно, управляются одной командой, стоит попробовать их объединить.

Я хочу повторить, что нет единого архитектурного шаблона. То, как вы выбираете разработку, развертывание и управление услугами, всегда будет определяться продуктом, который вы разрабатываете, набором навыков команды, создающей его, и опытом, который вы хотите предоставить клиентам (и, конечно, такие факторы, как стоимость, скорость, и отказоустойчивость).

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

Читать полностью: allthingsdistributed.com