Скажу сразу – оба архитектурных подхода имеют место быть. И монолит и Serverless, конечно, имеют свои плюсы и минусы. Но как подобрать лучший подход для конкретного ИТ-продукта? Я изучил этот вопрос и решил поделиться своими мыслями. Может быть, получится сэкономить кому-то время в поисках лучшего решения. 

Меня зовут Василий Широченко, я backend-разработчик в Konig Labs. Когда я в очередной раз столкнулся с темой выбора архитектурного подхода для приложения в среде Amazon Web Services (про это тоже поговорим), я работал над мобильным приложением для обучения игре на фортепиано. Так что, все выводы в статье будут основаны на реальной практике. Поехали!

Для начала, давайте разберемся, почему вопрос архитектуры так важен. Планирование архитектуры ИТ-продукта всегда проводится перед стартом разработки. Это критически важно, т.к.

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

Стоимость внесения изменений при этом должна оставаться адекватной. 

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

Теперь немного контекста о проекте, на примере которого будем рассуждать об архитектуре, и его предметной области.

Заказчик поставил задачу разработать мобильное приложение, которым люди, интересующиеся игрой на фортепиано, могут пользоваться на платформах iOS и Android.

Приложение должно уметь сканировать с листа произведения, записанные в классической музыкальной нотации, и далее распознавать нотный стан, сами ноты, знаки альтерации и т.д. (рис. 1, рис. 2).

Рис. 1. Сканирование с листа

Рис. 2. Распознавание нот

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

Для каждого пользователя хранится история его попыток, показывается процент точности попадания. Также есть экран статистики в разрезе дня/недели/месяца/года.

В принципе, получается несложная предметная область. 

Конечно, мы понимаем, что приложение само по себе не будет работать, потому как где-то необходимо сохранять прогресс их игры, статистику и другие важные данные. По этим причинам необходимо разработать backend-часть для приложения. 

Как я уже говорил, мы будем сравнивать монолитный и Serverless подходы. На самом деле, еще затронем микросервисный, но вскользь. Далее поймете, почему.

Сперва предлагаю кратко пройтись по всем трем подходам, посмотреть на “профпригодность” каждого из них и уже более детально рассмотреть то, что мы выбрали.

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

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

Почему так? Все благодаря своей простоте в разработке и поддержке по сравнению с более сложными подходами (если рассматривать те же микросервисы).

Простота заключается в едином развертывании, когда у нас бизнес-логика всего приложения, UI (то, что видит конечный пользователь), хранение данных (база данных) и возможно другие дополнительные компоненты находятся в общем репозитории, разрабатываются совместно и публикуются на сервер в рамках одного процесса. 

Конечно, у любого решения есть и минусы. Эволюция любого приложения – довольно непредсказуемый процесс, потому как появляются новые требования от заказчика. Эти требования необходимо стараться как-то “вписать” в существующее рабочее решение.

В случае с монолитом, у разработчиков очень часто появляется соблазн нарушить определенные рамки и конвенции, разработанные на этапе проектирования, вследствие чего система начинает сильно вязнуть, и вносить все новые и новые изменения становится труднее.

Архитектура, построенная на основе микросервисов – подход, набравший огромную популярность последние лет десять.

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

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

Среди явных плюсов: система разбита на модули, каждый из которых поддерживается определенной командой разработки, независимые публикации отдельно взятых микросервисов (допустим, в системе развернуто два микросервиса A и B, мы можем обновить микросервис B, не затронув при этом микросервис A).

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

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

Более того, микросервисы должны уметь общаться друг с другом – реализуется это посредством различных протоколов, таких как http, amqp и других. Т.е., в отличие от монолита, здесь дополнительно нужно продумать и реализовать API.

Serverless – данный подход стал применяться сравнительно недавно (последние несколько лет). Его суть в том, что облачный провайдер (по примеру AWS, Azure и др.) предлагает воспользоваться т. н.

