Развертывайте в облаке, но не полагайтесь на проприетарные решения

Прошло много времени с тех пор, как обслуживание собственных серверов было лучшим способом развертывания службы. GCP и AWS — явные победители в этой области. Но, как и все хорошие вещи, не переусердствуйте. Есть много сервисов, от которых стоит держаться подальше. Вы хотите предотвратить привязку к поставщику, чтобы при необходимости можно было перейти к конкуренту. Что еще более важно, часто есть более качественные и дешевые решения, если вы можете свернуть их самостоятельно. В этой статье приведены несколько примеров компромиссов.

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

Приведу два конкретных примера. Общее машинное обучение является одним из примеров. Глядя на платформу искусственного интеллекта Google, которая настраивает ваш конвейер данных, было бы рискованно инвестировать в подобную настройку, если она является ядром вашего приложения. Настройка чего-то на заказ, более подходящего для ваших нужд, с использованием потока keras/tensor, скорее всего, поможет вам лучше в долгосрочной перспективе. Другим хорошим примером этого являются бухгалтерские книги только для добавления, которые очень популярны в пространстве блокчейна. Амазон предлагает QLDBкоторая является размещенной базой данных.
Как правило, это может быть нормально для стандартного SQL, но для чего-то более продвинутого, как добавление только регистров, это большой риск для вашего приложения, потому что подобное предложение не так полнофункционально, как некоторые предложения с открытым исходным кодом, и не имеет использование и поддержка этих альтернатив. ИммуДБ это альтернатива с открытым исходным кодом, которая имеет большую поддержку и, вероятно, принесет вам большую прибыль в долгосрочной перспективе.

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

Оригинал статьи размещен на