В ноябре OTUS запускает новую образовательную программу «Архитектор ПО», в связи с этим продолжаем серию публикаций для будущих студентов курса и читателей нашего блога.
Читать первую часть
Микросервисы — это тип сервисно-ориентированной архитектуры программного обеспечения, ориентированный на создание ряда автономных компонентов, составляющих приложение. В отличие от монолитных приложений, созданных как единое целое, микросервисные приложения состоят из нескольких независимых компонентов, которые склеены вместе посредством API.
Структура микросервисов и монолитная архитектура в сравнении
Подход на основе микросервисов ориентирован главным образом на бизнес-приоритеты и возможности, тогда как монолитный подход организован вокруг технологических уровней, пользовательских интерфейсов и баз данных. Микросервисный подход стал тенденцией в последние годы, так как все больше и больше предприятий становятся гибкими и переходят на DevOps.
Есть много примеров компаний, которые эволюционировали от монолитного подхода к микросервисам. Среди наиболее известных — Netflix, Amazon, Twitter, eBay и PayPal. Чтобы определить, подходят ли микросервисы для вашего проекта, давайте определим плюсы и минусы этого подхода.
Самое большое преимущество микросервисов перед другими архитектурами заключается в том, что небольшие отдельные сервисы могут создаваться, тестироваться и развертываться независимо. Поскольку единица развертывания небольшая, это облегчает и ускоряет разработку и релиз. Кроме того, релиз одной единицы не ограничен выпуском другой, которая еще не завершена. И последний плюс здесь заключается в том, что риски развертывания снижаются по мере того, как разработчики релизят части программного обеспечения, а не целое приложение.
С помощью микросервисов несколько команд могут работать над своими сервисами независимо и быстро. Каждая отдельная часть приложения может быть построена независимо из-за изолированности компонентов микросервисов. Например, у вас может быть команда из 100 человек, работающих над всем приложением (как в монолитном подходе), или у вас может быть 10 команд из 10 человек, разрабатывающих различные сервисы.
Давайте представим это визуально.
Повышенная гибкость позволяет разработчикам обновлять компоненты системы, не отключая приложение. Кроме того, гибкость обеспечивает более безопасный процесс развертывания и повышенное время безотказной работы. Новые функции могут быть добавлены по мере необходимости, не дожидаясь запуска всего приложения.
Вертикальное масштабирование (при использовании того же программного обеспечения, но на более мощных машинах) может быть ограничено пропускной способностью каждого сервиса. Но горизонтальное масштабирование (создание большего количества сервисов в одном пуле) не ограничено и может работать с микросервисами динамически. Кроме того, горизонтальное масштабирование может быть полностью автоматизировано.
Самый большой недостаток микросервисов заключается в их сложности. Разделение приложения на независимые микросервисы влечет за собой больше артефактов управления. Этот тип архитектуры требует тщательного планирования, огромных усилий, командных ресурсов и навыков. Причины высокой сложности следующие:
В микросервисном приложении каждый функционал, который взаимодействует через API извне, увеличивает вероятность атак. Эти атаки могут произойти только в том случае, если при создании приложения не будут выполнены надлежащие меры безопасности.
Возможность выбирать разные языки программирования — это палка о двух концах. Использование разных языков усложняет развертывание. Кроме того, труднее переключать программистов между этапами разработки, когда каждый сервис написан на другом языке.
Микросервисы хороши, но не для всех типов приложений. Этот шаблон отлично подходит для развивающихся приложений и сложных систем. Вы можете думать о том, чтобы выбрать архитектуру микросервисов, когда у вас есть несколько опытных команд и когда приложение достаточно сложное, чтобы разбить его на сервисы. Когда приложение большое и должно быть гибким и масштабируемым, микросервисная архитектура выгодна.
Теперь мы можем сравнить эти три программные архитектуры, чтобы визуально определить различия между ними.
Монолитные приложения состоят из взаимозависимых, неделимых блоков и имеют очень низкую скорость разработки. SOA разбивается на более мелкие, умеренно связанные сервисы и отличается медленной разработкой. Микросервисы — это очень маленькие, слабо связанные независимые сервисы, которым свойственна быстрая разработка и непрерывная интеграция.
Бессерверная архитектура — это подход применения облачных вычислений для создания и запуска приложений и сервисов без необходимости управления инфраструктурой. В бессерверных приложениях выполнение кода управляется платформой, что позволяет разработчикам развертывать код, не беспокоясь об обслуживании и обеспечении сервера. На самом деле, бессерверность не означает «отсутствие сервера». Приложение все еще работает на серверах, но сторонняя облачная служба, такая как AWS, несет полную ответственность за эти серверы. Бессерверная архитектура устраняет необходимость в дополнительных ресурсах, масштабировании приложений, обслуживании серверов, а также системах хранения и баз данных.
Бессерверная архитектура включает в себя две концепции:
Вот как схематично выглядит бессерверная структура
При использовании бессерверной архитектуры разработчики могут сосредоточиться на самом продукте, не беспокоясь об управлении сервером или средах исполнения. Это позволяет разработчикам сосредоточиться на разработке продуктов с высокой надежностью и масштабируемостью.
На рынке много поставщиков облачных решений. Вот некоторые из ведущих поставщиков бессерверных вычислений:
Ведущие поставщики бессерверных вычислений
Чтобы узнать, нужен ли этот тип архитектуры вашему проекту, давайте определим преимущества и недостатки реализации модели без сервера.
В бессерверных приложениях разработчикам не нужно беспокоиться об инфраструктуре. Это позволяет им сосредоточиться на самом коде. Бессерверная архитектура позволяет очень быстро раскрутить приложение, поскольку развертывание занимает всего несколько часов или дней (по сравнению с днями или неделями при традиционном подходе).
Переход к бессерверной архитектуре снижает расходы. Поскольку вам не нужно обрабатывать базы данных, некоторую логику и серверы, вы можете не только создавать более качественный код, но и сокращать расходы. При использовании модели без сервера вы платите только за те циклы ЦП и память, которые вы фактически используете.
Многие владельцы бизнеса хотят, чтобы их приложения стали влиятельными и масштабируемыми, как Google или Facebook. Бессерверные вычисления делают масштабирование автоматическим и гладким. Ваше приложение будет автоматически масштабироваться при увеличении нагрузки или базы пользователей, не влияя на производительность. Бессерверные приложения могут обрабатывать огромное количество запросов, тогда как традиционные приложения будут перегружены внезапным их увеличением.
Привязка к поставщику описывает ситуацию, когда вы предоставляете поставщику полный контроль над своими операциями. В результате изменения в бизнес-логике ограничены, и миграция от одного поставщика к другому может вызывать затруднения.
Бессерверная модель не подходит для длительных операций. Бессерверные приложения хороши для коротких процессов в реальном времени, но если задача занимает более пяти минут, бессерверное приложение потребует дополнительных функций FaaS.
Архитектура бессерверного программного обеспечения полезна для решения одноразовых задач и вспомогательных процессов. Она отлично работает для приложений, насыщенных клиентами, и приложений, которые быстро растут и нуждаются в неограниченном масштабе.
И наконец, давайте посмотрим на следующее изображение, чтобы узнать, когда выбирать каждый из этих четырех типов архитектуры:
Выбор правильной архитектуры для вашего MVP является сложной задачей, но RubyGarage имеет многолетний опыт, чтобы помочь вам с вашим выбором. Автор статьи будет рад ответить на все ваши вопросы по этой теме.
Читать первую часть
Микросервисная архитектура
Микросервисы — это тип сервисно-ориентированной архитектуры программного обеспечения, ориентированный на создание ряда автономных компонентов, составляющих приложение. В отличие от монолитных приложений, созданных как единое целое, микросервисные приложения состоят из нескольких независимых компонентов, которые склеены вместе посредством API.
Структура микросервисов и монолитная архитектура в сравнении
Подход на основе микросервисов ориентирован главным образом на бизнес-приоритеты и возможности, тогда как монолитный подход организован вокруг технологических уровней, пользовательских интерфейсов и баз данных. Микросервисный подход стал тенденцией в последние годы, так как все больше и больше предприятий становятся гибкими и переходят на DevOps.
Микросервисы важны просто потому, что они добавляют уникальную потребительскую ценность путем упрощения систем. Разбивая вашу систему или приложение на множество более мелких частей, вы реализуете способ уменьшения дублирования, повышения согласованности и уменьшения связи между частями, что делает ваши общие части системы более понятными, более масштабируемыми и более легкими для изменения.
Лукас Краус, автор Microservices
Есть много примеров компаний, которые эволюционировали от монолитного подхода к микросервисам. Среди наиболее известных — Netflix, Amazon, Twitter, eBay и PayPal. Чтобы определить, подходят ли микросервисы для вашего проекта, давайте определим плюсы и минусы этого подхода.
Плюсы микросервисов
Легко разрабатывать, тестировать и развертывать
Самое большое преимущество микросервисов перед другими архитектурами заключается в том, что небольшие отдельные сервисы могут создаваться, тестироваться и развертываться независимо. Поскольку единица развертывания небольшая, это облегчает и ускоряет разработку и релиз. Кроме того, релиз одной единицы не ограничен выпуском другой, которая еще не завершена. И последний плюс здесь заключается в том, что риски развертывания снижаются по мере того, как разработчики релизят части программного обеспечения, а не целое приложение.
Повышенная гибкость
С помощью микросервисов несколько команд могут работать над своими сервисами независимо и быстро. Каждая отдельная часть приложения может быть построена независимо из-за изолированности компонентов микросервисов. Например, у вас может быть команда из 100 человек, работающих над всем приложением (как в монолитном подходе), или у вас может быть 10 команд из 10 человек, разрабатывающих различные сервисы.
Давайте представим это визуально.
Повышенная гибкость позволяет разработчикам обновлять компоненты системы, не отключая приложение. Кроме того, гибкость обеспечивает более безопасный процесс развертывания и повышенное время безотказной работы. Новые функции могут быть добавлены по мере необходимости, не дожидаясь запуска всего приложения.
Возможность масштабирования по горизонтали
Вертикальное масштабирование (при использовании того же программного обеспечения, но на более мощных машинах) может быть ограничено пропускной способностью каждого сервиса. Но горизонтальное масштабирование (создание большего количества сервисов в одном пуле) не ограничено и может работать с микросервисами динамически. Кроме того, горизонтальное масштабирование может быть полностью автоматизировано.
Минусы микросервисов
Сложность
Самый большой недостаток микросервисов заключается в их сложности. Разделение приложения на независимые микросервисы влечет за собой больше артефактов управления. Этот тип архитектуры требует тщательного планирования, огромных усилий, командных ресурсов и навыков. Причины высокой сложности следующие:
- Повышенный спрос на автоматизацию, поскольку каждый сервис должен быть проверен и подконтролен
- Доступные инструменты не работают с сервисными зависимостями
- Согласованность данных и управление транзакциями становится сложнее, так как каждый сервис имеет базу данных
Проблемы безопасности
В микросервисном приложении каждый функционал, который взаимодействует через API извне, увеличивает вероятность атак. Эти атаки могут произойти только в том случае, если при создании приложения не будут выполнены надлежащие меры безопасности.
Разные языки программирования
Возможность выбирать разные языки программирования — это палка о двух концах. Использование разных языков усложняет развертывание. Кроме того, труднее переключать программистов между этапами разработки, когда каждый сервис написан на другом языке.
В итоге
Микросервисы хороши, но не для всех типов приложений. Этот шаблон отлично подходит для развивающихся приложений и сложных систем. Вы можете думать о том, чтобы выбрать архитектуру микросервисов, когда у вас есть несколько опытных команд и когда приложение достаточно сложное, чтобы разбить его на сервисы. Когда приложение большое и должно быть гибким и масштабируемым, микросервисная архитектура выгодна.
Теперь мы можем сравнить эти три программные архитектуры, чтобы визуально определить различия между ними.
Монолитные приложения состоят из взаимозависимых, неделимых блоков и имеют очень низкую скорость разработки. SOA разбивается на более мелкие, умеренно связанные сервисы и отличается медленной разработкой. Микросервисы — это очень маленькие, слабо связанные независимые сервисы, которым свойственна быстрая разработка и непрерывная интеграция.
Бессерверная архитектура
Бессерверная архитектура — это подход применения облачных вычислений для создания и запуска приложений и сервисов без необходимости управления инфраструктурой. В бессерверных приложениях выполнение кода управляется платформой, что позволяет разработчикам развертывать код, не беспокоясь об обслуживании и обеспечении сервера. На самом деле, бессерверность не означает «отсутствие сервера». Приложение все еще работает на серверах, но сторонняя облачная служба, такая как AWS, несет полную ответственность за эти серверы. Бессерверная архитектура устраняет необходимость в дополнительных ресурсах, масштабировании приложений, обслуживании серверов, а также системах хранения и баз данных.
Бессерверная архитектура включает в себя две концепции:
- FaaS (Function as a Service — функция как услуга) — модель облачных вычислений, которая позволяет разработчикам загружать части функционала в облако и позволяет этим частям выполняться независимо
- BaaS (Backend as a Service — бэкэнд как услуга) — модель облачных вычислений, которая позволяет разработчикам передавать на аутсорсинг аспекты бэкэнда (управление базой данных, облачное хранилище, хостинг, аутентификация пользователей и т. д.), а также писать и поддерживать только часть внешнего интерфейса.
Вот как схематично выглядит бессерверная структура
При использовании бессерверной архитектуры разработчики могут сосредоточиться на самом продукте, не беспокоясь об управлении сервером или средах исполнения. Это позволяет разработчикам сосредоточиться на разработке продуктов с высокой надежностью и масштабируемостью.
На рынке много поставщиков облачных решений. Вот некоторые из ведущих поставщиков бессерверных вычислений:
Ведущие поставщики бессерверных вычислений
Чтобы узнать, нужен ли этот тип архитектуры вашему проекту, давайте определим преимущества и недостатки реализации модели без сервера.
Плюсы бессерверной архитектуры
Простота развертывания
В бессерверных приложениях разработчикам не нужно беспокоиться об инфраструктуре. Это позволяет им сосредоточиться на самом коде. Бессерверная архитектура позволяет очень быстро раскрутить приложение, поскольку развертывание занимает всего несколько часов или дней (по сравнению с днями или неделями при традиционном подходе).
Снижение затрат
Переход к бессерверной архитектуре снижает расходы. Поскольку вам не нужно обрабатывать базы данных, некоторую логику и серверы, вы можете не только создавать более качественный код, но и сокращать расходы. При использовании модели без сервера вы платите только за те циклы ЦП и память, которые вы фактически используете.
Улучшенная масштабируемость
Многие владельцы бизнеса хотят, чтобы их приложения стали влиятельными и масштабируемыми, как Google или Facebook. Бессерверные вычисления делают масштабирование автоматическим и гладким. Ваше приложение будет автоматически масштабироваться при увеличении нагрузки или базы пользователей, не влияя на производительность. Бессерверные приложения могут обрабатывать огромное количество запросов, тогда как традиционные приложения будут перегружены внезапным их увеличением.
Недостатки бессерверной архитектуры
Привязка к поставщику
Привязка к поставщику описывает ситуацию, когда вы предоставляете поставщику полный контроль над своими операциями. В результате изменения в бизнес-логике ограничены, и миграция от одного поставщика к другому может вызывать затруднения.
Не для долгосрочных задач
Бессерверная модель не подходит для длительных операций. Бессерверные приложения хороши для коротких процессов в реальном времени, но если задача занимает более пяти минут, бессерверное приложение потребует дополнительных функций FaaS.
В итоге
Архитектура бессерверного программного обеспечения полезна для решения одноразовых задач и вспомогательных процессов. Она отлично работает для приложений, насыщенных клиентами, и приложений, которые быстро растут и нуждаются в неограниченном масштабе.
И наконец, давайте посмотрим на следующее изображение, чтобы узнать, когда выбирать каждый из этих четырех типов архитектуры:
Выбор правильной архитектуры для вашего MVP является сложной задачей, но RubyGarage имеет многолетний опыт, чтобы помочь вам с вашим выбором. Автор статьи будет рад ответить на все ваши вопросы по этой теме.
