Неделю назад легла зона в Я.Облаке. Специально подождал пока утихнут страсти и мнения, и будет понятно что случилось.
Кратко. Легло питание.
У всех корпоративных инфраструктурщиков сразу вопрос - а что, ДГУ не запустились?
ДГУ в проекте даже не были предусмотрены. И нет, это не ошибка, это вполне взвешенное решение от проектировщиков Я.Облака.
Много лет я вижу что на конференциях, что у заказчиков, тему от облачных провайдеров "да зачем вам свое ИТ, приходите к нам, у нас железо, ЦОДы и спецы."
И следом ррраз - коммерческое предложение с очень привлекательной ценой в месяц против каких то чудовищных сотен миллионов или даже миллиардов рублей за собственный онпрем ЦОД.
И вот здесь и кроется интересный момент в сравнении.
Онпрем можно построить с любой заданной степенью надежности, математически доказанной. Нужна устойчивость от катастроф - построим метрокластер, репликацию, что угодно. Да, это стоит денег, это часто очень дорого. Но при этом с минимальными, а то и вообще без изменений ландшафта ПО. Это инфраструктурный проект, почти не затрагивающий прикладной слой.
Мы поставим ИБП, ДГУ, лазерную связь, спутниковую - все это может быть реализовано в онпрем, если ведет к снижению простоев и потерь данных. Но дорого и очень много капитальных затрат + сроки реализации.
Облако очень удобно, минимальные стартовые затраты, оплата по факту, ничего строить не надо, доступно сразу.
Облако надежнее и лучше пока нет своей инфраструктуры и инфраструктурщиков, а есть только пара-тройка гениальных программистов в стартапе.
Но по мере роста сложности и объемов бизнеса начинают вставать вопросы надежности. И здесь мы упираемся в термины "оферта" и "SLA", а конкретно уровня штрафных санкций за нарушение SLA.
Если в онпреме мы строим инфраструктуру, не ограничивая уровень ответственности, а считая прямые убытки от простоев / потери данных, то облаку все это не требуется. Все это ограничено 15-30%, ну пусть даже 100% (что почти нереально) одного месячного платежа. И соответственно нет никакого резона строить инфраструктуру облака, которая будет дороже, чем возможные штрафные санкции в виде скидки размером в месячный платеж.
И вот тут мы и приходим к вопросу почему у Я.Облака ДГУ просто нет в проекте. А есть вероятности выхода из строя питающих подстанций и стоимость простоя при маловероятном выходе из строя сразу двух. Матожидание, если в терминах теории вероятности. Стоимость ДГУ попросту кратно превышает ответственность, поэтому ДГУ там не нужны.
Как же тогда обеспечивать надежность? О, ну тут просто - вы просто берете и переписываете весь прикладной слой, чтобы он работал в двух, трех зонах доступности в асинхронном режиме. Ведь между зонами сеть не позволяет делать метрокластеры и работать синхронно, слишком разнесены зоны географически.
А в момент переписывания вы разумеется берете значимое количество "managed" сервисов облака. Зачем брать только ресурсы и строить все балансировщики, БД, хранение? Берем их в готовом виде и строимся уже не в IaaS, а в PaaS. В нескольких зонах. И живем, все у нас прекрасно.
Пока не захотим съехать в другое облако или даже в онпрем. Почему мы же мы можем захотеть съехать в онпрем?
1. Мы слишком выросли, своя инфраструктура становится в разы дешевле облака.
- Пример Dropbox. 100% выросший в AWS был вынужден не то что инфраструктуру свою строить, а начать покупать магистральных провайдеров. Слишком вырос трафик и популярность.
2. Требования регулятора, опасность полит. плана.
- Пример AWS vs Parler.
3. и еще много вариантов
Ключевой момент. Облако - это не про технологическое лидерство, это про как максимально сэкономить и снизить стоимость MHz, GB RAM, TB хранения, чтобы перепродать дороже. Вплоть до отказов от ДГУ и вообще резервирования, если это поможет продаваться.
И если у вас нет своих инфраструктурщиков, которые будут понимать как и где может развалиться ваша виртуальная облачная инфраструктура, и знающих как построена физика внизу, чтобы вовремя вас предостеречь - может быть мучительно больно.
Кратко. Легло питание.
У всех корпоративных инфраструктурщиков сразу вопрос - а что, ДГУ не запустились?
- Пэйн, я ДГУ не вижу!
- А их и нет!
ДГУ в проекте даже не были предусмотрены. И нет, это не ошибка, это вполне взвешенное решение от проектировщиков Я.Облака.
Много лет я вижу что на конференциях, что у заказчиков, тему от облачных провайдеров "да зачем вам свое ИТ, приходите к нам, у нас железо, ЦОДы и спецы."
И следом ррраз - коммерческое предложение с очень привлекательной ценой в месяц против каких то чудовищных сотен миллионов или даже миллиардов рублей за собственный онпрем ЦОД.
И вот здесь и кроется интересный момент в сравнении.
Онпрем можно построить с любой заданной степенью надежности, математически доказанной. Нужна устойчивость от катастроф - построим метрокластер, репликацию, что угодно. Да, это стоит денег, это часто очень дорого. Но при этом с минимальными, а то и вообще без изменений ландшафта ПО. Это инфраструктурный проект, почти не затрагивающий прикладной слой.
Мы поставим ИБП, ДГУ, лазерную связь, спутниковую - все это может быть реализовано в онпрем, если ведет к снижению простоев и потерь данных. Но дорого и очень много капитальных затрат + сроки реализации.
Облако очень удобно, минимальные стартовые затраты, оплата по факту, ничего строить не надо, доступно сразу.
Облако надежнее и лучше пока нет своей инфраструктуры и инфраструктурщиков, а есть только пара-тройка гениальных программистов в стартапе.
Но по мере роста сложности и объемов бизнеса начинают вставать вопросы надежности. И здесь мы упираемся в термины "оферта" и "SLA", а конкретно уровня штрафных санкций за нарушение SLA.
Если в онпреме мы строим инфраструктуру, не ограничивая уровень ответственности, а считая прямые убытки от простоев / потери данных, то облаку все это не требуется. Все это ограничено 15-30%, ну пусть даже 100% (что почти нереально) одного месячного платежа. И соответственно нет никакого резона строить инфраструктуру облака, которая будет дороже, чем возможные штрафные санкции в виде скидки размером в месячный платеж.
И вот тут мы и приходим к вопросу почему у Я.Облака ДГУ просто нет в проекте. А есть вероятности выхода из строя питающих подстанций и стоимость простоя при маловероятном выходе из строя сразу двух. Матожидание, если в терминах теории вероятности. Стоимость ДГУ попросту кратно превышает ответственность, поэтому ДГУ там не нужны.
Как же тогда обеспечивать надежность? О, ну тут просто - вы просто берете и переписываете весь прикладной слой, чтобы он работал в двух, трех зонах доступности в асинхронном режиме. Ведь между зонами сеть не позволяет делать метрокластеры и работать синхронно, слишком разнесены зоны географически.
А в момент переписывания вы разумеется берете значимое количество "managed" сервисов облака. Зачем брать только ресурсы и строить все балансировщики, БД, хранение? Берем их в готовом виде и строимся уже не в IaaS, а в PaaS. В нескольких зонах. И живем, все у нас прекрасно.
Пока не захотим съехать в другое облако или даже в онпрем. Почему мы же мы можем захотеть съехать в онпрем?
1. Мы слишком выросли, своя инфраструктура становится в разы дешевле облака.
- Пример Dropbox. 100% выросший в AWS был вынужден не то что инфраструктуру свою строить, а начать покупать магистральных провайдеров. Слишком вырос трафик и популярность.
2. Требования регулятора, опасность полит. плана.
- Пример AWS vs Parler.
3. и еще много вариантов
Ключевой момент. Облако - это не про технологическое лидерство, это про как максимально сэкономить и снизить стоимость MHz, GB RAM, TB хранения, чтобы перепродать дороже. Вплоть до отказов от ДГУ и вообще резервирования, если это поможет продаваться.
И если у вас нет своих инфраструктурщиков, которые будут понимать как и где может развалиться ваша виртуальная облачная инфраструктура, и знающих как построена физика внизу, чтобы вовремя вас предостеречь - может быть мучительно больно.