бессерверными вычислениями – пользователям теперь не надо заботиться о конфигурировании и поддержке сервера – за вас все делает провайдер (сколько ресурсов потребуется – столько провайдер и предоставит). 

Этот подход достаточно новый. С одной стороны, простота – главное его преимущество перед остальными подходами. Здесь мы имеем в виду удобство работы с инфраструктурой (сервисы, службы, логирование, мониторинг, вертикальное и горизонтальное масштабирование).

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

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

Так что советуем не закрывать статью, вдруг дальше будет написано, где находится Янтарная комната… ????

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

Посовещавшись, пришли к выводу, что микросервисы мы отметаем по причине того, что бизнес-модель не является сложной (даже если забегать вперед с возможными дополнениями) в связи с четко поставленными требованиями к конечному продукту для пользователей. Да, зарекаться не стоит, но взвесив все “за” и “против” решили оставить для более детального рассмотрения два варианта: монолитное решение и serverless.

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

Почему AWS – спросите вы? Все дело в том, что во-первых, заказчик был заинтересован в использовании инфраструктуры AWS, во-вторых, действительно AWS является лидером среди облачных провайдеров во всем мире.

Рис. 3. Сервисы AWS, необходимые в backend-части

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

Рис. 4. Предложенный вариант архитектуры backend’а, построенной на базе монолита

Из схемы на рис. 4 видно, что в системе есть мобильный клиент. Далее из мобильного приложения отправляется запрос в облачную инфраструктуру AWS, а конкретно,в виртуальную машину Ec2 instance. Запрос первым делом попадает на сервер nginx, который отвечает за перенаправление запроса в наше приложение. Что собой представляет приложение? 

Это приложение, написанное на Python, со всеми необходимыми нам endpoint’ами, бизнес-логикой и т.д., запущенное и работающее в Docker-контейнере. Все остальные необходимые сервисы – это просто компоненты, созданные однажды.

Хранилище файлов можно удобным образом выделить в S3. В качестве сервера БД выступает RDS (Relational Database Service).

Так как в системе предусмотрена отправка email-уведомлений, то можно использовать либо Sendgrid, как на схеме, либо AWS SES (Simple Email Service). 

P.S. Забегая вперед, хочется отметить, что на схеме не учтен момент с алгоритмом нахождения ошибок в игре пользователя (SMR). Предполагалось, что этот блок будет являться частью API, но после замеров нагрузки стало ясно, что такие тяжелые вычисления необходимо выносить в специальный сервис. Поэтому дальше в оценке можно будет увидеть этот дополнительный пункт.

Рис. 5. Трудозатраты на разработку монолитного решения

Пока что эти цифры нам ни о чем не говорят, чуть позже сравним их со значениями для serverless-решения.

* Исходим из расчета на 1000 активных пользователей системы

Рис. 6. Затраты на хостинг

1. Традиционная кодовая база. Можем сменить хоста в любой момент и практически ничего менять не придется
2. Упрощенная схема инфраструктуры (общий сервер почти для всего, если не используем выделенные сегменты инфраструктуры)
3. Ec2 запущен в режиме 24/7, поэтому нет проблемы «холодного старта»
4. Довольно предсказуемая ценовая политика, что весьма важно!

Минусы

1. Повышенная ответственность со стороны разработки: настройка веб-сервера nginx, настройка логирования, настройка мониторинга сервисов приложения. Плюс необходима соответствующая квалификация разработчиков.
2. Масштабирование. Нет гарантии, что однажды не упремся в пороговое значение.

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

3. Если захотелось бесплатно поднять БД, то придется настроить бэкапы и мониторинг самостоятельно.

   Это сложнее, чем просто «выставить галочку» в RDS «мне нужны бэкапы каждый день в 24:00», а значит и стоимость работы все равно будет недешевой.

    

4. При изменении чего-либо в конфигурации сервера не всегда получается понять, что пошло не так
5. Авторизацию в серверной части, например, придется реализовывать самостоятельно

Рис. 7. Архитектура serverless backend’а приложения

В данном случае система выглядит немного интересней ???? 

