LINUX.ORG.RU
ФорумTalks

Выбор SaaS, PaaS, IaaS или локальная инфра.

 , , , ,


0

1

Дорогой 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, но там еще к тому же появляется возможность упрощенного горизонтального масштабирования.

Безопасность.

К сожалению, VM не является панацей с точки зрения безопасности и надежной изоляции кода гостевой системы от хоста, а значит и других гостевых машин. В поисковиках можно найти упоминания exploit-ов типа escape (to host) from VM. И уж тем более контейнеры не являются защитой от хакеров в плане изоляции микросервисов, но зато они прекрасно изолируют контейнеры, в которых нет злого умысла в коде приложений, защищают от ошибок программистов, мейнтейнеров пакетов софта и администраторов от непреднамеренной попытки софта или скриптов негативно повлиять на окружение (например, по ошибке удалить нужный файл системной библиотеки или избыточного потребления каких-либо ресурсов).

Бэкапы.

Бэкапить на ленты - хорошая практика, потому что каждый экземпляр ленты не зависит от какой-либо электроники, привязанной к ней, как в HDD, кроме того лента не такая хрупкая при падениях и ударах. Относительно небольшие объемы данных надежнее всего дублировать еще и на M-DISC (по описанию до 1000 лет хранения данных): https://en.wikipedia.org/wiki/M-DISC Если еще не используется IaC, то конфиги можно хранить хотя бы инструментами типа etckeeper. Но самое простое - это использовать файловую систему с поддержкой создания снэпшотов состояний FS и реплик файловой системы на других хостах для бэкапов. Иногда требуется посмотреть состояние файла, над которым работал сотрудник в прошлом. Поэтому все работы сотрудников лучше хранить в VCS (если они занимают не слишком много места, как например работы видеомонтажеров), или хотя бы в регулярных автоматических снэпшотах FS. Самый быстрый и простой вариант (кроме баз данных) - это остановка софта и снятие снэпшота FS, софт самой СУБД точно также. Для данных СУБД у нас обычно есть механизм Point in Time Recovery (в журналах WAL), но и для некоторых баз данных (если утеря части данных после снэпшота допустима в отдельных случаях) снэпшоты тоже могут быть полезными, потому что откатиться к ним намного быстрее, чем восстанавливаться из бэкапа. В любом случае перед установкой нового софта даже на компьютеры пользователей нужно стараться делать бэкапы файлов, на которые может повлиять обновление, или хотя бы их снэпшот и стараться, чтобы длительность его создания не превышала небольшого времени (например с помощью zfs snapshot). И конечно нужно стремиться по возможности уходить от обычных персональных компьютеров у пользователей к тонким клиентам, тогда админить придется только сервера, что намного легче. При использовании облачных сервисов безусловно в любом случае нужны автоматические регулярные бэкапы данных из облака в свою инфру, при этом нужно использовать безопасное рабочее место администратора с аппаратными криптоключами для аутентификации и многое другое.

Мониторинг.

В случае разбора инцидента удобнее смотреть на проблему из мониторинга с обеих сторон (пользовательской и админской) на момент времени возникновения этого инцидента.

sanyo1234 ()

Ну облака это удобно и круто, но не везде и не под все нагрузки по деньгам выгоднее. Но смотря как считать. Иногда анализ рисков показывает, что риск дешевле принять.

Чего сказать-то хотел?

mikhalich ★★ ()

Я несколько лет работаю исключительно в облаках с инфраструктурой и в основном получаю удовольствие от этого процесса, так как действительно это удобно, ресурсы получить можно почти мгновенно, а использование Infrastructure as Code вкупе с декларативным подходом описания ресурсов заменяет низкоуровневую документацию ресурсов в обороте. Настройка же сетевого взаимодействия компонентов сети гораздо проще, нежели настройка реальных железок.

Но бывают и негативные сценарии, например провайдер закрывает один или другой сервис. К примеру, Alibaba Cloud так делает в своём облаке. Ты завязываешься в KMS, а потом они говорят - shared KMS больше нет, будьте любезны покупать dedicated KMS, который работает только в VPC. А то, что у вас serverless и VPC нет в принципе, ну это ваши проблемы, установите.

