В какой момент вы рассматриваете переход от облака к колокации?
В настоящее время я работаю по цене от 25 до 40 долларов в месяц на AWS. У меня есть около 30 ТБ данных, проиндексированных в Elasticsearch, с рабочим кластером из 4 узлов и еще одним промежуточным кластером из 4 узлов. Каждая система в кластере имеет размер m4.2x, с выделенным 10 ТБ твердотельным накопителем IOPS. У меня есть постоянное одно рабочее место EMR, которое мне нужно выполнить, и я также широко использую Elasticache.
В настоящее время у меня в S3 есть куча данных, которые еще не были проиндексированы, что приведет к тому, что мои 30 ТБ данных превысят 150 ТБ, и я начинаю беспокоиться о своих эксплуатационных расходах. Я только когда-либо управлял инфраструктурой в облаке, поэтому я не очень знаком с колокейшн. Тем не менее, похоже, что для моего случая использования затраты на размещение в конечном итоге будут намного дешевле, чем в AWS.
Кроме того, в команде есть инженеры по инфраструктуре, которые могут выполнять задачи центра обработки данных и т. Д. Итак, я уже плачу за трудовой аспект этого. Мой вопрос: какие факторы учитываются при таком движении? Каковы плюсы и минусы каждого, и имеет ли смысл когда-либо переходить от облачного провайдера, такого как AWS, к colo?
2 ответа
Это не вопрос мнения, это вообще вопрос сравнения двух чисел и определения, что больше.
Вы знаете, каков ваш текущий счет в AWS.
Теперь вам нужно сложить стоимость всего необходимого оборудования, контракты на обслуживание на весь срок его службы (три года, возможно, четыре), стоимость колокации (которую вы узнаете, когда узнаете, сколько оборудования покупаете), а также расходы на персонал по его установке и обслуживанию. Не забывайте SLA; если они хороши, у них тоже будет цена.
Лично я считаю, что каждый, кто тратит на AWS четверть миллиона долларов в год, должен выполнять это упражнение как минимум раз в год. Трудно понять, сколько оборудования вам понадобится, и мы можем оказать лишь ограниченную помощь в этом; но как только это будет сделано, вам, как правило, нужно будет периодически обновлять его в соответствии с любым увеличением требований вашего бизнеса.
Последнее предостережение: если в настоящее время колокейшн кажется вам " намного дешевле ", возможно, вы упускаете одну или несколько из указанных выше затрат или недооцениваете их. Я согласен с тем, что Amazon стремится получать прибыль от удовлетворения ваших потребностей, но у них есть значительная экономия на масштабе, которая может быть недоступна для вас; Я был бы удивлен, если бы одна фигура была намного больше, чем другая.
В какой момент вы рассматриваете возможность перехода из облака в совместное местоположение?
Очень банальный ответ: если вам нужно спросить здесь, то, вероятно, не стоит. Если вы не можете следить за тем, что вам нужно сделать, чтобы заменить облачные предложения Amazon, мы не сможем вам этого сказать.
Немного более длинный ответ будет:
Часто встречающийся финансовый аргумент в пользу использования облака заключается в том, что вы торгуете CAPEX за OPEX. В облаке вы платите за то, что вам нужно, и фактически используете, а не делаете долгосрочные инвестиции (которые отражаются на вашем балансе). В облаке вы также используете инженерные усилия инженеров-провайдеров облачных вычислений, и вам нужно только сосредоточиться на тех областях, где ваша компания действительно добавляет ценность.
Чтобы отойти от облака, вам нужно заранее потратить время / деньги / усилия на создание собственной замещающей инфраструктуры и сервисов, прежде чем вы сможете мигрировать. (Вам не обязательно вкладывать средства в покупку оборудования, вы также можете взять его в аренду.) После создания собственной инфраструктуры ее необходимо поддерживать. Укажите, сколько будет стоить увеличение вашей инфраструктуры, и возможно ли ее уменьшение: что это может стоить / сэкономить.
Мы не можем поставить для вас суммы в евро или долларах и сказать, имеет ли это финансовый смысл.
Помимо финансовых аспектов, при переходе на собственную инфраструктуру могут быть полезны инженерные решения, ваши инженеры могут точно соответствовать вашим потребностям и бизнес-драйверам, а не пытаться приспособиться к стандартным услугам, которые предоставляет Amazon. Риск, который у вас есть, заключается в том, что ваши инженеры не лучше, чем Amazon по созданию и поддержанию вашего полного стека. Совсем иначе использовать существующие сервисы в качестве строительных блоков по сравнению с созданием их с нуля и их обслуживанием.