В мире бизнеса разворачиваются нешуточные дебаты: стороны делятся на тех, кто за использование всех удобств публичных облаков, и тех, кто уже заметил их «негибкость» и теперь стремится к все большей степени независимости от подобных инструментов. Как найти баланс между удобством и стабильностью и когда что важнее? Разбираемся вместе.
Кому сегодня принадлежит ответственность за сохранность данных
В последние пару десятилетий всё больше компаний переводят или создают свою инфраструктуру в публичных облаках: Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure и много-много других, менее популярных. Когда такой подход только появлялся, а платформы стартовали и набирали популярность, многие эксперты, да и компании из ИТ-сферы нарекали их не просто революционными инструментами, а даже «убийцами DevOps-инженеров». Но, как это обычно бывает, люди, которые хотят приносить домой деньги, просто обучаются новому и становятся ещё более крутыми специалистами.
Учитывая, что в ИТ сотрудники-технари в целом привыкли постоянно меняться и обучаться, «рыночек порешал» и в этот раз. DevOps-инженеры, когда-то работавшие в локальной инфраструктуре, выучили кнопки в облаках, научились декларировать инфраструктуру как код в «простыни» и благополучно забыли о том, чтобы протирать серверные стойки, пытаясь не задеть важный провод, уронив продакшн. Теперь пыльная и, в большинстве своём, админская работа (уход за серверами, нарезка виртуальных машин и т. д.) отправляется к вендору. Он обещает нам 10/10, 99,99%, сверхстабильность и т. п. И если нехороший сотрудник перепутает провода в серверной, то это будет ответственность облака. За это мы ему и платим.
Особенности использования публичных облаков
С ответственностью разобрались. Но наверняка же есть какие-то сложности и особенности в этих ваших публичных облаках? Конечно есть! И их много.
Один из таких примеров — возникновение зависимости целой инфраструктуры от всего лишь одного инструмента. Допустим мы захотели разместить эту самую инфраструктуру в публичном облаке (до этого инфраструктуры не было, компанию создали вчера). Причины могут быть разными: от рекомендации консалтинга до «ну, просто модно». Выбор пал на GCP. И очень нам понравился там такой сервис, как Pub/Sub, который является замечательным техническим решением в качестве брокера очередей. Чудесно, серверы созданы, Kubernetes крутится, приложение разворачивается. Все прекрасно работает. Но вот проходит год, а может два, и по какой-то причине (цены в облаке взлетели, инвестор попросил, Google закрылся и т. д.) появляется необходимость выбрать другое облако и переехать. Инженеры садятся за расчёты и начинают планировать, сколько стоит миграция. И вот тут выясняется, что Pub/Sub не существует вне GCP. Да, конечно, есть аналоги. Если это AWS, то с очередями могут поработать SNS и SQS, если Azure, то Event Hubs или Service Bus. А возможно это переезд в локальную инфраструктуру, и нативных сервисов, как у облаков, нет. И здесь мы можем вспомнить Kafka.
Впрочем, если мы хотим переехать с одного брокера на какой-то другой, умельцы на GitHub или иногда авторы брокера всё же стараются проработать этот момент и создают всякого рода адаптеры для интеграции. Но конечно же это чревато раздуванием инфраструктуры и усложнением архитектуры. Помимо этого, появляется дополнительная работа для инженеров, а значит траты времени и денег, которые можно было предотвратить.
Как сохранять независимость
Как же мы могли поступить в данной ситуации? Просто поставить Kafka изначально. Да, у неё не было бы красивых кнопочек в интерфейсе облака (хотя можно и нарисовать), но, сохранив все конфиги, мы могли бы переехать откуда угодно куда угодно, лишь поменяв адреса старых виртуальных машин на адреса новых. Или вообще одну единственную переменную кластера, если Kafka жила в контейнерах (k8s, Swarm, OpenShift и т. д.).
И это только один пример для одного инструмента — брокера сообщений. На деле же таких примеров много.
Сравним инструменты Amazon:
- Amazon RDS (база данных). Аналоги: Google Cloud SQL, Azure SQL Database. В целом — это всё SQL-базы данных, но внутренние функции всё же часто отличаются, и можно не найти функцию из AWS в GCP и наоборот. Но мы можем просто поставить PostgreSQL или MySQL и сделать нашу БД почти независимой от размещения.
- AWS RedShift (анализ данных). Аналоги: BigQuery, Synapce Analytics. Здесь вообще разные подходы к аналитике, хранению и запросу больших данных. Интерфейс, очевидно, различается ещё сильнее. Можно использовать Apache Hive и не думать о переездах как о чём-то страшном.
- AWS CloudFormation (описание инфраструктуры как код). Аналоги редко используются, но вообще существуют: Google Cloud Deployment Manager, ARM. У всех троих разный формат, хотя CloudFormation очень схож с OpenStack Heat (это если вы настолько преисполнились, что свои собственные приватные облака клепаете). Универсальный инструмент — конечно же Terraform. Он позиционируется как инструмент для работы в облаках, но к локальной инфраструктуре тоже можно прикрутить.
- А ещё Amazon S3, AWS Lambda, Amazon SNS и т. д. Много их.
Трудные решения, которые стоит принимать
Вернёмся к нашему переезду, а точнее к нашим инженерам, которые выясняют стоимость миграции. Что же они насчитают?
1. Общее время миграции увеличивается в несколько раз. Не все пункты будут задействованы в одном конкретном случае, но наши инженеры абстрактные, поэтому варианты тоже для абстрактных разных ситуаций:
- время на получение экспертизы в инструменте-аналоге;
- время на создание промежуточных состояний работы инфраструктуры;
- время на траблшутинг (в перспективе архитектура слегка раздуется, количество элементов вырастет, поиск проблемы станет дольше);
- время на поиск и наем специалиста, который имеет экспертизу и может поднять наш аналог (опционально, если пойти другим путём).
2. Расход на миграцию также увеличивается:
- нужно как-то сохранить часть старой инфраструктуры, и эта часть где-то должна жить;
- докупка дополнительных курсов для инженеров (если мы не берём дополнительного инженера даже на аутсорс);
- даже если мы не берём нового инженера, время старого инженера мы тратим, а как известно время — деньги;
- мы всё-таки можем взять нового инженера, и он будет стоить денег;
- возможно условный адаптер для изменения будет стоить некоторых денег (например если этот адаптер не опенсорсный, а сделанный специально платформой для таких ситуаций, но за дополнительную плату).
Разумеется, всё это не очень понравится бизнесу. И это мы еще итоги не затронули. Например, чем это грозит в перспективе (спойлер: дополнительным расходами, легаси и превращением надёжной и уютной инфраструктуры в адское колесо технологий).
Но что же теперь делать? Отказываться от таких классных сервисов, которые придумывают и предоставляют вендоры специально для нас? Коротко: стараться да, не использовать их. Но естественно о таких вещах всегда необходимо думать в перспективе. Возможно, какой-то наворот от условного Azure повысит производительность и надёжность инфраструктуры настолько, что это нивелирует все риски схлопывания этого сервиса. Но лучше, конечно, использовать облака как ЦОДы. Вот это действительно удобно и безопасно. А сервисы лучше брать универсальные. И тогда и на работу будет инженера легче найти. Ведь если использовать публичное облако в основном как ЦОД, то и особая экспертиза по конкретному облаку не требуется. А инженеров, которые имеют экспертизу в Kafka, очевидно, больше, чем тех, кто знает Pub/Sub.