Irben ★★ ()
Ответ на: комментарий от Irben

Отключить могут всё что угодно, это не аргумент. На сколько отключат? Где отключат? Будет ли в это время электричество у пользователей сервера? Будет ли в это время доступен интернет - как у сервера, так и у его пользователей, или будет связность между сервером и пользователями без интернета (кстати этот вполне рабочий случай превращается в полностью нерабочий если у тебя облако)? Если на небольшое время то бесперебойник для таких случаев используют. Если на долгое и есть всё, кроме электричества у сервера - генератор, но такое очень редко происходит, либо сервер не особо важный в плане аптайма и может полежать.

firkax ★★★ ()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от firkax

Вооот, видишь как много вопросов, на которые необходимо ответить, прежде чем решить вопрос лишь электричества и немного интернета. Поэтому утверждение «Свой сервер лучше всего» считаю неправильным, вообще правильного ответа нет, пока не была произведена оценка требований. В каких-то случаях достаточно использовать малинку, в каких-то необходимо географически распределённые ресурсы.

Irben ★★ ()

Я за полный селфхостинг всего, что физически можно селфхостить не разоряясь по деньгам. Пусть оно даже будет не такое кучерявое, как стороннее. Админ не могу/не хочу - пусть идёт бутылки собирать.

Видел как люди взвыли, когда РКН с блокировками телеги приложил ещё и амазон с гуглопочтой, а офисный почтовик на постфикс-компоте как пахал так и пашет. Где гарантия, что это не повторится, причём с обеих сторон? Платная Телефония от Известных Компаний могла сломаться в выходные ночью, там коллцентр круглосуточный работает, у Известной Компании разбор технических проблем «в течение трёх рабочих дней» и ты даже при желании не можешь туда влезть «руками» и хотя бы попытаться исправить оперативно... Плохо тут только админу, на котором будут злость вымещать за сгоревшее железо на которое деньги надо, в этом плане админу проще хотя бы железо свалить на стороннюю фирму.

yu-boot ★★★ ()
Ответ на: комментарий от Irben

А если электричество отключат?

А если метеорит упадёт? Давно в Москве были жёсткие проблемы с питаловом? А нежёсткие хороший UPS вывезет.

Сетевая доступность - ну затяни себе трёх провайдеров по оптике, четвёртого по радиоканалу и пятого по LTE. И да, ручками настрой переключение и приоритеты. «Это классика, это знать надо» (с) ЗС

yu-boot ★★★ ()
Последнее исправление: yu-boot (всего исправлений: 1)
Ответ на: комментарий от yu-boot

Default city это хорошо, но мы сейчас про какой случай говорим? Когда у мамкиного админа псевдо-сервер под кроватью или крупную компанию с многомиллионными убытками в случае простоя сервера? В первом случае можно перевести сервер в облако и спать спокойно, так как псевдо-сервер шуметь не будет во время сна. Во втором случае слишком дорого и долго строить свои датацентры в разных городах, дешевле и быстрее метнуться в облако. При желании к разным провайдерам, всё равно между регионами трафик платный.

И, да, выше твой же комментарий: «Я за полный селфхостинг всего, что физически можно селфхостить не разоряясь по деньгам» - три провайдера всё же дорого + обвязку для работоспособности сервера / серверов.

Irben ★★ ()
Ответ на: комментарий от Irben

Я про компанию, которой надо «для себя» облако с файлами, сайт, телефонию, почту, корпоративный IM, CRM и прочую бытовуху. Админу головняк да, ну так ему за это зарплату платят. Если не подымать это на офисной пекарне то в идеальных условиях однозначно дороже *aaS (хотя кто запрещает, если комп тянет и бэкапится регулярно?), зато данные всегда у тебя локально в офисе и ты не зависишь от оплаты, политики и закидонов стороннего сервиса, РКН и прочего. В любую проблему ты можешь руками оперативно влезть и исправить, не дожидаясь «три рабочих дня». Что-то в существующих решениях при/до-крутить проще намного.

