Мы в своё время в nvidia считали стоимость размещения "резервного ЦОД" в амазоне, аналогичного нашему сетапу по сбору телеметрии: у нас было 24 физических сервера с Xeon E3-1240v5, 32 гб памяти и ssd на террабайт, это примерный аналог m4.2xlarge. Коробка с 12 такими блейдами тогда стоила 15000 баксов, а EC2 за один такой инстанц без апфронта и 3хлетнего контракта просил 1500 в год. То есть уже к середине второго года эксплуатации решения "на своём железе" мы выходили в плюс с учётом запасов запчастей, сетевой и менеджмент инфраструктуры и избыточности.
Для себя мы тогда сделали выводы, что размещение в облаке оправдано только в случае создания прототипов сервиса, когда сроки поставок оборудования (особенно выходящего за рамки типовой конфигурации) и общая загруженность команд эксплуатации ЦОД или админов не позволяет выкатить сервис в срок
Его сложно поддерживать и на уровне репки и на уровне установленной системы.
Допустим, у нас есть пакет libfoo, за время жизни дистрибутива версия на релизе была версия 1.0.0, в процессе выпускались последовательно обновления до 1.0.4, в таком случае для того, чтобы пользователь в любой момент времени мог обновиться на последнюю версию с любого состояния дистрибутива, нужно либо применять (и хранить на стороне сервера репки) последовательно изменения 1.0.0-> 1.0.1 ... 1.0.4, либо иметь набор патчей 1.0.0->1.0.4, 1.0.1->1.0.4, 1.0.2 ->1.0.4 и т.д. Если мы начнём закладывать ещё и ситуацию "обновление с предыдущей федоры", то тут количество дельт возрастает кратно, а если добавить rawhide, то всё вообще превращается в адЪ. Кроме того, нет гарантии, что пользователь не вносил изменений в файлы пакета.
Информация
В рейтинге
Не участвует
Зарегистрирован
Активность
Специализация
System Administration, Site Reliability Engineer (SRE)
Мы в своё время в nvidia считали стоимость размещения "резервного ЦОД" в амазоне, аналогичного нашему сетапу по сбору телеметрии: у нас было 24 физических сервера с Xeon E3-1240v5, 32 гб памяти и ssd на террабайт, это примерный аналог m4.2xlarge. Коробка с 12 такими блейдами тогда стоила 15000 баксов, а EC2 за один такой инстанц без апфронта и 3хлетнего контракта просил 1500 в год. То есть уже к середине второго года эксплуатации решения "на своём железе" мы выходили в плюс с учётом запасов запчастей, сетевой и менеджмент инфраструктуры и избыточности.
Для себя мы тогда сделали выводы, что размещение в облаке оправдано только в случае создания прототипов сервиса, когда сроки поставок оборудования (особенно выходящего за рамки типовой конфигурации) и общая загруженность команд эксплуатации ЦОД или админов не позволяет выкатить сервис в срок
Его сложно поддерживать и на уровне репки и на уровне установленной системы.
Допустим, у нас есть пакет libfoo, за время жизни дистрибутива версия на релизе была версия 1.0.0, в процессе выпускались последовательно обновления до 1.0.4, в таком случае для того, чтобы пользователь в любой момент времени мог обновиться на последнюю версию с любого состояния дистрибутива, нужно либо применять (и хранить на стороне сервера репки) последовательно изменения 1.0.0-> 1.0.1 ... 1.0.4, либо иметь набор патчей 1.0.0->1.0.4, 1.0.1->1.0.4, 1.0.2 ->1.0.4 и т.д. Если мы начнём закладывать ещё и ситуацию "обновление с предыдущей федоры", то тут количество дельт возрастает кратно, а если добавить rawhide, то всё вообще превращается в адЪ. Кроме того, нет гарантии, что пользователь не вносил изменений в файлы пакета.