Корпоративный мир стремительно движется к микросервисам. Это может ускорить разработку «хаосозащищенных» сервисных сеток.

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

Похоже, что корпоративные ИТ-подразделения, как показало недавнее исследование, используют оба пути. Опрос, проведенный Red Hat среди пользовательской базы своих продуктов Red Hat JBoss Middleware и Red Hat OpenShift, показал, что 69% респондентов задействуют микросервисы как для новых приложений, так и для перестройки существующих. «Эти данные говорят о том, что микросервисы являются ценным подспорьем пользователей во всех аспектах их работы над цифровой трансформацией — занимаются ли они только обновлением своего прежнего портфеля приложений или продвигают новые инициативы», — констатирует автор отчета Сезар Сааведра.

Порядочная часть ИТ-менеджеров довольно быстро осознала преимущества внедрения микросервисов. Треть опрошенных (33%) сообщили, что они убедились в этих преимуществах через 2-6 месяцев после ввода технологии в действие. На первом месте отмечается лучшая реализация видения Agile и DevOps в форме непрерывной интеграции и непрерывного развертывания (CI/CD). Другими плюсами разбиения приложений на миниатюрные микросервисы видятся лучшая масштабируемость, укороченное время выхода на рынок, более высокая продуктивность разработчиков и сокращение затрат времени на отладку и техническое обслуживание.

Микросервисы — а если идти дальше, контейнеры — играют огромную роль в переориентации подходов на повышенную отказоустойчивость корпоративной инфраструктуры подобно тому, как высокая степень распределенности Интернета, а ныне и блокчейн, помогает избежать аварийных отказов. Так, Астазия Майерс, венчурный капиталист из Redpoint Ventures, считает, что микросервисы являются витриной, за которой скрываются «сервисные сетки» (service meshes). Микросервисы и контейнеры, уже не развертываемые последовательным или двухточечным образом, обеспечивают функционирование сервисных сеток, которые «могут помогать управлять трафиком через обнаружение сервисов, маршрутизацию, балансировку нагрузки, проверку работоспособности и обеспечение видимости того, как работает инфраструктура, — отмечает Майерс. — Сервисные сетки пытаются укротить сложности непокорных контейнеров. Мы еще не наблюдаем их широкого распространения, но знаем о компаниях, использующих их в продуктивной среде. К тому же сервисные сетки не связаны исключительно со средами микросервисов или Kubernetes, но также приложимы к виртуальным машинам и бессерверным средам».

Сервисные сетки и их микросервисные и контейнерные компоненты также являются базой для сравнительно новой вещи с крутым названием «chaos engineering», или, как формулирует Майерс, «дисциплины экспериментирования с распределенной системой в целях убедиться в ее способности выдерживать турбулентные условия». Иными словами, здесь подразумевается умышленное вмешательство в работу частей распределенных систем, чтобы увидеть, как они себя при этом поведут. Концепция chaos engineering была выкристаллизована Netflix и позднее использована на практике Amazon, Google, Microsoft и Facebook, добавляет Майерс. «Chaos engineering экспериментирует с системой, чтобы повысить уверенность в ее способности выдерживать сложные условия эксплуатации, — пишет она. — Хотя ломать системы, возможно, забавное занятие, это не всегда бывает продуктивным или дает полезную информацию. Chaos engineering подразумевает более широкий спектр воздействий, включающий не только преднамеренные аварии, но и такие факторы, как пиковые выбросы трафика, необычные комбинации запросов и тому подобное, чтобы вскрыть существующие проблемы».

Конечно, создание или разъединение приложений в форме оркестрованных ансамблей слабосвязанных микросервисов — задача, требующая времени. Как свидетельствует опрос Red Hat, проблемы в реализации микросервисов требуют кооперации с корпоративными менеджерами и конечными пользователями в целях того, чтобы создаваемые сервисы могли эксплуатироваться сообща и использоваться повторно. Наиболее существенной проблемой является преодоление консерватизма корпоративной культуры и организационных неурядиц. К дополнительным вопросам технического плана относятся диагностика и мониторинг микросервисов, а также возможность выделения времени и ресурсов для построения, тестирования и поддержания рабочего состояния соответствующей инфраструктуры.

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