Нет привычных nginx’а, Docker’а, вместо них появились какие-то Lambda с нумерацией от 1 до N, Step Function, Cognito… На самом деле все не очень сложно.

Если вспомнить, что serverless тесно связано с понятием FaaS, то можно увидеть, что вместо единого API у нас получились разрозненные lambda-функции, каждая из которых отвечает за свой endpoint.

Например, чтобы создать пользователя в системе (выполнить POST-запрос /users) мы вызываем определенную lambda-функцию, задача которой создавать пользователей – ничего более!

Тот блок, который помечен как Step Function – долгая задача, выполняющаяся асинхронно (дело в том, что мы не можем блокировать выполнение http-запроса до момента получения результата, потому как алгоритм нахождения ошибок может выполняться десятки секунд, а пользователь не очень хочет видеть заблокированный экран приложения).

Cognito – мощный сервис авторизации пользователей в системе.

Рис. 8. Трудозатраты на разработку

* Исходим из расчета на 1000 активных пользователей системы

Рис. 9. Затраты на хостинг – serverless

1. Подход развертывания конфигурации через template.yaml, который, имеет очевидные достоинства в виде четко структурированного файла с описанием AWS инфраструктуры + любые изменения отслеживаются Git’ом (можно выявить проблемы, связанные с изменением конфигурации) + хорошо документировано на официальном сайте.
2. Lambda-функции являются изолированными, удобно тестируются, для каждой из них создана своя группа для мониторинга.
3. Cloud Watch – очень удобный инструмент для сбора логов и мониторинга сервисов AWS. Для Python есть мощная библиотека boto3, которая позволяет выполнять любые операции с сервисами AWS.
4. Удобный CI/CD (с использованием environment-переменных): dev-stack/prod-stack/etc.
5. Мы не заботимся об обслуживании lambda-функций, мы лишь пишем код и точка. Хотя нет, не точка – еще платим деньги, сколько – не известно – вот такая простая математика, все зависит от ситуации. Тогда почему этот пункт в плюсах?..

1. Высокий порог вхождения при отсутствии опыта. 
2. «Холодный старт» у lambda-функций – специфическое ограничение, для нашего проекта некритично.
3. Грамотная настройка IAM-политик и их полное соблюдение требуют соответствующей квалификации специалистов, что есть не всегда.
4. Кодовая база достаточно плотно завязана на AWS-провайдере.
5. Зачастую, невозможно предсказать нагрузку и предотвратить автомасштабирование (пример – черная пятница), что ведет к непредсказуемым затратам.

Рис. 10. Сравнение стоимостей

Итак, как можно видеть из таблицы (рис. 10), стоимость инфраструктуры не сильно разнится, если смотреть со стороны стоимости разработки. Зато стоимость работ оценена практически в два раза больше.

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

Тем не менее, есть несколько пунктов, которые перевесили наше решение в сторону выбора serverless: 

• Заказчик имеет положительный опыт разработки с использованием инфраструктуры AWS  и настаивает на serverless;
• решение выглядит масштабируемым, т. е. со стороны разработки «практически» не потребуется ничего предпринимать с ростом нагрузки. Те затраты, которые понес заказчик в начале, с лихвой окупятся при масштабировании. А это значительный плюс по сравнению с монолитным решением;
• SAM – об этом будет рассказано более подробно в следующей в статье;
• Со стороны команды разработки, действительно хотелось опробовать современный подход в разработке, поэтому остановились на serverless ????

Консультация по архитектуре ПО
AWS, serverless, архитектура, монолит

Монолитная и микросервисная — разница между архитектурами разработки программного обеспечения — AWS

Перейти к главному контенту

Монолитная архитектура — это традиционная модель разработки программного обеспечения, в которой одна база кода используется для выполнения нескольких бизнес-функций.

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

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

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

Подробнее о микросервисах »

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

В распределенной архитектуре каждый микросервис выполняет одну функцию или один элемент бизнес-логики. Микросервисы взаимодействуют друг с другом через API, а не через встроенные механизмы языка программирования.

