Ошибок тут как минимум две.
Первая в том, что Сова повелась на обещания Лисы, что "всё будет просто огонь, гиперконвергенция же!" и не спросила у Бельчонка, который в этом немного разбирается, применим ли перенос сервиса в облако в их конкретном случае. Есть часть сервисов, переносить которые в облака либо совсем нельзя, либо надо их почти с нуля переписывать, чтобы они в облаке хорошо работали. Потому что, если перенести "как есть" то либо работать не будет, либо стоимость услуг "облака" будет такой, что дешевле по-старинке работать.
Вторая - разгон IT-отдела. Облака и аутсорсинг вцелом позволяют хорошо оптимизировать финансовые потоки в том, что касается IT. Но разгонять айтишников совсем - это глупо. Чтобы эффективно решать вопросы в ситуации "у нас всё тормозит" нужен грамотный специалист со стороны заказчика, который может сказать, "что именно всё", тогда специалистам со стороны условного "облака" не нужно будить штатного телепата, а можно работать с вполне понятными техническими вопросами.
Третья, как метко заметил @wrench10x12 - "кабан под магистральным дубом", в комикс не вошла, но актуальности от этого не потеряла. Когда сервис в облаке, а не локально, важность каналов связи (и их резервирования) резко возрастает.
Гиперконвергентную инфраструктуру (это совсем не облако, хотя в некоторых аспектах похоже) используют, именно когда хотят сэкономить на админах за счёт покупки избыточной кучи железа с уже установленным особо умным софтом (кучи однотипных компьютеров, на самом деле). Проблема в том, что для обеспечения надёжности особо умный софт дублирует данные на нескольких компьютерах сразу, в отличие от массивов накопителей (чтобы при отказе просто можно было заменить компьютер, а софт сам восстановит копии на нём). В результате сильно растут задержки операций с хранилищем данных. Это может быть фатально для задач, персонально требующих высокой производительности от базы данных.
Высоконагруженные БД, мягко говоря не стоит выносить в облако. По нескольким причинам. Во первых, у сервис провайдеров далеко не один клиент, и мощности серверов и СХД делятся на всех. Во вторых - свою долю ещё внесёт и задержки на передачу данных по сети.
Ну и, вообще по хорошему, критичные сервисы должны быть на собственном оборудовании. Потому что, например, ляжет канал до сервис-провайдера, и компания мгновенно становится колом.
Ну-ка, расскажите мне как плохо работают высоконапряжённые базы данных в Amazon rds по сравнению с сервером в подсобке на pentium 4.
Ну, сравнил жопу с пальцем. Я же сказал высоконагруженные.
Те, которые в принципе смогут работать на P4 - я бы такими не назвал.
При типичной OLTP нагрузке - как правило бутылочным горлышком становится latency - https://habr.com/post/414269/
Ну и, даже если и помещают такую СУБД у того же амазона, то при этом стараются минимизировать передачу данных по сети через полмира.Ибо задержки по меркам производительности того же CPU просто вечные. Т.е. потребитель - рядом.
Как вообще можно гарантировать latency в виртуальном хранилище, я не представляю. В FullFlash NVMe хранилище, подключённом по SAS или FC ещё более или менее просто. В традиционных дисковых и гибридных системах немного сложнее. А в виртуальном хранилище слишком много переменных для этого надо контролировать.
Вот и я ровно про это говорю. Потому реально высоконагруженные системы как правило на собственных площадках. Покупают себе какую-нибудь Exadata, и ебут друг друга в жопы используют ее под собственные сервисы.

Сова - эффективный менеджер
918 постов9.9K подписчиков
Правила сообщества
Обновлены 18 декабря 2018 16:00 по МСК.
- Тег "Сова - эффективный менеджер" ставится только на авторский комикс, выложенный самим автором.
- Тег "Xander toons" ставится на любой созданный автором Совы (эффективного менеджера) контент, опубликованный или самим автором, или любым другим пользователем.
- Тег "Фанфики об эффективной сове" ставится на все остальное. При этом тег "Xander toons не ставится.
Сообщество следует общим правилам Пикабу, а значит и запреты такие же.