Дорогой LOR,
Понимаю, что возможно этот топик вызовет очень разные чувства и эмоции у разных читателей, но все же интересно ваше мнение о моем мнении об онтопике. Написал основные свои мысли по этому поводу.
Выбор между SaaS, PaaS, IaaS, On-premises (локальная инфра).
Если ваша полиси безопасности позволяет, то по остальным критериям почти всегда нужно стремиться найти возможность использовать сначала предпочтительно SaaS, если не получится, то PaaS, и только уже потом IaaS, если не получается найти PaaS для вашего требуемого уровня кастомизации. Если компания не специализируется на предоставлении определенного вида сервиса типа SaaS или PaaS, то даже IT отделу лучше заняться более узкоспециализированными задачами из своей предметной области, чем пытаться поднимать подобные сервисы в своей инфре. Можно найти отличные готовые решения типа Yandex 360 или Google WorkSpace Business (не удивлюсь, если у них таким занят целый отдел или несколько отделов для каждого сложного сервиса).
Если вы надеетесь с помощью только отказоустойчивой облачной IaaS добиться отказоустойчивости своих приложений, то HA только инфры недостаточно для отказоустойчивости самого приложения, например из-за возможных багов в приложении, падении его частей из-за нагрузки, эксплойтов и т.п. Проще всего приобрести готовый SaaS уровня business у крупного облачного провайдера, где уже решены вопросы безопасности, HA в кластерах приложений, сохранности и приватности данных (хотя бы частично потому что полностью это очень труднодостижимо даже для провайдеров уровня Google, Amazon, Azure) и т.п. Какой бы надежный не был облачный провайдер, всегда необходимо обеспечить возможность перехода к другому и хранение регулярной бэкап реплики своих данных, иначе из-за критического сбоя провайдера или его изменившейся политики в области блокировки неугодных пользователей можно прийти к очень большим убыткам из-за остановки сервисов и утери своих данных.
При прочих равных условиях, включая намного больше факторов (особенно в области безопасности и High Availability), чем обычно учитывает среднестатистический администратор, SaaS обычно экономичнее других вариантов (PaaS, IaaS, etc.) почти всегда и особенно для случаев достижения высокой степени доступности на уровне 99.999% времени, потому что даже, чтобы нанять только опытных безопасников, которые смогут защитить сервер от зависаний из-за эксплойтов, от утечек данных (что нередко требует специального образования и оборудования в т.ч.) и т.п., стоит относительно дорого и требует относительно много времени для освоения, что обычно недоступно обычным админам без предварительной подготовки. Кроме того одного человека явно недостаточно для качественного администрирования хотя бы даже только одного вида сервиса и обеспечения доступности такого сервиса, нужно как минимум двое для подмены, и то это на пределе их возможностей и надежности системы, т.е. лучше больше для взаимозаменяемости, а это очень дорого при высоких требованиях к квалификации персонала.
Еще раз повторю, что абсолютно необходима взаимозаменяемость провайдеров и наличие регулярной локальной реплики данных облачного сервиса, иначе вы - заложник того или иного провайдера и находитесь в состоянии Vendor Lock со всеми вытекающими последствиями, включая геополитические.
Примеры SaaS: для популярных CMS типа Wordpress обычно можно найти SaaS или PaaS, удовлетворяющий всем требованиям. Для сайта визитки вполне достаточно SaaS, чьим наполнением справится копирайтер или в запущенных случаях эникей. Программисты занимаются программированием. Если программист занимается наполнением сайта, то это уже не программист, а офисный работник по набору текста, хорошо если он еще разбирается в PR и рекламе, что одновременно конечно большая редкость и бессмысленность при узкой специализации.
Пример IaaS: для сильно кастомизируемого сервиса почты можно использовать IRedMail docker container для развертывания в IaaS. Конечно, использование облачных сервисов возможно, только когда полиси безопасности компании разрешает использование облачных сервисов, но очень сомнительно, чтобы какая-то среднестатистическая компания могла самостоятельно обеспечить у себя защищенность данных от хакеров (не от спецслужб) выше, чем крупные облачные сервисы хотя бы из-за разницы в уровне квалификации их сотрудников.
Масштабирование (scaling).
Обычно проще (быстрее и предсказуемее) нарастить объемы виртуального сервера даже on premise, чем физического сервера, путем его миграции на другой уже заранее готовый более мощный хост (при наличии), чем пытаться оперативно проапгрейдить физический сервер. Аналогично относительно несложно масштабировать контейнеры, особенно с помощью автоматизированного оркестратора типа Kubernetes, но там еще к тому же появляется возможность упрощенного горизонтального масштабирования.