Далее мы обсудим другие различия между двумя подходами.

Подробнее об API »

Процесс разработки

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

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

Сначала нужно определить, какие функциональные возможности могут работать независимо друг от друга, и создать согласованный проект API.

Первоначальная координация значительно повышает эффективность при дальнейшем обслуживании кода. Вы сможете быстрее вносить изменения и находить ошибки. Также со временем возрастает возможность повторного использования кода.

Развертывание

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

Развертывание приложений на основе микросервисов намного сложнее, поскольку каждый микросервис представляет собой независимо развертываемый пакет программного обеспечения. Обычно разработчики помещают микросервисы перед развертыванием в контейнеры. Контейнеры помогают изолировать код и все зависимости микросервиса, чтобы обеспечить независимость от платформы.

Подробнее о контейнеризации »

Отладка

Отладкой называют программный процесс выявления в коде ошибок, которые приводят к неправильному или непредсказуемому поведению приложения.

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

Для выявления проблем в коде с микросервисной архитектурой придется анализировать сразу несколько слабо связанных сервисов. 

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

Модификации

Небольшое изменение в одной части монолитного приложения влияет на многие функции программного обеспечения, поскольку весь его код тесно связан. Кроме того, любые изменения в монолитном приложении приводят к тому, что всю систему нужно повторно тестировать и развертывать на сервере.

Подход, основанный на микросервисах, наоборот, очень гибок. Вносить изменения в такое приложение намного проще. Разработчикам не нужно модифицировать все сервисы, достаточно лишь изменить конкретные функции.

Также есть возможность развертывать сервисы независимо друг от друга.

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

Масштабирование

При масштабировании монолитных приложений возникает целый ряд проблем. Монолитная архитектура объединяет все функциональные возможности в одной базе кода, поэтому масштабировать при изменении требований придется все приложение сразу.

Например, если из-за увеличения трафика снижается производительность коммуникационных функций приложения, придется предоставлять дополнительные вычислительные ресурсы для всего монолитного приложения.

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

Архитектура микросервисов поддерживает распределенные системы. Каждый программный компонент в распределенной системе получает собственные вычислительные ресурсы.

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

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

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

Ускорение внедрения инноваций

Монолитная архитектура мешает внедрять новые бизнес-возможности и технологии в существующие приложения. У разработчиков нет простой возможности изменить часть базы кода, используя новые технологические решения, что не позволяет организации адаптироваться к современным технологическим тенденциям.

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

Снижение рисков

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

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

Такие инциденты приводят к серьезным перебоям в обслуживании и могут затронуть всех активных пользователей.

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

Сокращение времени вывода продуктов на рынок

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

И наоборот, организации с хорошим опытом создания микросервисов могут быстрее разрабатывать и выпускать цифровые продукты.

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

Достаточно лишь правильно использовать соответствующие API, что гораздо быстрее и проще для понимания. 

Сокращение совокупной стоимости владения

Как микросервисы, так и монолитные приложения требуют затрат на разработку, развертывание и обслуживание. Однако микросервисный подход более рентабелен в долгосрочной перспективе.

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

Помимо затрат на инфраструктуру, расходы на обслуживание монолитных приложений также растут по мере изменения требований. Например, разработчикам иногда приходится запускать старое монолитное ПО на новом оборудовании.

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

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

Монолитная архитектура и архитектура микросервисов требуют разных подходов разработчиков к созданию приложений. Важно понимать, что микросервисы не уменьшают сложность приложения. Структура микросервисов полезна тем, что выявляет основные сложности и позволяет более эффективно создавать, администрировать и масштабировать большие приложения.

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

Размер приложения

Монолитный подход удобнее при разработке простого приложения или прототипа.

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

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

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

Узнайте, как Netflix использует Lambda »

Компетентность команды

Разработка с использованием микросервисов предоставляет больше гибкости, но требует другого набора знаний и проектного мышления.

В отличие от монолитных приложений, разработка микросервисов требует понимания облачной архитектуры, API, контейнеризации и других технологий, характерных для современных облачных приложений.

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

