Гибель монолитов: Не переусердствуем ли мы с составлением простых приложений?

Представьте: вы строите будку для собаки. Вы берёте фанеру, пилу и гвозди. Внезапно появляется ваш сосед в очках архитектора и толстовке с Kubernetes. «Тебе действительно стоит использовать для этого микросервисы, — говорит он. — Каждая стенка может быть независимым сервисом!»

Мы достигли пика культуры «микросервисы во всём», и пришло время вмешаться.

Почему мы влюбились в распределение

Позвольте рассказать историю о моём друге Дейве. Дейв сделал идеальное приложение для задач — один файл на Python, который мог:

# monolith.py
from flask import Flask
app = Flask(__name__)
todos = []
@app.route("/add/<item>")
def add(item):
    todos.append(item)
    return f"Добавлено {item}!"
@app.route("/list")
def list_items():
    return "<br>".join(todos)
if __name__ == "__main__":
    app.run()

Затем Дейв открыл для себя Docker. Вдруг его установка стала выглядеть так:

Теперь его счёт за облако превышает арендную плату, но, эй, по крайней мере, он «облачный туземец»!

Когда простота становится преступлением

Одержимость распределёнными системами в отрасли достигла комических масштабов. Недавно я видел учебник «Привет, мир микросервисов», для которого требовалось:

• кластер Kubernetes;
• сетка сервисов Istio;
• 17 различных файлов YAML;
• жертвоприношение крови Мартину Фаулеру. Давайте сравним сложность развёртывания:

  Операция	Монолит	Микросервисы
  Запуск локально	python app.py	docker-compose up
  Отладка	Операторы печати	Распределённая трассировка
  Развёртывание	SFTP + перезапуск	GitOps-конвейер
  Размер команды	1 разработчик	5+ SRE

Швейцарский нож против набора инструментов

Мой горячий совет: большинство приложений должны начинаться как монолиты и заслуживать распределения через боль. Вот моё «противоречивое» дерево решений:

Когда выбрать монолит:

• Прототипирование.
• Небольшие команды (1–3 разработчика).
• Линейное масштабирование.
• Крайние сроки, когда нужно просто выпустить продукт.

Когда перейти на микросервис:

• Более 10 микрокоманд.
• Независимое масштабирование.
• Развёртывание в нескольких облаках.
• Вам нравится писать YAML-поэзию.

Искусство стратегических монолитов

Давайте покажу вам, как создать «модульный монолит», который не будет отстойным:

1. Создайте чёткие ограниченные контексты:

# project/
#   auth/
#     routes.py
#     models.py
#   todos/
#     routes.py
#     models.py 

2. Используйте внедрение зависимостей:

class TodoService:
    def __init__(self, db):
        self.db = db
# В вашем маршруте:
service = TodoService(Database())

3. Применяйте вертикальные срезы:

/user-auth
  ├── Dockerfile
  ├── requirements.txt
  └── src/
/todo-management
  ├── Dockerfile
  ├── requirements.txt
  └── src/

Это даст вам возможность разделяться позже без лишних сложностей.

Гибридный подход Хоркрукса

Для тех, кто не может сразу перейти на микросервисы, попробуйте паттерн «Хоркрукс»:

1. Начните с монолита.
2. Определите один изменчивый компонент.
3. Выделите его как сервис.
4. Повторяйте при необходимости. Пример эволюции:

Phase 1: Монолит (Аутентификация пользователя + Задачи)
Phase 2: Монолит + Сервис оплаты
Phase 3: Сервис аутентификации + Монолит задач + Платежи

Совет: используйте этот контрольный список миграции:

• Есть бизнес-обоснование.
• Команда может справиться с когнитивной нагрузкой.
• Мониторинг лучше, чем слежка за бывшим партнёром в Instagram.
• Вы знаете, что такое прерыватель цепи (не электрический).

Советы по выживанию в распределённых системах

Если вы вынуждены использовать микросервисы, избегайте следующих ошибок новичка: Тест инцидента в 3 часа ночи. Можете ли вы отладить его, будучи невыспавшимся, с проблемами двухфакторной аутентификации? Нет? Упростите. Парадокс петабайта. Работаете ли вы с трафиком масштаба Twitter? Нет? Возможно, вам не нужны 16 кластеров Redis. Карусель фреймворков. Хватит изобретать велосипеды. Используйте:

# Для 90% случаев
docker compose up
# Вместо
kubectl apply -f orchestra-of-suffering.yaml

Будущее скучно (и это нормально)

В 2025 году самым радикальным выбором будет использование подходящего инструмента для работы. Иногда это великолепный монолит. Иногда — стратегические сервисы. Всегда речь идёт о бизнес-ценности, а не об архитектурных тенденциях. Как я говорю своей команде: «Если вашей схеме архитектуры нужна легенда, вы, вероятно, слишком усложняете». А теперь вперёд и создавайте простые системы, которые радуют пользователей, а не только нанимают SRE. А что думаете вы? Сталкивались ли вы с чрезмерным использованием микросервисов в дикой природе? Поделитесь своими ужасными историями @CodeMaxim #MonolithsLiveMatter.