Книга: Руководство по DevOps
Архитектурные архетипы: монолитный или микросервисы
Архитектурные архетипы: монолитный или микросервисы
В определенный момент своей истории почти все организации, использующие сейчас DevOps, были отягощены плотно связанной, монолитной архитектурой. Успешно помогая им соответствовать требованиям рынка или требованиям к продуктам, она создавала риск сбоев организационной структуры, если пользователям надо было значительно расширять деятельность (например, монолитное приложение на C++ компании eBay в 2001 г., монолитное приложение OBIDOS компании Amazon в том же году, монолитное клиентское Rails-приложение Twitter в 2009 г. и монолитное приложение Leo компании LinkedIn в 2011 г.). В каждом из этих случаев компании смогли перепроектировать свои системы и заложить основы не только выживания, но и процветания и победы на рынке.
Монолитные архитектуры неплохи по своей сути, в реальности они часто становятся лучшим выбором для организации на раннем этапе жизненного цикла продукта. Как отмечает Рэнди Шуп, «нет идеальной архитектуры для всех продуктов и всех масштабов. Любая архитектура соответствует некоторому набору целей или диапазонам требований и ограничений, таких как время вывода на рынок, простота развития функциональности, масштабирование и так далее. Функциональность любого продукта или услуги почти наверняка будет изменяться с течением времени, так что нет ничего удивительного, что наши архитектурные потребности будут меняться. Что работает в масштабе 1x, редко работает в масштабе 10x или 100x».
Основные архитектурные архетипы показаны в табл. 3, каждая строка означает различные эволюционные потребности организации, каждый столбец показывает достоинства и недостатки разных архетипов. Как видно из таблицы, монолитная архитектура, поддерживающая стартапы (например, быстрое прототипирование новых функций и возможность отклонений или больших изменений в первоначальных стратегиях), очень отличается от архитектуры, требующей наличия сотен команд разработчиков, когда каждая должна быть в состоянии самостоятельно предоставлять продукт клиентам. Поддерживая эволюционность архитектур, мы можем добиться того, что наша архитектура всегда обслуживает текущие потребности организации.
Таблица 3. Архитектурные архетипы
Источник: Shoup, From the Monolith to Micro-services.
- Архитектура, обеспечивающая производительность, тестируемость и безопасность
- Облачное хранилище данных компании Google
- Архитектурные архетипы: монолитный или микросервисы
- Практический пример
- Эволюционная архитектура в компании Amazon (2002 г.)
- Используем шаблон «удушающих приложений», чтобы безопасно развивать архитектуру нашей организации
- Практический пример
- Шаблон удушения в программе Blackboard Learn (2011 г.)
- Заключение
- Заключение к третьей части