Если ваша DevOps-команда планирует перейти от традиционных серверных архитектур к микросервисам, то вы должны учитывать различные изменения, связанные с инструментами и навыками, пишет на портале InformationWeek президент и ведущий сетевой архитектор компании West Gate Networks Эндрю Фролик.

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

Понимание на уровне руководства

Технологии и технологические навыки постоянно меняются. Таким образом, CIO и ИТ-менеджеры хорошо понимают, что инструменты и навыки должны развиваться, чтобы использовать преимущества последних корпоративных ИТ-разработок. Однако в некоторых случаях эволюционные изменения для одних технологий не столь очевидны, как для других. Одной из областей ИТ, с которой регулярно сталкиваются ИТ-директора, является DevOps. Помимо понимания того, что DevOps трансформирует с использованием agile-подхода процессы и методы, используемые предприятиями для быстрой разработки, тестирования, развертывания и управления приложениями, руководство ИТ-отделов редко полностью разбирается в некоторых дополнительных деталях. И при обсуждении вопроса о том, как наилучшим образом перенацелить DevOps из разработки ПО для традиционных серверных архитектур на микросервисы, для многих остается загадкой, насколько такой сдвиг полезен для общего состояния организации.

Причины, по которым микросервисы привлекают команды DevOps

ИТ-лидерам важно разобраться в причинах, по которым разработка ПО с использованием микросервисной архитектуры стала столь привлекательной для команд DevOps. Микросервисные архитектуры без чрезмерной технической поддержки устраняют большую часть негибких, ненужных и трудоемких задач и технологий, которые часто используются при разработке ПО на старых монолитных архитектурах. Кроме того, полностью автономные приложения совместно используют вычислительные ресурсы и должны обновляться, изменяться и масштабироваться в виде единой программы. Это добавляет значительный риск при необходимости внесения изменений в ПО.

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

Новые микросервисные платформы и инструменты

Как и в ситуации с любыми технологическими достижениями, перевод DevOps на микросервисные архитектуры потребует ряда новых платформ и инструментов. Наиболее очевидное различие между микросервисами и традиционными программными приложениями заключается в хостовой операционной системе, под которой выполняется ПО. Хотя Microsoft Windows Server и полнофункциональные операционные системы Linux могут выполнять микросервисы, работающие в контейнерах, большинство предпочитает урезанную ОС, которая избавлена от многих ненужных функций/возможностей традиционных серверных ОС. Вместо этого используется меньшая специализированная ОС, которая обеспечивает минимальную функциональность, необходимую для защиты и выполнения микросервисов.

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

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

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

Необходимы дополнительные навыки

Новые технологии полезны только в том случае, если ИТ-персонал понимает, как интегрировать их в существующие производственные среды. Переход от традиционных DevOps-моделей разработки ПО к микросервисам требует значительных изменений в используемых инструментах и платформах.

Микросервисы, по всей вероятности, послужат основой для корпоративных приложений в обозримом будущем. Поэтому жизненно важно, чтобы как разработчики, так и операционный ИТ-персонал прошли обучение, необходимое для успешного создания и управления хост-ОС, контейнерными платформами, средствами оркестровки/планирования и средствами мониторинга производительности контейнеров. В зависимости от выбранных технологий и инструментов обучение, охватывающее как концепции, так и инструменты, будет в значительной степени способствовать успешной DevOps-миграции на микросервисы.