Comments 8
Хочется узнать, с вашего позволения: каковы причины переезда в облако (любое), в котором отсутствуют на момент переезда многие важные фичи. К тому моменту «стабильных» облаков базе той же вмвари было достаточно много, что заставило компанию масштаба Альфы становиться первопроходцем и испытателем preview решений и строить костыли на своей стороне, чтобы получить отсутствующие еще в оьлаке функции?
Не буду говорить, что в Альфе словно бы нет других проблем, кроме как таким лихим образом тестировать новинку - компании виднее. Надеюсь, от все этих переездов и перенастроек туннелей не очень страдали операции для клиентов.
В общем, если бы вы дописали абзац-другой о том, почему ушли в облако, и почему ушли именно в это облако, статья бы выиграла!
Облака на базе vmware безусловно были и являются стабильным решением. На момент пилотирования Яндекс.Облака в нем было больше возможностей, гибкости и технического потенциала, чем в нашем текущем на тот момент облачном провайдере.
Причины переезда в облако это удешевление и повышение скорости разработки, хороший уровень SLA, гибкость, точечное планирование бюджета и безопасность.
Почему именно Яндекс.Облако? Так как это достаточно молодой сервис у нас была и остаётся возможность влияния на его развитие путем формирования запросов на определенные фичи, индивидуальная тарифная сетка и содействие команды Яндекс.Облака так же играют не последнюю роль.
Стоимость разработки, может, и уменьшилась — но обычно это с лихвой компенсируется увеличившимся счётом за обслуживание всего остального.
Ещё интересно, как переезд в облако поспособствовал точному планированию бюджета? Имхо, куда проще расчитывать расходы, располагаясь на собственном железе, чем в облаке, чья «гибкость», являющаяся преимуществом с одной стороны, с другой продуцирует как раз-таки меньшую предсказуемость затрат.
Разумеется, эти «индивидуальные тарифы» теоретически могут быть настолько привлекательны, что перевешивают всё, описанное выше :) Но применимы ли они к общему случаю — компании не столь крупной и известной, просто зашедшей в Я.О «с улицы»?
зависит от времени амортизации , своя инфраструктура тоже амортизируется + кроме инфраструктуры есть ещё софт, многие облачный провайдеры забывают про софт , а soft does matter. Например, нужно S3 хранилище , а в компании его нет , где его взять ? да можно нанять свой саппорт купить железяк и сделать свой S3, но это потеря 1 год времени - > полгода всех убеждать , что нужен S3 , насчитать там какой-то большой бюджет года на три вперёд , потом "нанимаем людей и строим S3". Железки в ЯО норм , но основное это софт ,плюс каналы взаимодействия , например есть Amazon и он очевидно по функционалу богаче , но как и к кому тыкнуться в случае чего там , как построить ландшафт так , чтобы его там внезапно не заблокировали - гораздо большая проблема, поэтому ЯО
можно было конечно, например, "замутить" небольшое своё S3 "опытно-промышленное", чтобы год не ждать , но тоже так всё везде сразу не сделаешь , поэтому облако добавляет возможностей . Сильно ресурсоёмкие вещи ( по ядрам процессоров) в облако пока не тащим , плюс есть различные механизмы оптимизации стоимости при работе с облачной инфраструктурой , поэтому расходы зависят больше от архитектуры продуктов в облаке и качества контроля за расходами
Спасибо за интересный пост.
имеющиеся в работе кластеры были deprecated-версий (снятых с поддержки в Яндекс.Облаке).
Какие именно версии Kubernetes у вас были? Какие главные причины не обновления Kubernetes? Спасибо.
Как мы переезжали на новую сетевую маршрутизацию и Interconnect в Яндекс.Облаке