Инфраструктура

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

Для работы с микросервисами необходима подходящая инфраструктура. Чтобы правильно настроить все инструменты и рабочие процессы для микросервисов, требуется больше усилий, но эти усилия окупятся при создании сложного и масштабируемого приложения.

Перенос монолитных приложений на архитектуру микросервисов возможен, но требует тщательного планирования и внедрения. Важно поддерживать постоянную обратную связь с заинтересованными сторонами. За основу можно взять описанный ниже процесс.

Составьте план

Разработайте стратегию миграции и развертывания, в которой учтены операционные риски, опыт клиентов, технологические возможности, сроки и бизнес-цели. 

Найдите партнера по облачным технологиям

Возьмите в партнеры надежного поставщика облачных услуг и перенесите монолитное приложение в контейнер. Это необходимый процесс, устраняющий зависимости приложения от конкретных требований к аппаратному и программному обеспечению. Затем ваши разработчики могут постепенно разделять большую базу кода на несколько микросервисов. 

Примените методы DevOps

Развивайте культуру DevOps в своей организации и применяйте инструменты непрерывной интеграции и непрерывного развертывания (CI/CD) для поддержки процесса миграции. Методы DevOps для работы с программным обеспечением позволяют сократить жизненный цикл разработки благодаря применению автоматизации. 

Подробнее о DevOps »

Создание микросервисов

Создавайте и развертывайте микросервисы в облачной инфраструктуре. Примените соответствующие инструменты для мониторинга состояния, отслеживания трафика, контроля безопасности микросервисов и быстрого реагирования на проблемы. Если интересно, вы можете прочитать руководство по разделению монолитного приложения IC на микросервисы.

Категория	Монолитная архитектура	Архитектура микросервисов
Проектирование	Единая кодовая база с несколькими взаимозависимыми функциями.	Независимые программные компоненты с автономными функциональными возможностями, которые взаимодействуют друг с другом через API.
Разработка	Требует меньше планирования на начальном этапе, но сложность понимания и поддержки постепенно растет.	Требует больше планирования и инфраструктуры на начальном этапе, но со временем управление и обслуживание упрощаются.
Развертывание	Все приложение развернуто как единое целое.	Каждый микросервис представляет собой независимый программный объект, требующий индивидуального контейнерного развертывания.
Отладка	Весь путь кода можно отслеживать в одной среде.	Требуются сложные инструменты отладки, умеющие отслеживать обмен данными между несколькими микросервисами.
Модификация	Небольшие изменения влекут за собой большие риски, поскольку затрагивают всю базу кода.	Можно изменять отдельные микросервисы, не затрагивая приложение в целом.
Масштабирование	Необходимо масштабировать все приложение, даже если увеличится нагрузка только на некоторые функциональные области.	При необходимости можно масштабировать отдельные микросервисы, что снижает общие затраты на масштабирование.
Инвестиции	Низкие первоначальные инвестиции, но более высокий объем работ по текущему и техническому обслуживанию.	Дополнительные затраты времени и средств на создание инфраструктуры и накопление опыта в команде. С другой стороны — долгосрочная экономия затрат, более простое обслуживание и адаптивность.

AWS позволяет создавать современные приложения с использованием модульных архитектурных моделей, бессерверных операционных моделей и гибких процессов разработки. Мы предлагаем полнофункциональную платформу для создания высокодоступных микросервисов любого масштаба и назначения.

Для настройки и поддержки архитектуры микросервисов вы можете использовать, среди прочего, следующие сервисы AWS.

• Эластичный контейнерный сервис Amazon (Amazon ECS) для создания, изоляции и выполнения защищенных микросервисов в управляемых контейнерах, что позволяет снизить сложность операций и расходы на управление.
• AWS Lambda для запуска микросервисов без необходимости подготавливать серверы и управлять ими.
• AWS App Mesh для мониторинга микросервисов и управления ими.
• AWS X-Ray для мониторинга и диагностики сложных взаимодействий микросервисов.

