Чарльз Кастер, старший технический контент-маркетолог компании Cockroach Labs, описывает на портале ITPro Today пять ключевых стратегий создания мультиоблачных приложений.
Развертывание приложений в нескольких облаках становится все более распространенным. В нашем исследовании «State of Multi-Cloud 2024» мы обнаружили, что примерно половина опрошенных нами компаний являются мультиоблачными, и половина из них уже начала экспериментировать со сложными схемами развертывания мультиоблачных приложений, такими как развертывание одной рабочей нагрузки в нескольких облаках.
Однако эти компании часто сталкиваются с тем, что создавать мультиоблачные приложения не так-то просто. Основные поставщики облачных сервисов (CSP) могут предлагать на первый взгляд эквивалентные услуги, но дьявол часто кроется в деталях — даже небольшие, незначительные различия между облаками могут сделать создание приложений, работающих в каждом из них, удивительно сложной (и дорогой) задачей.
В рамках подготовки отчета мы побеседовали с несколькими инженерами-экспертами, которые имеют непосредственный опыт создания мультиоблачных приложений. И хотя мы никогда не скажем, что создавать мультиоблачные приложения легко, вот несколько способов, которые, по словам тех, кто это делал, могут облегчить вам задачу.
Установите отношения с облачным провайдером на ранней стадии
Налаживание работы с новым CSP требует времени. Придется участвовать во встречах и в подготовке контрактов. Чем раньше вы начнете этот процесс, тем меньше вероятность того, что эта волокита повлияет на сроки разработки.
Заблаговременное установление отношений особенно важно, если у вас еще нет собственных специалистов по новому облачному провайдеру или провайдерам, с которыми вы планируете работать. Без внутренних экспертов вам придется больше полагаться на команду поддержки CSP, поэтому стоит начать налаживать эти отношения и укреплять доверие как можно раньше.
Нанимайте людей, которые уже накопили опыт
Одной из основных проблем, связанных с созданием систем в нескольких облаках, является множество мелких различий и идиосинкразий между ними. Инженеры, с которыми мы общались, рассказали, что даже сотрудники службы поддержки CSP иногда не замечают их — в одном случае они подписали проект приложения, не заметив, что оно может нарушить ограничения учетной записи в облаке, что привело к потере нескольких месяцев времени на рефакторинг для решения проблемы после ее обнаруженния.
Никто не может знать все тонкости и нюансы каждого облака, но самый простой способ выявить такие вещи до того, как они станут серьезными проблемами, — поговорить с людьми, которые имеют опыт создания мультиоблачных приложений, подобных тому, что вы пытаетесь создать. Правда, найти и нанять инженеров со значительным опытом создания мультиоблачных приложений нелегко и недешево, но в долгосрочной перспективе это может принести большие дивиденды.
Однако, следуя некоторым другим рекомендациям, приведенным в этой статье, можно уменьшить необходимость найма штатных специалистов. Например:
Выбирайте не зависящие от конкретного облака инструменты
Не так давно создание мультиоблачного приложения означало необходимость самостоятельно решать множество сложных проблем, связанных с тем, чтобы заставить каждое облако работать с вашим приложением. Теперь же сторонние инструменты, созданные для поддержки мультиоблака, широко доступны.
Например, Terraform — это облако-агностический инструмент инфраструктуры как кода, который облегчает управление и оркестровку крупномасштабных инфраструктур в нескольких облаках. Scalr — не зависящий от конкретного облака инструмент, позволяющий использовать единый интерфейс для управления ресурсами на любой облачной платформе. CockroachDB — распределенная база данных SQL, ориентированная на облака.
Лучший инструмент зависит от вашего сценария использования, но существует большое количество инструментов, не зависящих от облака, и их внедрение в ваш стек часто позволяет абстрагироваться от некоторых сложностей работы с каждым конкретным облаком.
Отдайте предпочтение управляемым сервисам
Аналогичным образом, управляемые сервисы могут быть хорошим вариантом для абстрагирования от некоторых сложностей, связанных с развертыванием мультиоблака, чтобы ваша команда могла сосредоточиться на создании вашего продукта. Разумеется, управляемые сервисы стоят недешево, но вам следует сопоставить эту стоимость с тем, во что вам обойдется (с точки зрения времени и денег) самостоятельное управление сервисом, а также с тем, что потребуется для достижения того уровня знаний, который необходим для обеспечения его работоспособности.
Например, если вы в основном используете AWS, но у вас есть несколько рабочих нагрузок баз данных, которые должны выполняться на GCP, разработка или наем специалистов, необходимых для подключения и управления рабочими нагрузками GCP собственными силами, может оказаться весьма дорогостоящими. Возможно, лучше просто выбрать управляемую СУБД DBaaS, не зависящую от облака, и предоставить поставщику возможность позаботиться о том, как оптимизировать работу базы данных в любом облаке или облаках, в которых она должна работать.
Тщательно взвешивайте миграцию; рассмотрите вариант «с нуля»
Конечно, можно попробовать перенести существующее приложение из одного облака в мультиоблако, но такая миграция редко бывает быстрой и простой. Особенно в тех случаях, когда требуется сложное мультиоблачное развертывание — например, выполнение одной рабочей нагрузки в нескольких облаках, — на самом деле может оказаться быстрее и проще просто создать новое приложение, разработанное с нуля для такого развертывания.
Кроме того, если начать с нуля, то будет проще использовать инструменты, не зависящие от облака, в различных частях вашего стека, что избавит вас от необходимости разбираться со сложностями работы в разных облаках.
