В процессе разработки программного обеспечения одним из ключевых аспектов является определение структуры и способа распространения приложения. Разработчики могут выбирать между монолитной архитектурой и микросервисами, при этом также существует промежуточный вариант в виде сервисно-ориентированной архитектуры или использования различных подходов вместе.
Плюсы и минусы монолитных приложений
Монолитный подход традиционно используется для развертывания приложений, при котором весь софт поставляется одним, зачастую объемным, пакетом бинарных файлов. Такие приложения включают в себя все необходимые функции и не требуют подключения к сторонним сервисам. К примеру, это могут быть разнообразные настольные приложения, такие как графический редактор Adobe Photoshop, офлайн игры вроде Fallout, а также "коробочные" версии программ, например, Microsoft Excel, или базы данных, такие как Oracle, Microsoft Server и PostgreSQL. Этот же подход применяется и при развертывании серверных приложений. Например, стартап FoodFox изначально был создан как единый монолитный сайт на PHP, и только через 5 лет был переведен на архитектуру микросервисов командой Яндекса. Сегодня сервис доступен под брендом Яндекс Еда. Сайт Auto.ru создан в 1996 году как монолитное PHP приложение. В 2014 году Яндекс приобрел сайт у его основателя и программиста Михаила Рогальского за сумму, оцениваемую в 175 миллионов долларов.
Основное преимущество разработки монолитного приложения заключается в том, что код программы обычно сосредоточен в одном месте, и для вызова функций используются внутренние библиотеки. Эти вызовы нативно поддерживаются операционными системами и широко используемыми фреймворками, включая Java, .NET, PHP, Go и Node.JS. Разработчику не требуется дополнительных усилий для развертывания и координации множества компонентов приложения или межсетевых взаимодействий. Этот подход особенно популярен среди стартапов при создании новых приложений.
Когда размер команды разработчиков увеличивается, происходит замедление развития продукта. Во-первых, возникают чаще конфликты при изменении одних и тех же участков кода. Во-вторых, даже для минимальных изменений разработчикам приходится взаимодействовать с большим количеством коллег. В-третьих, общая скорость работы команды снижается до уровня наиболее загруженного или медленного сотрудника, что хорошо иллюстрируется в книге “Проект Феникс. Как DevOps устраняет хаос и ускоряет развитие компании” авторства Кима, Бера и Спаффорда. В-четвертых, тестирование больших приложений потребляет значительные ресурсы, как в ручном, так и в автоматическом режимах. Один из разработчиков базы данных Oracle в 2018 году описывал свою работу следующим образом: 25 миллионов строк кода на C, исправление ошибки, сотни серверов, занятых компиляцией одного приложения, затем ожидание результатов автотестов от 20 до 30 часов. На следующий день обнаруживается ошибка в автотестах, и процесс начинается сначала.
Архитектура программного обеспечения наследует структуру и принципы компании
Для решения упомянутых выше проблем Amazon и Google применяют подход формирования малых команд, для которой будет достаточно двух пицц. Такие команды эффективно определяют свою сферу ответственности внутри приложения и снижают зависимость от других групп. В крупных организациях это могут быть отдельные сервисы, такие как системы аутентификации, поисковые механизмы, модули рекомендаций или рекламные блоки. В последствии размер сервисов уменьшают до микро и тогда два человека могут буть ответствеными за десятки сервисов. Приложения разделяются на мельчайшие функциональные группы, как, например, микросервис для создания PDF-документов для накладных, микросервис для конвертации видео или микросервис, ответсвенный за отзывы клиентов. Часто архитектура приложения отражает организационную структуру и принципы работы компании. Подход с использованием небольших команд успешно применяется в крупных международных корпорациях.
В контексте микросервисной архитектуры, сервисы могут обновляться несколько раз в день. Это ускоряет процесс разработки и исправления ошибок по сравнению с более громоздкими монолитными приложениями.
Ограничения монолитных приложений из-за их целостности
Монолитные приложения сталкиваются с рядом проблем, связанных с их целостным бинарным пакетом. Во-первых, такой "монолит" обычно устанавливается на одном сервере, и масштабировать его можно лишь "вертикально", увеличивая мощность этого сервера. Этот...