Создайте аккаунт AWS и начните работу с микросервисами в AWS уже сегодня.

Монолиты, микросервисы или бессерверная архитектура: что выбрать для проекта — Timeweb Cloud

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

Разница между монолитами, микросервисами и бессерверной архитектурой

• Под монолитом понимают приложение как неделимую единицу. Традиционно монолитное решение — один исполняемый файл на стороне сервера и еще один — на стороне клиента.
• Архитектура микросервисов представляет собой приложение, состоящее из множества различных сервисов, каждый из которых выполняет свою определенную функцию.
• Бессерверная архитектура — это облачное решение. Бессерверной она называется потому, что всю заботу о масштабировании и распределении ресурсов берет на себя провайдер, а клиенту остается только работа с функциями.

Все три архитектурных подхода, от традиционного монолита до облачного решения, имеют свои сильные и слабые стороны и подходят для проектов определенного типа. Если упрощенно, то:

• Монолитная архитектура часто является хорошим вариантом для относительно небольшого или простого приложения с предсказуемой нагрузкой. Это, например, MVP (минимально жизнеспособный продукт) или веб-сайт, обслуживающий статический контент.
• Микросервисы лучше подходят для более крупных и сложных решений, работающих в том числе и в облаке.
• Бессерверная архитектура идеальна для небольших и средних облачных приложений с непредсказуемыми нагрузками.

Выбор между архитектурными шаблонами определяется как техническими требованиями, так и стратегическими приоритетами. В начале любого процесса разработки ПО необходимо выбрать:

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

Теперь подробно рассмотрим сами архитектурные решения и их плюсы и минусы.

Монолиты

Традиционный подход к созданию приложений путем объединения всех функций в единую сущность, объединяющую интерфейс и серверную часть, по-прежнему актуален. Дело в том, что не всегда есть смысл в усложнении архитектуры.

Если требования к сервису (например, к веб-сайту) включают только скорость, доступность и возможность обслуживания статического контента, который находится в свободном доступе, монолитная архитектура для таких целей — вполне естественный выбор.

А всё остальное было бы чрезмерным усложнением.

Плюсы монолитов

• Скорость, простота и низкая стоимость создания. Приложения, основанные на монолитной архитектуре, как правило, быстрее, проще и дешевле создавать, поскольку они не требуют синхронизации и объединения сложных частей. Поэтому, если монолитное приложение будет делать то, что от него требуется, без ущерба для продвижения, то можно использовать монолитную архитектуру.
• Удобное тестирование. Протестировать монолитное приложение гораздо проще, чем микросервисы или бессерверное. Можно запустить и протестировать приложение на сервере разработчика или в промежуточной среде, а также применить стандартный процесс развертывания для проверки изменений перед запуском приложения в продакшн.
• Простая инфраструктура. Монолитные приложения используют один сервер для внешнего интерфейса, серверной части и базы данных, что упрощает требования к инфраструктуре. А ​​для повышения скорости, масштабируемости, доступности и безопасности монолитных веб-приложений можно добавить сеть доставки контента (например, Cloudflare).
• Снижение затрат на поддержку. При монолите вам нужно поддерживать только один репозиторий. Вам также понадобится только один конвейер тестирования и развертывания, что может значительно снизить затраты, поскольку создание, настройка и обслуживание нескольких конвейеров выйдет дороже, ведь нужно будет обеспечить согласованность между ними. Все данные, используемые приложением, также могут храниться в единой базе данных.
• Мониторинг. Простая инфраструктура обеспечивает дополнительное преимущество в виде упрощения мониторинга.
• Легкое управление транзакциями и поддержка целостности данных. Тот факт, что монолитные приложения обычно используют одну базу данных, означает, что здесь проще управлять транзакциями и поддерживать целостность данных.

Минусы монолитов

