Константин Рядов Инженер JVM, ушедший в инженерию ИИ. То, что я сделал.

Рубрика бэк ту скул: почему появились микросервисы и откуда взялся Polyglot Architecture?

Когда говорят о микросервисах, часто можно услышать такую историю:

Микросервисы появились потому, что разные команды хотели использовать разные языки программирования, разные базы данных и вообще работать независимо друг от друга.

Звучит логично, но исторически это не совсем так.

На самом деле микросервисы появились как ответ на проблему масштабирования больших систем и больших организаций. А уже потом возникли идеи Polyglot Programming, Polyglot Persistence и, как следствие, Polyglot Architecture.

Сначала был монолит

Для небольшой команды монолит обычно является отличным решением:

  • проще разработка;
  • проще тестирование;
  • проще деплой;
  • меньше инфраструктуры;
  • меньше сетевых взаимодействий;
  • меньше операционной сложности.

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

Проблемы начинаются позже:

  • продукт растёт;
  • появляется много команд;
  • разные части системы развиваются с разной скоростью;
  • релизы начинают мешать друг другу;
  • координация становится дорогой.

Именно в этот момент компании начинают искать способы разделить ответственность и снизить связанность между командами.

Закон Конвея

Чтобы понять происхождение микросервисов, нужно вспомнить Conway's Law.

В 1967 году Мелвин Конвей сформулировал принцип:

Любая организация, проектирующая систему, создаёт архитектуру, которая отражает структуру её коммуникаций.

На практике это означает:

  • одна небольшая команда часто создаёт монолит;
  • несколько независимых команд начинают создавать относительно независимые подсистемы;
  • архитектура со временем повторяет границы ответственности внутри организации.

Именно поэтому микросервисы многие считают не только архитектурным, но и организационным паттерном.

Amazon и автономные команды

Одним из самых известных примеров стала Amazon.

Там популяризировали концепцию Two Pizza Teams. Смысл был не столько в количестве людей, сколько в автономности команды. Каждая команда должна обладать всеми необходимыми компетенциями для развития своей бизнес-функции и не зависеть от множества внешних согласований.

Такая команда:

  • отвечает за конкретную бизнес-возможность;
  • самостоятельно принимает технические решения;
  • разворачивает свои сервисы;
  • поддерживает их в продакшене;
  • отвечает за результат перед бизнесом.

Отсюда появился знаменитый принцип:

You build it, you run it.

Когда каждая команда владеет своим доменом целиком, становится логичным выделять этот домен в отдельный сервис.

Так появляются микросервисы.

Что такое Technology Diversity

В классической статье о микросервисах Fowler и Lewis описывают одну из важных характеристик такого подхода: Technology Diversity. Отдельные сервисы могут использовать разные языки программирования, разные фреймворки и разные технологии хранения данных.

Например:

  • платёжная система работает на Java;
  • сервис рекомендаций написан на Python;
  • высоконагруженный API реализован на Go;
  • фронтенд использует TypeScript.

Главное, чтобы между сервисами существовали понятные и стабильные контракты взаимодействия.

И вот здесь начинается история всего «полиглотного» мира.

Polyglot Programming

Ещё в 2006 году Neal Ford предложил термин Polyglot Programming.

Идея была простой:

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

Например:

  • Python отлично подходит для машинного обучения;
  • Go удобен для сетевых сервисов;
  • Rust хорош там, где критичны производительность и безопасность;
  • TypeScript доминирует в веб-разработке.

То есть вместо подхода «один язык на всё» появляется подход «лучший инструмент для конкретной задачи».

Важно понимать, что идея Polyglot Programming появилась раньше массового распространения микросервисов. Но именно микросервисная архитектура сделала её практичной в больших организациях.

Polyglot Persistence

Затем появилась ещё одна идея, которую активно продвигал Мартин Фаулер:

Polyglot Persistence.

Логика абсолютно такая же, только применительно к данным.

Вместо одной универсальной базы данных для всей системы используются разные типы хранилищ для разных задач:

  • PostgreSQL для транзакций;
  • Redis для кэшей;
  • Elasticsearch для поиска;
  • ClickHouse для аналитики;
  • Neo4j для графовых данных.

Фаулер описывает это как переход от вопроса:

«Как хранить всё в одной БД?»

к вопросу:

«Какая технология лучше подходит для работы именно с этим типом данных?»

Микросервисы идеально ложатся на эту модель, потому что каждый сервис может владеть собственным хранилищем данных.

И наконец: Polyglot Architecture

Когда объединяются:

  • автономные команды;
  • микросервисы;
  • разные языки программирования;
  • разные базы данных;

получается то, что сегодня обычно называют Polyglot Architecture.

Это не отдельный архитектурный стиль со строгим определением.

Скорее это естественное следствие того, что независимые команды начинают выбирать наиболее подходящие технологии для своих задач.

Итог

Если сильно упростить историю развития идей, получается довольно интересная цепочка:

Рост продукта
↓
Рост количества команд
↓
Conway's Law
↓
Автономные продуктовые команды
↓
Микросервисы
↓
Technology Diversity
↓
Polyglot Programming
↓
Polyglot Persistence
↓
Polyglot Architecture

Поэтому исторически наиболее корректно говорить так:

Микросервисы появились не потому, что разработчики хотели использовать разные языки программирования и разные базы данных. Они появились как способ масштабировать разработку больших систем и ответственность больших команд. А Polyglot Programming, Polyglot Persistence и Polyglot Architecture стали естественным следствием автономности команд и децентрализации технических решений.

Полезные ссылки

Все записи