Микросервисы, контейнеры, облако
Приложения с микросервисной архитектурой можно развернуть в своем дата-центре или в облаке. Второй вариант удобнее, потому что поддержку инфраструктуры берет на себя провайдер. А если вложиться в разработку и правильно настроить работу контейнеров и микросервисов, получится ощутимая выгода от всей реализации приложения.
Привет, мы — Cloud.ru, провайдер облачных и AI-технологий. Делаем сервисы для разработки и развертывания приложений: виртуальные машины, управляемые кластеры Kubernetes, хранилища данных и другие сервисы, которых у нас в портфолио еще 50 штук.
Почему микросервисы
Микросервисы — это разновидность архитектуры, в которой отдельные компоненты программного обеспечения взаимодействуют между собой и обеспечивают приложение необходимыми функциями. Каждый микросервис поддерживает одну функцию приложения: первый отвечает за аутентификацию и авторизацию, второй генерирует интерфейс, третий заполняет интерфейс контентом под каждую сессию, четвертый взаимодействует с базой данных, в которой хранится информация о пользователях.
Еще есть монолит — архитектура, когда все компоненты приложения, включая пользовательский интерфейс, серверный код и базы данных, наоборот собраны в единый неделимый блок. Раньше, в 2010 году, приложения были монолитными, они существовали и действовали как одна единица и в большинстве случаев как единственный процесс. Со временем стала развиваться API-сервисно-ориентированная архитектура, которая разбивает приложение на составляющие. Но эти составляющие все равно не такие самостоятельные и динамичные, как микросервисы.
Есть несколько причин, почему микросервисы стали популярными:
подвижность — с разделением на составляющие стало проще масштабировать приложения (целиком или отдельные части) в любую сторону. Например, если количество запросов на вход в систему резко возрастает, приложение может запустить больше инстансов конкретной микрослужбы, которая обрабатывает входы в систему вместо увеличение количества ресурсов для всего приложения в целом;
эластичность — если один микросервис упадет, приложение продолжит работать даже несмотря на то, что часть его функций недоступна. В этом смысле микросервисы более эластичны;
быстрые обновления — разработчики могут обновлять и разворачивать микросервисы отдельно друг от друга, а это более эффективно, чем переустановка всего приложения каждый раз, когда его надо обновить;
поддержка — обычно разработчики пишут и управляют кодом отдельно для каждого микросервиса. Это упрощает разработку, потому что исключает необходимость пробираться через огромный базовый код для каждого изменения.
Микросервисы действительно более гибкое архитектурное решение по сравнению с монолитом. Но не стоит рассчитывать на то, что переход на микросервисы автоматически дает все описанные преимущества бесплатно. Микросервисная архитектура требует гораздо большего внимания к настройке окружения. Например, в вопросе масштабирования микросервисы подвижнее, но первоначальная настройка и последующее изменение правил масштабирования — более объемная задача, так как вместо одного правила для монолита мы имеем несколько (возможно даже несколько десятков) для каждого микросевиса отдельно.
Наши клиенты, крупные компании из разных отраслей, чаще выбирают микросервисы, например, для e-commerce. Это подтверждает, что микросервисы хорошо подходят для больших и сложных систем, где каждый сервис можно разрабатывать, тестировать и масштабировать независимо от других.
Что такое контейнеры
Контейнеры — технология развертывания приложений — это изолированные окружения, в которых работают приложения или его части. В отличие от виртуальных машин, которые используют изолированные друг от друга операционные системы, контейнеры делят ресурсы с ОС сервера, на котором они хостятся. Это делает контейнеры более эффективными, чем виртуальные машины, потому что каждое контейнерное окружение не требует полноценной гостевой ОС.
Контейнеры изолированы друг от друга на уровне процессов, а также от неконтейнерных процессов, которые выполняются на сервере. Изоляция на уровне контейнеров более безопасна, чем запуск нескольких приложений непосредственно на сервере.
Технология для развертывания приложений внутри контейнеров существует с момента появления утилиты Unix chroot call в 1970-х. Контейнеры стали популярными в середине 2010х с появлением Docker и Kubernetes, которые упростили создание и управление контейнерными приложениями.
Мы используем микросервисы и контейнеризацию уже 10 лет. Начинали еще до появления оркестраторов вроде Kubernetes, что привело нас к созданию собственного решения для оперирования микросервисами. В современном мире такой подход не стоит поддерживать, лучше сразу использовать Kubernetes, потому что он точно покроет подавляющее большинство потребностей. А если что, можно в любой момент его доработать и кастомизировать. Мы пока не начали использовать Kubernetes, но двигаемся в эту сторону. Основной тормозящий фактор для нас — сложность разделения ресурсов GPU при помощи Kubernetes, наша текущая система позволяет тонко настраивать взаимодействие контейнеров с GPU.
В ритейле бизнес-приложения требуют микросервисного подхода, чтобы проводить регулярные обновления и снизить влияние различных отказов. Любые проблемы с конечным функционалом оказывают сильное влияние на показатели упущенной выручки компании. Минимизировать подобные эффекты можно за счет мультиклауд-подхода и зеркалирования основных компонентов системы. Важно понимать, что для реализации развитого микросервисного приложения командам требуется значительный уровень компетенций и экспертизы как в согласованности работы его компонентов, так и в организации потоков данных.
Как микросервисы и контейнеры работают вместе
Контейнеры — популярный способ реализовать микросервисную архитектуру по нескольким причинам:
Быстрый старт. Виртуальной машине нужно несколько минут, чтобы начать работать, а контейнеру — несколько секунд. Так проще максимизировать подвижность микросервисов, когда они хостятся внутри контейнеров.
Безопасность. Контейнеры обеспечивают изоляцию для каждого контейнерного приложения или микросервиса. Так снижается риск взлома системы. С этой стороны микросервисы в большей опасности, потому что лежат на хостовой ОС.
Service discovery. Микросервисами проще управлять, когда они все работают в контейнерах на одной платформе. При разворачивании микросервисов на виртуальной машине, serverless или unikernels каждый хост, на котором они разворачиваются, может иметь свою сетевую конфигурацию. Но это усложняет дизайн архитектуры сети для надежного service discovery.
Оркестрация. Микросервисами легче управлять (планировать, запускать, останавливать и перезапускать), когда они работают в контейнерах на одной платформе.
Инструменты для разработки микросервисов в контейнерах сильно усовершенствовались за последние несколько лет. Платформы оркестрации для контейнеров, такие как Kubernetes, широко популярны и хорошо поддерживаются в любом публичном облаке. Для оркестрации микросервисов на виртуальных машинах или unikernels, наоборот, есть только несколько инструментов.
Эффективность. Контейнеры, микросервисная архитектура и практика FinOps взаимосвязаны. Контейнеры и микросервисная архитектура обеспечивают техническую основу для гибкой и масштабируемой разработки в облачной среде, а FinOps предоставляет методологию для управления затратами и оптимизации инвестиций в облачные технологии. Вместе они создают эффективную экосистему для разработки, развертывания и финансового управления современными облачными приложениями.
Выбор IT-архитектуры и варианта развертывания приложения зависит от множества факторов: размера и структуры компании, требований к производительности и масштабируемости приложения, требований к его безопасности и надежности, общих требований законодательства. Корректное проектирование приложений и их развертывание с учетом преимуществ микросервисной архитектуры и возможностей контейнеризации дает ощутимый прирост эффективности использования облачных ресурсов. А становление практики FinOps и повышение зрелости российских пользователей облачных сервисов способствуют популяризации использования обоих подходов одновременно.
FinOps становится критически важным для оптимизации облачных затрат и повышения эффективности бизнеса. Интеграция FinOps с микросервисной архитектурой и контейнеризацией не только ускоряет развертывание и инновации, но и предоставляет невиданные ранее возможности для точного контроля и управления ресурсами в реальном времени. Это позволяет компаниям не просто экономить, но и стратегически инвестировать в технологии, которые определят их будущее.
В статье использованы фрагменты из материала американского профессора Криса Тоззи про микросервисы и контейнеры «How microservices and containers work, apart and together».