• Большие массивы кода. Монолитная архитектура подразумевает единую кодовую базу. Если объемы кода растут, его становится труднее читать и понимать, что затрудняет интеграцию новых разработчиков в проект.
• Могут быть проблемы с обновлениями. Обновление монолитного приложения означает перестройку и повторное развертывание всего кода.
• Высокий уровень зависимостей. Единый код означает, что компоненты тесно связаны, и изменения в логике одного модуля или службы сопряжены с гораздо более высоким риском влияния на код и работу других модулей. Порой трудно предсказать последствия для приложения даже после небольших изменений в коде. Поэтому каждое обновление вынуждает повторно тестировать весь продукт.
• Отсутствие гибкости. Монолитная архитектура одновременно ограничивает диапазон технологий, которые вы можете использовать, и означает, что технологический стек должен быть строго согласован в глобальном плане. Поэтому вы не можете использовать другую, возможно, более подходящую технологию для каких-то отдельных частей приложения.
• Проблемы с масштабированием. Монолитные приложения плохо масштабируются. Поэтому, если вы создаете монолитное приложение, которое неожиданно становится чрезвычайно популярным и должно справляться с гораздо большими нагрузками, а также расширяться, вам придется перенести его на другой шаблон. Либо на микросервисы, либо на бессерверную архитектуру.

Примеры монолитов

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

Микросервисы

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

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

Архитектура микросервисов разделяет приложение на отдельные службы или группы.

Плюсы микросервисов

• Итеративная разработка. Архитектура программного обеспечения на основе микросервисов хорошо подходит для организации гибкой разработки ПО, основанной на итеративном подходе. Разбиение уже работающего приложения на отдельные, слабо связанные между собой сервисы означает, что новые возможности и функции могут быть проверены и добавлены без риска остановки приложения.
• Гибкость. Микросервисы обеспечивают большую гибкость процесса разработки ПО сразу на нескольких уровнях. Это позволяет разным командам одновременно работать над разными сервисами и упрощает интеграцию в процесс разработки новых членов команды, ведь разделенный на отдельные функциональные части код легче читать и понимать.
• Свобода в выборе технологического стека. В монолитной архитектуре, где сервисы тесно связаны, важно поддерживать согласованность технологий, используемых в приложении. Они также должны быть хорошо совместимы друг с другом, что характерно не для всех языков программирования и средств разработки ПО. Слабо связанные микросервисы обеспечивают гораздо большую свободу в выборе стека технологий. Вплоть до того, что команда разработчиков может даже создавать отдельные сервисы с очень разным набором инструментов разработки.
• Доступность. Одним из самых больших преимуществ архитектуры микросервисов является то, что слабо связанные сервисы обеспечивают большую надежность приложения и более высокую доступность. Если одна служба выходит из строя, то это, как правило, не влияет на остальную часть приложения, которое продолжит функционировать для пользователей.
• Масштабируемость. Еще одним плюсом микросервисов является то, что этот подход хорошо подходит для масштабирования приложений. Модульность микросервисов позволяет легко добавлять новые функции прямо в работающее приложение. Хотя первоначальные затраты на архитектуру микросервисов выше, ее масштабирование может быть значительно дешевле, чем у монолитного приложения, благодаря сочетанию уже упомянутых сильных сторон.
• Производительность. Также за счет разделения служб и нагрузки между несколькими серверами возможно значительно повысить производительность.

Минусы микросервисов

• Сложность синхронизации. Распределенная система, такая как микросервисы, неизбежно создает дополнительную сложность, поскольку ее части необходимо синхронизировать таким образом, чтобы они могли работать как единая программная система. И если службы разделены между серверами, вам придется подготовить инфраструктуру для взаимодействия микросервисов.
• Сложность тестирования. С одной стороны, тестировать отдельные микросервисы проще, с другой, необходимость тестировать каждый сервис по отдельности может значительно усложнить приложение по мере его масштабирования. А необходимость тестировать и поддерживать связь между службами создает дополнительную сложность.
• Более высокие первоначальные затраты. Хотя попытки значительно масштабировать монолитное приложение могут оказаться сущим кошмаром, который приводит к резкому росту прямых затрат на разработку, архитектура микросервисов требует более высоких первоначальных затрат. Для каждого микросервиса требуется своя команда разработчиков (хотя одна команда может отвечать и за несколько). Кроме того, придется наладить и процесс автоматического тестирования и развертывания (CI/CD). Всё это приводит к более высоким первоначальным затратам.
• Потребность в DevOps. Распределенная система, такая как микросервисы, требует квалифицированной оркестровки, обычно с использованием Kubernetes и других инструментов и процессов DevOps. Это означает, что вам нанять хотя бы одного инженера DevOps, что также увеличит расходы.

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

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

