Михаил Фомин

Новое время потребовало от бизнеса искать новые решения, чтобы отвечать на запросы клиентов и предвосхищать ожидания от сервиса. Повсеместная монолитная архитектура не отвечала запросам, связанным с быстрым масштабированием проектов. Кроме этого, компоненты монолита при «выгорании» часто нарушали работу всего сервиса. Даунтаймы крайне опасны для любого бизнеса, поэтому в качестве альтернативы монолиту в самых разных проектах стала все чаще использоваться микросервисная архитектура. Стоит заметить, что этому процессу также предшествовала популяризация методологии DevOps, но, пожалуй, это тема для отдельного материала. Можно сказать, что микросервисная архитектура появилась в момент, когда клиент-серверная архитектура эволюционировала в сторону распределительных систем. Распределенные системы отличаются от традиционной модели «клиент-сервер» тем, что несколько различных приложений в них работают на нескольких различных, но взаимосвязанных системах. Сама по себе архитектура еще не решала проблем, связанных со скоростью развертывания, но уже двигалась в этом направлении. В то же время нельзя было воспринимать ее как панацею от всех проблем. Например, проблемы с компонентом авторизации могли все так же приводить к недоступности сервисов, но это уже проблема критических областей, а не всего приложения как болевой точки. Многие разработчики считают микросервисную архитектуру главным драйвером развития всей индустрии, но значит ли это, что монолит — это однозначно плохо? На самом деле, нет. Особенности монолитной архитектуры Выбор архитектуры во многом зависит не только от задач проекта, но и от организации команды. Для небольших команд от 2 до 5 человек монолитный подход может быть более выигрышным по ряду причин: Работа в одном приложении решает проблему с логированием и безопасностью, которой часто пренебрегают при микросервисном подходе. Не требуется уделять столько внимания взаимосвязи компонентов, как при микросервисной организации. Более простой мониторинг. Порог входа в микросервисы на порядок выше, поскольку разработка требует наличия в команде специалистов с определенными компетенциями. Монолитная архитектура действительно хороша, когда нужно быстро выкатить в прод новую фичу, но нет возможности готовить инфраструктуру — чаще это решение для новых продуктов. Нужно также понимать, какие сложности и на каком этапе команда сможет перенести с наименьшей потерей ресурсов. В то же время, некоторые большие проекты не спешат переходить на микросервисы, поскольку с точки зрения затрат и ресурсов для них выгоднее масштабировать инфраструктуру, чем переделывать архитектуру всего сервиса. На графике отражено примерное отношение стоимости кода по мере развития проекта: чем больше кода придется дописать в монолите, тем дороже окажется решение. В то же время, чем больше кода будет в микросервисах — тем меньше за это придется заплатить. Поскольку разделение большого монолита на микросервисы достаточно болезненный процесс, можно проводить его постепенно, но сам выбор архитектуры стоит осуществлять, исходя из бизнес-потребностей. Стоит спросить себя «достаточно ли приложение большое, чтобы дробить его на микросервисы?». Чтобы перейти от монолита к микросервисам чаще всего применяется два подхода. Подход «большого взрыва» и поэтапный рефакторинг. В «большом взрыве» все усилия сосредотачиваются на рефакторинге монолита. Внедрение новых функций на этот период приостанавливается. Поэтапный рефакторинг гарантирует, что новые функции будут реализованы в виде современных микросервисов, которые могут взаимодействовать с монолитом через API-интерфейсы. При этом непосредственно в монолит код не интегрируется. По мере модернизации продукта функциональность монолита постепенно делегируется микросервисам. Когда компания выбирает свой путь рефакторинга, важно учесть следующие аспекты: Какие бизнес-компоненты отделить от монолита и превратить в распределенные микросервисы. Как отделить базы данных от приложения, чтобы отделить сложность данных от логики приложения. Как протестировать новые микросервисы и их зависимости. Особенности микросервисной архитектуры В основе микросервисной архитектуры лежит принцип, что каждый микросервис — реализует свою бизнес-возможность. Его можно протестировать, развернуть или обновить, не затрагивая работу соседей. Такое разграничение полномочий обеспечивает высокую отказоустойчивость (при должной настройке) и открывает возможность контейнеризации приложений. Упаковка микросервисов в контейнеры стала следующим шагом в эволюции разработки и поддержке приложений. Подход позволяет не заботиться о консистентности языков — любой микросервис может быть написан на языке, который максимально релевантен задачам узла. Каждый контейнер как единица ПО содержит в себе среду разработки, код, системные инструменты, различные библиотеки и настройки – очень удобно, но главная их особенность в том, что микросервис оказывается изолирован. Благодаря четким границам контейнера, его можно легко переместить или масштабировать, например, при возрастании нагрузки на приложение. Кроме этого, его можно безболезненно обновить, так что клиенты не почувствуют, что в какой-то части приложения ведутся работы. В условиях сезонного спроса или при проведении рекламных кампаний, количество пользователей может резко увеличиться, поэтому даунтайм на этом отрезке сведет на нет все успехи маркетинга. Во время пиковых нагрузок какой-либо контейнер может «сгореть», поэтому потребуется оперативная замена из образа. Теперь очевидно, почему монолитные приложения все чаще распиливаются на микросервисную архитектуру. Оркестрация и Kubernetes Можно ли автоматизировать этот процесс, чтобы новые приходили на замену «сгоревшим», а поставки осуществлялись бесперебойно? Управление контейнерами оказалось непростой задачей, поэтому появились системы оркестрации. С их помощью стало возможным настраивать зависимости между контейнерами и развертывать их быстрее и проще. Одним из самых популярных решений считается Kubernetes, также известный как K8s. За 8 лет Kubernetes прошел путь от любопытного решения и сайд-проекта разработчиков из Google до настоящего бренда. Не будем проводить расследование, почему так получилось, но K8s оказался одновременно удобен и для разработчиков, и для бизнеса*. *Под такими звездочками всегда прячутся самые сложные задачи в учебниках и самые неудобные условия договоров. В случае c Kubernetes таких вещей оказалось несколько: Опытных специалистов по Kubernetes чрезвычайно мало на рынке. Содержать собственный полноценный отдел DevOps, скорее всего, окажется экономически невыгодно, особенно для стартапов. В отсутствие специалистов с должным уровнем компетенции деплой действительно превращается в лаву, в то время как Managed Kubernetes позволяет автоматизировать основные задачи, связанные с поддержкой работы вашего приложения. Kubernetes как Managed Service В основе сервиса лежит принцип делегирования. Бизнес получает возможность сосредоточиться на самом продукте и заботе о клиентах, а не беспокоиться об инфраструктуре. В первую очередь, сервис позволяет качественно улучшить процессы развертывания и масштабирования. В силу того, что лучшей практикой считается логика, когда каждый микросервис записывает данные в собственную базу данных, провайдер также обеспечивает администрирование, резервное копирование и защиту инфраструктуры. Managed Kubernetes от Selectel может облегчить работу многим компаниям, вне зависимости от их размеров: Для стартапов это отличная возможность не заниматься самостоятельным разворачиванием и обслуживанием кластера. Для среднего и крупного бизнеса — это возможность выстроить гибкую отказоустойчивую платформу любого масштаба, пригодную для работы в разных облаках, с разным кодом и ОС. Для многих ключевым бенефитом здесь окажется возможность быстрого масштабирования под ожидаемую нагрузку. Во вторую очередь, мы настраиваем K8s как систему с автохилингом кластеров. Это помогает избежать конфликта версий и «выгорания» контейнеров. Система отправляет на их место готовый контейнер, так что бизнес не страдает от даунтаймов даже в отдельных узлах. Лучшей практикой в этом смысле является консолидация в одном месте клиентских сервисов и реестра контейнеров. Это обеспечивает высокую скорость загрузки образов и меняет подход к безопасности. Для хранения образов теперь можно не использовать публичные серверы, а хранить все данные в собственном репозитории у провайдера. Готовый к работе Container Registry поможет облегчить хранение, управление и развертывание контейнеров. Провайдер также несет ответственность за доступность кластера и занимается поддержкой актуальных версий самого K8s и компонентов. Вместе с Managed Kubernetes вы сможете подключить все необходимые сервисы для веб- или мобильных приложений. Managed Kubernetes полностью совместим с другими продуктами компании. Перенос приложения в облако, использование объектного хранилища S3 или защита от DDoS-атак синкретичны с Managed Kubernetes, поскольку мы сами выстраиваем всю инфраструктуру, а не работаем как ресейлеры с решениями на основе чужих разработок.

Михаил Фомин

Материалы автора