Cloud Native – революция в мире разработки

“Знаете, почему монолитная архитектура называется «монолитом»? Потому что после нескольких лет разработки он становится настолько тяжелым, что приходится носить его как памятник ошибкам прошлого!”

– ChatGPT

Время (деньги) – самый ценный ресурс современного бизнеса. Чтобы сохранять устойчивость и оставаться в лидерах, организации должны действовать на опережение.

Вместе с определением “Двухскоростное ИТ”, Gartner обратил внимание на Cloud Native – стратегию, которая поможет бизнесу приспосабливаться к быстро меняющимся требованиям рынка. Более 95% цифровых проектов будут развернуты на облачно-нативных платформах к 2025 году по сравнению с 30% в 2021 году.

Микросервисы, контейнеры, облачные технологии – если вы сталкивались с перечисленным, то уже разбираетесь в некоторых аспектах Cloud Native. А что это такое, и как избежать главной ошибки при составлении стратегии внедрения – разберём далее.

Монолит VS Микросервис

Согласно определению Cloud Native Computing Foundation (CNCF):

“Нативные облачные технологии позволяют создавать и запускать масштабируемые приложения в современных и динамичных средах, таких как публичные, частные и гибридные облака. Этот подход иллюстрирует использование контейнеров, сервисных сеток, микросервисов, неизменяемой инфраструктуры и декларативных API”

До появления инструментов Cloud Native, традиционная разработка приложений основывалась на монолитной архитектуре, где все компоненты приложения были взаимосвязаны и взаимозависимы. Это ограничивало гибкость и масштабируемость приложений, усложняло их развертывание и обновление, а также затрудняло применение новых технологий и инноваций.

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

Пирамида Gartner

Для понимания, где вы находитесь и к чему пытаетесь прийти в стратегии Cloud Native, можно использовать пирамиду Gartner.

Она изображает четыре этапа внедрения Cloud Native с точки зрения взаимозависимости бизнеса и технологий, где нижний слой – самая низкая («Технологический разрушитель»), а верхний – бизнес-цель самого высокого уровня («Бизнес-разрушитель»).

Облако как технологический разрушитель, Cloud As Technology Disruptor

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

Облако как инструмент расширения возможностей, Cloud As Capability Enabler

Теперь у вас есть новая технология, и вы можете организовать процессы, которые раньше было трудно реализовать, например, автоматизированное тестирование или CI/CD.

Облако как фактор инноваций, Cloud As Innovation Facilitator

С новыми возможностями у вас есть подходящая среда для стимулирования инноваций. Это значит, что вы можете, например, использовать свою облачную платформу для более быстрого предоставления функций или проводить A/B-тестирование новых функций, чтобы максимизировать отдачу от инвестиций.

Облако как разрушитель бизнеса, Cloud As Business Disruptor

Наиболее продвинутый этап внедрения облачных технологий, когда вы можете использовать результаты предыдущих трех этапов для изменения своей бизнес-модели, например, перейдя на модель SaaS или представив новую линейку продуктов.

Самая большая ошибка

Самая большая ошибка в стратегии Cloud Native – объединение четырех уровней пирамиды в один монолитный объект. То есть, рассматривать все этапы как один и строить планы, исходя из этого.

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

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

Например, компания может документально подтвердить, что ее «переход в облако» осуществляется для того, чтобы перевести свой продукт с модели установки у клиента на более масштабируемую модель SaaS. Это будет высокоуровневое видение, «четвертый уровень» пирамиды. В том же документе может содержаться дорожная карта с описанием реализации остальных уровней. В ней может быть указано, например, какой поставщик облачных услуг выбран, что будет использоваться в качестве платформы для приложений, и какие технологии будут применяться для непрерывной интеграции и доставки.

“Сборная солянка” может привести к тому, что высокоуровневое видение и планы внедрения будут рассматриваться как одна задача. Их следует разделить, поскольку план может значительно измениться по мере проработки остальных трех уровней пирамиды, и это должно быть признано частью общей стратегии. В мировой практике это называют «динамической стратегией»: признание того, что план внедрения может быть итерационным и меняться в зависимости от конкретных потребностей и возможностей бизнеса.

Что же делать?

Определите путь – оптимизация или трансформация

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

– Путь «Замена» (Replacement), который проходит через первый «Технический срыв» (Technical Disruption), может также включать классический путь «Подъем и сдвиг» (Lift and Shift).

– Путь «Облако натив» (Cloud Native) может пересекать как первую, так и вторую фазы. 

– Путь «Трансформация бизнеса» (Business Transformation) может пересекать все четыре фазы.

Пути «восток-запад» можно охарактеризовать как пути «оптимизации», а пути «юг-север» — как пути «трансформации».

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

Видение фиксировано, путь внедрения динамичен

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

Каждая организация уникальна, и по мере прохождения этапов меняется, создавая свои возможности Cloud Native. Это может иметь рекурсивный эффект на всю программу, поскольку различные фазы взаимодействуют друг с другом и с изменяющимися возможностями.

Вы можете защитить себя от риска “монолита”, отделив видение высокого уровня от любого плана внедрения. Если видение описывает, почему проект осуществляется, и должно быть менее подвержено изменениям, то план (или планы) внедрения описывает, как это должно быть сделано, и является более тактическим. Другими словами, внедрение должно происходить по схеме динамической стратегии.

Начните с малого и будьте терпеливы

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

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

Эффективная петля обратной связи

Поскольку стратегия должна быть динамичной, а организационное обучение – приоритетным, важно создать эффективную и действенную петлю обратной связи между всеми сторонами. Добиться этого сложнее, чем может показаться, поскольку в любом контуре обратной связи существует «эффект Златовласки»: слишком много шума, и лидеры разочаровываются в уровне детализации; слишком мало, и руководители среднего звена могут разочароваться, поскольку реальность реализации видения, изложенного лидерами, наталкивается на ограничения внутри и вне проектной группы.

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

Подведём итог

“Что общего между монолитом и лабиринтом? В обоих случаях, если вы захотите изменить что-то, вам придется блуждать по множеству неясных путей, сталкиваться с тупиками и пытаться разобраться, как это все связано и как сделать правильный поворот”

– ChatGPT

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

Cloud Native – это не просто технология, это стратегия, которая способна преобразовать бизнес. Согласно исследованиям Gartner, организации, осуществившие успешный переход к Cloud Native, достигают значительных преимуществ в виде более высокой скорости разработки, масштабируемости, гибкости и безопасности.

В этом убедились и российские компании. О том, как внедрение облачных технологий помогло в 4 раза сократить время и стоимость устранения инцидентов на рабочих местах пользователей рассказали здесь.

Как в 12 раз сократить полную стоимость владения ИТ-инфраструктурой в первый год обслуживания за счет перехода в облако – здесь.

О том, как облако помогает не только защитить ИТ-инфраструктуру, но и выполнить требования законодательства по ФЗ-152 “О персональных данных” без головной боли – тут.