Я должен знать лучше, чем обращаться к толпе Hacker News за мудростью. Недавно кто-то из HN задал интересный вопрос: «Вы когда-нибудь переключались?» Будучи HN, ответы были далеко не такими интересными. На самом деле относительно немногие люди вообще ответили на вопрос, предпочитая вместо этого отстаивать запуск своих приложений в частных центрах обработки данных. Другие предлагали советы, ориентированные на небольшие магазины, а не на крупные предприятия.
Тем не менее, несмотря на шум, в потоке *был* небольшой сигнал. Если вы хотите получить максимальную отдачу от какого-либо конкретного облака, вам придется покупать его услуги, что, конечно же, усложняет миграцию. О, и если вы думаете, что можете построить лучшее облако, чем гиперскейлеры, вы можете упустить суть.
== Покажите мне кредиты ==
Как только компании решили использовать конкретное облако, что побуждает их двигаться дальше? Читая ответы HN, «кредиты» являются основным мотиватором. Неясно, насколько такая приманка привлекательна для крупных предприятий, но для определенной демографической группы миграция может быть мотивирована «достаточным количеством кредитов Google Cloud [или Azure или AWS] для оправдания перехода». .âÂÂ
К сожалению, этот упрощенный вид анализа затрат и выгод упускает из виду все скрытые затраты на работу в облаке, как подробно описал Дэвид Линтикум.
Как, по-видимому, обнаружил GitLab, кредиты могут стимулировать миграцию, но они не обязательно оплачивают ее. Как описано в комментарии HN: «В GitLab мы перешли с AWS на Azure, а затем на Google Cloud». Зачем вообще отказываться от AWS? Деньги были проблемой, но не потому, что AWS изначально был дороже. Скорее, это была проблема с настройкой: «Как и в большинстве компаний, очень мало внимания уделялось затратам, настройке и т. д. [при запуске с AWS]. В результате мы, по сути, сжигали деньги». Одновременно поступило предложение о бесплатных кредитах Azure, которые «сэкономили бы нам что-то вроде годовой стоимости счетов ( немалые деньги по тем временам
Звучит здорово, правда? âÂÂПереход был довольно болезненным, и ⦠мы сожгли бесплатные кредиты *очень* быстро. â Затем компания решила перейти на Google Cloud (по необъяснимым причинам), и обнаружил, что миграция снова была «сложным процессом».
Что комментатор узнал из этого опыта? âÂÂОглядываясь назад, если бы я собирался основать компанию, я бы, вероятно, остановился на чем-то вроде Hetzner или другого доступного поставщика «голого железа». Облачные сервисы хороши *если* вы используете их сервисы в максимально возможной степени, но я подозреваю, что в 90% случаев это просто становится огромным фактором затрат, а преимущества того не стоят.
Для меня это совершенно неправильный урок.
== Все еще не разбираюсь в облаке ==
Если вы прочитаете всю ветку, вы найдете много уверенных в себе утверждений о том, что самостоятельная облачная служба (на Hetzner или других хостерах выделенных серверов) — это путь. (Здесь, здесь и здесь.) Как говорится, общедоступное облако «медленнее и дороже вашего собственного сервера с огромным отрывом». . Идея о том, что ИТ-специалисты могут легко «превзойти облако» — неверна и не имеет отношения к делу.
Облако никогда не предназначалось для экономии денег. Речь идет о максимальной гибкости и производительности. Как отмечает один комментатор HN: «Я работаю в очень маленькой команде. У нас есть несколько разработчиков, которые также работают операторами. Никто из нас не является и не хочет быть системным администратором. В нашем случае ECS [Elastic Container Service] от Amazon позволяет значительно сэкономить время и деньги. Как? Удалив функции системного администратора, которые раньше приходилось выполнять команде. - Да, большинство проблем, которые у нас были раньше, мог бы решить грамотный сисадмин, но в том-то и дело, что нанять хорошего сисадмина для нас намного дороже. чем платить немного больше Amazon и просто говорить им: «Пожалуйста, запустите эти контейнеры с этой конфигурацией».
Он делает облако правильно.
Другие предполагают, что, перейдя на бессерверные варианты, они еще больше уменьшат потребность в системных администраторах. Да, чем больше вы копаетесь в услугах, уникальных для конкретного облака, тем труднее мигрировать, независимо от того, сколько кредитов вам выдает провайдер. Но, возможно, тем меньше у вас будет желания мигрировать, если ваши разработчики значительно более продуктивны, потому что они не изобретают инфраструктурные колеса все время.
Одна компания явно пыталась избежать привязки к какому-либо конкретному облаку. «Мы с самого начала разрабатывали наш продукт для развертывания на 3AWS, Azure, IBM». Как так? «Придерживаясь наименьшего общего знаменателя, которым был FaaS/IaaS ([AWS] Lambda, [Amazon] S3, [Amazon] API [Gateway], Kubernetes Звучит просто, правда? было, конечно, нелегко. Мы также проигнорировали инструменты, которые могли бы нам сильно помочь [если бы мы остались] с одним облаком, чтобы быть мультиоблачным». âÂÂПеремещение между заданными общими функциями возможно, но это определенно не пара кликов или пара заданий Jenkins. Перемещение между — это работа на полный рабочий день. , теперь в Azure, потребует времени и обучения. А переход между AWS IAM и разрешением Azure [Active Directory]? Время, время и время».
Иными словами, мультиоблако реализовать непросто, равно как и миграцию. Означает ли это, что ни то, ни другое в конечном итоге того не стоит? Не обязательно. По словам Майлза Уорда, технического директора SADA (ключевого партнера Google Cloud), могут быть веские причины для перехода в другое облако. âÂÂДля многих это просто простота использования и эффективность для выполнения задач; для других это внимание и партнерство; для третьей когорты это абсурдные ценовые преимущества; и, в-четвертых, это производительность и надежность». Таким образом, когда «клиенты видят пробелы в одной или многих из этих четырех областей, они переходят на новый уровень». .âÂÂ
Вероятно, Уорд прав: *могут быть* веские причины для миграции. Просто обязательно проведите полный анализ общей стоимости владения переездом, которая должна выходить далеко за рамки «cloud X предлагает мне 50 000 долларов в кредит». Кроме того, прежде чем вы решите развернуть собственное облако, стоит учесть расходы, связанные с управлением всей вашей собственной инфраструктурой.