Примеры микросервисов

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

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

Бессерверная архитектура

Прежде всего отметим, что многие современные приложения сочетают в себе бессерверную архитектуру и микросервисы.

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

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

Плюсы бессерверной архитектуры

• Гибкость. Разделение приложений с помощью облачных функций дает такие же преимущества гибкости, как и микросервисы.
• Экономия на ресурсах. Бессерверные функции запускаются только тогда, когда они необходимы, что потенциально позволяет сэкономить значительные ресурсы. Ведь служба в микросерверной архитектуре доступна постоянно, тогда как у функции есть жизненный цикл — она вызывается, выполняется и «убивается», как только выполняет свою работу.
• Экономия на инфраструктуре. Всю инфраструктуру выделяет облачный провайдер, что означает, что разработчики могут полностью сосредоточиться на коде. А еще функции, размещенные на бессерверной платформе, можно использовать и в нескольких приложениях. Например, если у компании есть несколько приложений, каждое из которых содержит профили пользователей, для которых загружаются изображения этих профилей, то для них можно использовать одну и ту же функцию.
• Масштабируемость. Как и в случае с микросервисами, модульная организация бессерверных приложений упрощает разработчикам масштабирование приложений. В облаке над новыми функциями можно работать независимо, а затем постепенно добавлять их в работающее приложение.
• Надежность и доступность. Опять же, как и в случае с микросервисами, приложение, разбитое на слабо связанные функции, создает гораздо меньше зависимостей между ними, чем в монолитной архитектуре. Поэтому, если одна функция дает сбой, приложение продолжит работу. А провайдер, заботящийся о своей инфраструктуре, обеспечивает дополнительное снижение потенциальных точек отказа.

Минусы бессерверной архитектуры

• Сложность. С одной стороны, провайдер, заботящийся об облачной инфраструктуре, снижает сложность бессерверной архитектуры. Однако разбивка на независимые функции означает, что система, как и в случае с микросервисами, состоит из множества частей, что делает управление ей более сложной задачей, чем монолитом.
• Ограничения технологического стека. Бессерверная архитектура менее гибкая, чем микросервисы. Эти платформы часто поддерживают только отдельные языки программирования, фреймворки и инструменты, и, хотя существуют обходные пути, реализовать поддержку нужного инструмента бывает непросто. Поэтому разработчики часто ограничены инструментарием провайдера.
• Привязка к провайдеру. Полностью бессерверные приложения тесно связаны с платформой поставщика услуг, для которой они были созданы. Но каждая облачная платформа поддерживает разные технологии, а это означает, что перенастройка бессерверных функций для платформы другого провайдера может оказаться трудной задачей. Особенно, если приложение большое и сложное, то есть включает множество функций.
• Несовершенные инструменты. По сравнению с традиционными монолитами и микросервисами инструменты, доступные для поддержки бессерверной разработки и обслуживания, еще нельзя назвать зрелыми. Так, пока еще трудно говорить о полноценной поддержке мониторинга и журналирования. Тем не менее, поскольку бессерверная архитектура быстро набирает популярность, инструментарий со временем будет также совершенствоваться.

Примеры бессерверной архитектуры

Видов приложений, которые можно полностью создавать в облаке, довольно много. Поэтому сосредоточимся на конкретных службах, которые предлагаются облачными провайдерами в качестве бессерверных функций или FaaS (Function as a Service). Вот одни из самых популярных:

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