Технический директор MongoDB Марк Портер обсуждает на портале InformationWeek подходы к созданию гибких инженерных команд для поддержки мультиоблачных сред.

Тот факт, что Гамельнский крысолов завлекает многие инженерные команды в мираж снижения производительности в виде мультиоблачных агностических фреймворков, вызывает обеспокоенность и наверняка отразится на нашей способности к инновациям. Сегодня более 70% компаний работают в нескольких облаках. При этом многие из них по-прежнему выполняют рабочие нагрузки и на локальных платформах. В ответ на эту все более сложную среду предприятия часто пытаются абстрагировать свою архитектуру, используя единый набор высокоуровневых инструментов и интерфейсов, которые (теоретически) делают все их приложения и операции якобы агностическими, или «независимыми от облака».

Прежде чем объяснить, почему это ошибка, нужно понять, почему компании вообще переходят на мультиоблачные технологии. Времена трех гиперскейлеров прошли. Такие провайдеры, как Tencent, Alibaba и OVH, бросают вызов «большой тройке» как по возможностям, так и по географическому охвату. Кроме того, страны принимают законы о суверенитете данных, которые требуют, чтобы определенные данные оставались в пределах их физических границ. Одновременно с этим высокоскоростные мобильные сети пятого поколения со сверхнизкой задержкой двигают вычислительные возможности на периферию. И наконец, что еще больше усложняет ситуацию, многие компании применяют гибридный облачный подход, сохраняя некоторые части своей инфраструктуры онпремис, тогда как другие части переносят в облако. Таким образом, если вы хотите быть на переднем крае технической революции, недостаточно просто быть в мультиоблаке, в облаке нужно быть гибким.

Что же делать инженеру в этом мультиоблачном хаосе? К примеру, можно выбрать только одно облако. Но это очень рискованное бизнес-решение. Оно ограничивает доступ к инновациям, затрудняет соблюдение постоянно меняющихся законов о суверенитете данных и привязывает предприятие к одному поставщику для всех его вычислительных потребностей. (Помните, что единственный поставщик облачных услуг может видеть журналы входящих и исходящих данных и может назначать соответствующую цену на услуги).

Также заманчиво создать уровень абстракции, который сведет все облака к их самым базовым предложениям: вычислениям, хранению, сетям. Но использование одних и тех же контейнеров и других мультиоблачных фреймворков может ограничить инновации и погубить перспективную разработку, потому что вы потеряете доступ к управляемым услугам, предлагаемым различными облачными провайдерами, к примеру, специфическим функциям хранения, функция инстансов или даже целым сервисам, таким как ИИ/МО, которые просто невозможно абстрагировать. В итоге вы платите премиум-цену только за самые базовые функции облака. Это все равно что попросить свою команду выиграть «24 часа Ле-Мана», разрешив ей построить автомобиль только с педалью газа, четырьмя колесами и лобовым стеклом.

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

  • во-первых, позвольте рабочей нагрузке диктовать, в каком облаке (или облаках) она будет размещаться. При выборе места проведения вычислений можно руководствоваться массой соображений: географический регион, надежность, соответствие требованиям, производительность. Пусть стратегический замысел каждой рабочей нагрузки определяет требования ваших потребностей в облачных вычислениях;
  • во-вторых, пользуйтесь лучшими сервисами везде, где это возможно. Да, использование различных сервисов в разных облаках несет когнитивную нагрузку. Если вы можете использовать один и тот же сервис во всех облаках (и это лучший сервис, доступный вам во всех облаках), тем лучше;
  • в-третьих, сосредоточьте свои команды на проектировании для каждой среды с максимальной отдачей. И будьте скептичны, когда слышите слова «агностический», «фреймворк» или «универсальный». Очевидно, что хорошая архитектура и инструменты необходимы, но не позволяйте им стать центром внимания ваших команд, иначе вы потеряете конкурентное преимущество.

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

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