Я прекрасно понимаю, что лютый хайлоад так подымать неоправданно. Точнее не просто хайлоад, а когда фирма небольшая и бедная, а хайлоад уже нужен.

yu-boot ★★★ ()
Ответ на: комментарий от yu-boot

Писал длинную портянку, почему облако в данном случае может быть хорошим вариантом, но «ты не зависишь от оплаты, политики и закидонов стороннего сервиса, РКН и прочего» не перебить. Если изначально грамотно поднимать сервисы на открытом софте, то никаким другим образом этого не добиться. Но это будет дорого в админо-часах и скорее всего будет зависимость на конкретного админа, хотя добросовестный постарается всё автоматизировать и не будет биться над job security, хорошие специалисты всегда работу найдут.

Irben ★★ ()
Ответ на: комментарий от cobold

Почему «если»? Сервис могут отключить по причине... «а он нам посчитался не нужным».

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от cobold

ТС написал же, что «Еще раз повторю, что абсолютно необходима взаимозаменяемость провайдеров и наличие регулярной локальной реплики данных облачного сервиса, иначе вы - заложник того или иного провайдера и находитесь в состоянии Vendor Lock со всеми вытекающими последствиями, включая геополитические.»

mydibyje ★★ ()
Ответ на: комментарий от mydibyje

Ну так это сразу нужны внешние бэкапы, то есть всё равно уже какой-то трах админу. Полностью всё красиво за денежку на чужом железе и софте, и своё айти вообще туда не прикасается, это таки vendor lock.

yu-boot ★★★ ()
Ответ на: комментарий от Irben

Если изначально грамотно поднимать сервисы на открытом софте, то никаким другим образом этого не добиться

Ну это само собой, к селфхостингу прилагается открытый софт с открытыми стандартами, без этого смысла немного. Хотя, видел по офисам почтовики на взломанном Kerio или Exchange, пока ни у кого не «взрывалось».

yu-boot ★★★ ()
Ответ на: комментарий от Irben

ресурсы получить можно почти мгновенно

«Почти» это как? Быстрее чем на локальной гигабитке? И назад так же быстро заливается?

anc ★★★★★ ()
Ответ на: комментарий от Irben

В каких-то случаях достаточно использовать малинку, в каких-то необходимо географически распределённые ресурсы.

Очень верно.

anc ★★★★★ ()
Ответ на: комментарий от Irben

можно перевести сервер в облако и спать спокойно

Вы только предварительно подпишите договор с компанией которую обслуживаете.

anc ★★★★★ ()
Ответ на: комментарий от anc

Ну кстати да, были же истории успеха, у Яндекса с удаленными клиентскими виртуалками, у клаудмауса. Правда историй про утраченные данные и у компаний с инфрой хватает

cobold ★★★★ ()
Ответ на: комментарий от anc

«Почти» это как? Быстрее чем на локальной гигабитке? И назад так же быстро заливается?

В данном случае под словом «ресурсы» я имел ввиду вычислительные ресурсы - сервер, виртуальная сеть, балансировщик нагрузки и прочее. В случае локальных вычислительных ресурсов самое быстрое - сгонять в ближайший магазин и купить какой-нибудь компьютер.

Irben ★★ ()
Ответ на: комментарий от yu-boot

Хотя, видел по офисам почтовики на взломанном Kerio или Exchange, пока ни у кого не «взрывалось».

Здесь проблема именно в слове «пока». Если продукт перестанет получать обновления безопасности, то рано или поздно можно отхватить большие проблемы. Хотя каждому своё, если начальство согласно с такими рисками и админ - горячий перец, то вперёд.

Irben ★★ ()
Ответ на: комментарий от cobold

Ну кстати да, были же истории успеха, у Яндекса с удаленными клиентскими виртуалками, у клаудмауса. Правда историй про утраченные данные и у компаний с инфрой хватает

Насколько я знаю, виртуалки у облачных провайдеров необходимо расценивать примерно как поды в кубере - нечто, что может в любой момент исчезнуть и необходимо пересоздать. Облако требует другого мышления и подходов к созданию / управлению ресурсами, тогда всё будет фунциклировать должным образом.

Irben ★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)