Comments 57
В добавок я вижу суживание специализаций, изобретения костылей типа докера и падение уровня понимания ЭВМ со стороны новоиспеченных программистов, вплоть до непонимания понятия «владелец файла».
Технологий действительно стало больше, они стали специализированней. Каждая стала лучше решать задачи в своей узкой области, но за счёт этого стала требоваться дополнительная работа для её интеграции в соседние области (которые стали ближе).
Это естественный процесс. Без такой специализации (и усложнения интеграции) прогресс бы не двигался вперёд (по крайней мере с такой скоростью), так как нам пришлось бы сопостовимого эффекта жертвовать либо временем либо качеством.
Например, для веба, если вы хотите сделать маленький бложик, вы можете:
- Выбрать генератор статических сайтов и залить полученное на github pages.
- Открыть туториал по Python и Django, за пару часов наклепать сайт с базой, поставить их руками с дефолтными настройками, кинуть туда исходники и всё заработает.
- Подойти к разработке серьёзно. Сразу начать с правильной структуры репозитория, git-flow какой-нибудь. Собирать весь софт в пакеты, выкладывать их в приватный репозиторий (который ещё поднять надо, и, конечно, автоматически), на сервере какой-нибудь докер настроить (и скрипты для настройки сервера), плюс прочее CI/CD, тесты там понаписывать, автоматическое обновление сертификатов, базу настроить и так далее и в том же духе. И чтобы всё в кластере с доступностью в пять девяток.
Третий вариант можно хоть месяц делать, если не полгода, — работы хватит. Получится офигенно крутой и правильный бложик. И можно будет ворчать, что разработка стала медленнее и неудобнее. Но на самом деле это не разрабокта стала медленее, это технологии и подходы выбраны были не те. Не для того масштаба.
Нет, автор как раз видит всё вместе, с исторической точки зрения. И констатирует: (полезного) эффекта нет. Прогресса — нет. Потому что прогресс — это не про гонку версий и усложнение систем, а про повышение эффективности и появление новых возможностей. Чего в действительности не наблюдается.
Наблюдается. При всём моём скептицизме к облачным сервисам, основанном прежде всего на их ценах, технических возможностей получить такие вычислительные ресурсы на короткий срок чуть ли не милисекундах, таких не было
Это не так определяется. Новые возможности — это вот человек не мог раньше летать, а теперь полетел (и дело не только в задаче перемещения — например, аэрофотосъемка не была возможна). Или не мог раньше разговаривать на ходу за сотни километров, а теперь телефоном по радио — может. Доступ же вычислительным ресурсам вполне был и раньше — например, понятие CDN появилось и раньше, как и сервера в дата-центрах — договорился да арендовал.
Да, может показаться, что ускорение доступа к мощностям подпадает под критерий эффективности. Но в действительности надо смотреть не на отдельные мелочи, а опять же на всю картину целиком. В детстве я читал в поднесоветском научпопе такое сравнение, что если бы за полвека авиация развивалась теми же темпами, что IT, то типичный самолёт бы совершал трансатлантический полёт за полчаса, стоил как велосипед и потреблял на это канистру топлива (на память, точно не помню цитату). С тех пор реальное развитие IT сильно замедлилось — например, отзывчивость приложений стала хуже, чем двадцать лет назад, несмотря на возросшие мощности. С точки зрения пользователя никаких новых задач или более эффективного решения старых — не возникло. То есть реальный прогресс наблюдается лишь в отдельных областях, где нижележащие достижения не скомпенсированы массовыми быдлокодерами и менеджерами — на суперкомпьютерах, скажем, в обработке видео… То же самое и с облаками — какую задачу в целом они улучшили, кроме потенциальных улучшений в частности?
Полностью согласен. Мы теряем целостное видение картины мира. Каждый видит свой маленький кусочек ))) и его пилит. Но это может и хорошо. Те люди, которые смогут двигать весь этот ком вперёд, структурно осознать всю систему — они будут на вес золота
А потом такой бложик годами, а то и десятилетиями развивается так, что простейшее изменение требует человеко-неделю на поиск нужного места, человеко-неделю на регресс-тесты, ещё человеко-неделю на фикс регресс-багов и ещё одну на регресс после этих фиксов. Команду в проект невозможно набрать, если не платить за готовность работать с python 2 и django 0.x, правя файлы руками на проде или заливая их по фтп с локали, в 2 раза больше чем за с последними "тройками", и то не надолго.
Засетапить для того же блога на джанге git-flow, пакеты, докер ( не очень понятно зачем и то, и то, но ладно), плюс прочее CI/CD займёт, наверное, несколько дней по аналогичному туториалу на своём или виртуальном железе, но есть наджда, что останется оно в более-менее поддерживаемом состоянии гораздо дольше
Виной всему существующая бизнес модель, которая не изменилась с 19XX-бородатых годов: мы продаем вам платформу, а вы пишите под нее свой бизнес. Обязательным условием продаваемости был vendor-lock — подсадить клиента на свое решение, чтобы миграция на конкурирующее потребовала значительных расходов. Сначала это были дорогущие мейнфреймы. Затем появились ПК, и расцвел рынок проприетарных настольных и серверных ОС. Затем появились кросс-платформенные технологии, и потребовалась концепция — сервера приложений, которая и по сей день отживает свое в энтерпрайзе. Затем появились фреймворки, научившиеся локально стартовать встроенный вебсервер, и потребовалась новая концепция продаваемой платформы — облако, которая включает в себя хостинг и управление инфраструктурой. Облака активно форсились 10-12 лет назад. Затем развитие виртуализации опять сделало приложения независимыми от поставщика услуг, и провайдеры резко начали форсить концепт микросервисов, DevOps-а и serverless архитектуры, под которыми удобнее продавать API к своим сервисам (PaaS, AaaS). В итоге предпринимаются все рекламные усилия, чтобы никогда не дать приложению развернутся на локальной тачке со всеми своими зависимостями, а сделать некий компот из ненужных сервисов, завязанный на API платформы и продаваемые бизнес-решения.
managed k8s вроде активно продвигается, с возможностью запускать "на локальной тачке"
Весь k8s задуман и продвигается с целью пропаганды в массы cloud-решений. И чтобы клиент даже не задумывался о необходимости данной тулзы для своего проекта. Это как в свое время сервер приложений — некоторые люди реально не представляли как java приложение с вебом может работать вне сервера приложений. Теперь точно также не представляют как деплоить без кубернетиса.
Вот всегда останавливало от серьёзного изучения Java необходимость разбираться во всяких томкэтах (или катах?) — вы про это?
Боюсь, что разговор про серьёзные сервера приложений: IBM WebSphere, Oracle WebLogic, JBoss, а не про Apache Tomcat. Но уже давно в этом разбираться не требуется, есть сервера, подключаемые как библиотека.
Томкэт по сути это тот же сервер приложений, только урезанный до веба, и который разделяет все его идеи: запускается отдельно от приложения, ресурсы конфигурирются также отдельно, а само приложение пакуется и деплоится на сервак. К сожалению в экосистеме Java томкэт долгое время это был фактически единственным вебсервером, благодаря чему люди стали использовать альтернативные технологии. Однако ситуация уже давным давно поменялась: есть embedded-сервера (https://www.eclipse.org/jetty/), куча хеви и лайтовых фреймворков для веб разработки с минимальным порогом вхождения (https://javalin.io/).
В идеале задумка провайдеров была задвинуть клиенту за монету свой сервер, на который тот бы смог деплоить свои приложения, и они бы там работали, а провайдер собирал бы за лицензию и поддержку. Но концепт быстро устарел: вместо одного сервера с кучей приложений уже одному приложению требовалось несколько серверов для работы. К тому же люди быстро поняли, что концепция деплоить что-то куда-то стала излишней, а все то, что предлагал сервер приложений либо нафиг не нужно, либо неплохо решалось с помощью сторонних библиотек. И расцвел век фреймворков типа спринга. Но империя нанесла ответный удар ввиде контейнеров и кубернетиса. И теперь хомячкам снова требуется все паковать и куда-то деплоить, чтобы оно там работало. А чтобы это не выглядело совсем по-идиотски, клиента убедили самому раздробить свое приложение по частям, а уже платформа возьмет на себя задачу собрать все снова воедино. И все это безобразие назвали хайповым словом "микросервисы".
Оригинальный взгляд. :) В любом случае понял, что если в мануале "production ready хелловорд в вебе на Java" пишут что-то про томкат, то мануал не очень современный, так? А если про контейнеры и кластеры, то через чур хайповый, да? Supervisor/systemd — норм?
Да, конкретно по томкэту мануалы уже попахивают. Хотя для общего развития полезно ознакомиться с легаси веб стеком джавы (контексты, сервлеты, фильтры, etc). В мире Java сейчас в основном форсят Spring Boot, который (внезапно!) пускает тот же томкэт в embedded-режиме, но никак на него не завязан. На хабре каждая вторая статья в джавовском хабе — это как написать очередной Hello World на спринге с кучей плюшек.
И да, когда контейнеры и кубернетис — это на 90% хайп, ибо сегодня, планируя архитектуру, никто уже не задумывается о необходимости данных тулзов применительно к решаемой задаче. Архитектура большинства систем не настолько сложна, чтобы был необходим промежуточный слой виртуализации и оркестрации сервисов. Контенеризация зачастую излишня: как правило вы выделяете весь виртуальный сервер под конкретный процесс/систему — зачем еще одна операционка внутри другой? Большинство задач оркестрации и сервис дискавери решается средствами самой операционки (либо тупо конфигурационным файлом). Для деплоя и управления обычно хватает ssh. Чуть сложнее инфраструктура или сценарий — есть Ansible. А бездумно пихать микросервисы, k8s и весь девопс в каждый проект, тем самым усложняя себе и другим жизнь, и получая себе на задницу массы новых впечатлений — лишь увеличивает градус неадеквата. Думаю, об этом и была данная статья.
Спасибо за ориентиры в мире Java. Хотя вот с PHP использовать докер мне нравится, когда по ряду причин возможности выделить отдельный виртуальный или реальный сервер под конкретный процесс (насколько в мэйнстримовом PHP можно говорить о процессах)/систему нет. Причём в обе стороны: желаемых процессов/систем много, а сервер один-два, и ресурсов одного сервера недостаточно или он нелинейно дорог — нужно горизонтальное масштабирование или просто какой-никакой fault tolerance. СУБД и подобное не рискну для прода в докере запускать, но вот остальное для современного PHP стэка, включая вроде как Java системы типа ElasticSearch — вполне. Это удобнее (лично для меня) чем все известные мне за десятилетия :) разработки на PHP способы разворачивания, если этим должен заниматься я, если я на проекте кроме роли разработчка и архитектора приложения выполняю роль "девопс-инжнера" (админа, ответственного за эксплуатацию приложения в тесном взаимодействии с разработчиками) и архитектора системы. Будь у меня команда "девопсов" — пускай творят что хотят: вот требования, вот спеки конфигов/енв-переменных. Но пока мне это внедрять и обеспечивать неформальные SLA лучше докера (+композ/сварм+старый добрый баш) я не нашёл. k8s — перебор, если что :)
Совершенно верно, докер большинство используют как систему развертывания, чтобы избежать сложностей с установкой и конфигурацией зависимостей. Одна команда — и тебе поднимается весь готовый эластик без лишней головной боли. В случае некоторых сторонних продуктов и зависимостей это имеет смысл. Но тем не менее для развертывания есть свои тулзы: Chef, Puppet, Terraform, Ansible — докер больше по части виртуализации, которая в большинстве случаев не нужна. На одной хостовой тачке можно поднять кучу процессов — заворачивать каждый в свой контейнер вовсе не обязательно. Многие утверждают, что докер позволяет избежать ада с зависимостями и библиотеками, но во-первых, ОС имеет свой репозиторий и уже как правило предоставляет свежую версию необходимой зависимости, а во-вторых тут есть скрытая угроза в безопасности — контроль над версиями ложится на самих разрабов, которые очень не спешат апдейтить зависимости, пока не случаются проблемы. А контейнер на продакшне сильно затрудняет сторонний security-audit.
У нас в докере поднимается "неубиваемый" кластер из Postgresql, ничего страшного в этом нет. Естественно data-volume-ы замеплены на файловую систему. Тоже compose+swarm. Плюс отдельный контейнер/машина под Elastic. Сервисы деплоятся без контейнеров прямо на тачки при помощи git.
Ансиблем мне нравится подготавливать новый сервер к работе как докер-хост ) И мне кажется, что он прежде всего для подобных задач, как раз для установки софта из стандартных и не очень репозиториев, а не для развертывания in-house приложений в разных средах.
Докер также позволяет избежать части конфликтов разных сервисов на одном сервере за ресурсы типа 80-го порта. Не только он позволяет, конечно. Перенаправление трафика с порта физического или виртуального адаптера на виртуальный не в Докере придумали. Докер в целом лишь обёртка, интерфейс к низкоуровневым фичам ядра ОС. Но как по мне самая удобная из более-менее популярных, не идеальная, но достаточно удобная для массового использования.
Что до контроля версий, то лучше он под контролем разрабов, чем вообще без контроля. Вот была недавно задачка от бизнеса срочно сделать TLS 1.3 на наших сайтах под Ubuntu 16.04, в репах которой слишком старый openssl: выбор был между сборкой свежих nginx+openssl из исходников и запуском контейнера. Пробовал ещё сторонние репы подключить, но конфликтов множество — уж больно много на openssl завязано. А с докером решилось за 15 минут буквально, практически прозрачно для остальной системы после ещё 15 минут игры с симлинками
задачка от бизнеса срочно сделать TLS 1.3
Если на вашем предприятии за актуальностью версий шифрования траффика следит "бизнес", то у меня для вас плохие новости.
Докер также позволяет избежать части конфликтов разных сервисов на одном сервере за ресурсы типа 80-го порта. Н
Позволять — позволяет, но это а) не про безопасность б) это даётся ценой дикого оверхеда по ресурсам (сеть в докере существенно медленнее, чем нативное взаимодействие)
Одна команда — и тебе поднимается весь готовый эластик без лишней головной боли.
Это как минимум не так.
контейнер на продакшне сильно затрудняет сторонний security-audit.
Тоже не так.
Многие утверждают, что докер позволяет избежать ада с зависимостями и библиотеками,
Это так есть и на самом деле. Но докер хорош для python/ruby/nodejs с их помоечной экосистемой. Которую нормально интегрировать в репозиторий операционной системы почти нереально из-за сложности задачи.
У нас на собесе есть отличный вопрос — «как правильно установить ансибл», который и показывает поел ли говна кандидат с условным pip install ansible в системное окружение (это топ #1 ответ), но подразумевается, что и у всех остальных способов установки есть свои недостатки
Контенеризация зачастую излишня: как правило вы выделяете весь виртуальный сервер под конкретный процесс/систему — зачем еще одна операционка внутри другой?
Полностью поддержу. Но если зайти с другой стороны. Скажем, у вас есть куча железа. Но выделять по железку на задачу — ту мач. Значит, тут появляются системы виртуализации, которые позволяют нарезать железки на виртуалки. Но виртуалки — «тяжелые». И здесь выясняется, что если нет гипер требований по изоляции — мы можем поверх того же железа натянуть кубер и управлять контейнерами с БОЛЕЕ ВЫСОКОЙ утилищацией аппаратных ресурсов… Как пример — тот же хадуп я не слышал, чтобы на виртуалках разворачивали, т.к. он сам по себе распределённая система.
Како вывод? Да, хорошо, что есть куча разных технологий, но нужно выбирать технологию под свою задачу, а не наоборот.
И здесь выясняется, что если нет гипер требований по изоляции — мы можем поверх того же железа натянуть кубер и управлять контейнерами с БОЛЕЕ ВЫСОКОЙ утилищацией аппаратных ресурсов…
Вот только кубер здесь необязательное звено. Нередко только уменьшающее утилизацию и аппаратных и человеческих ресурсов для сценариев типа "поднять 100500 сайтиков на одном хосте".
//SYSIN DD *
Или я что-то забыл?
Ну, а еще по поводу страданий автора об интерактивности вспоминается фраза из статьи про настоящих программистов тех времен:
Плохое время отклика не беспокоит настоящего программиста; он получает возможность вздремнуть между трансляциями.
Соответственно, пока количество разработчиков на проекте меньше ± 15 — в микросервисах смысла мало — только overhead дополнительный.
Облака сейчас — это огромный набор функционала. Никто не заставляет пользоваться всем. В самом простом варианте можно использовать облако как удобный хостинг.
Кусаться об лямбды никто не заставляет же.
Про YAML согласен — сейчас не хватает полноценной проверки. Можно ошибиться с индентацией так, что файл формально останется валидным, но по факту не верным.
В целом проблема как всегда одна: бизнес требования. Либо они не достаточно понятны изначально, либо меняются по ходу разработки. Иногда в архитектуру закладывают сразу масштаб, а на деле он оказывается не нужен — получаем бестолковые микросервисы. А может быть наоборот — неповоротливый монолит, которому для работы нужен все более мощный сервак.
Соответственно, пока количество разработчиков на проекте меньше ± 15 — в микросервисах смысла мало — только overhead дополнительный.
Не согласен. Это зависит не только от количества разработчиков, но от их стремления соблюдать модульность, например, и прочую инкапсуляцию. Микросервисы уменьшают соблазн залезть в кишки соседнего модуля, мимо его публичного API — как раз оверхедом, необходимым что опубликовать кишки...
В самом простом варианте можно использовать облако как удобный хостинг.
Только очень дорогой. Если сравнивать AWS с DO, то в пару раз точно VDS (с признаками облака уже) дешевле EC2
Если разработчики не придерживаются хороших практик, то и микросервисы они будут разрабатывать криво (начнут общие бизнес модули использовать, например). Оверхед — на коммуникацию сервисов: Http клиенты, circuit breakers, всякие кодогенераторы для api этих клиентов, трассировка. Все это — много работы. Поэтому я считаю есть некий минимум разработчиков ( не обязательно конкретно озвученное мной число).
Насчёт DO — я его уже вполне облаком считаю. У них уже и кубер есть. Где грань, что облако, а что нет?
У микросервисов много плюсов. Может какой-то оказаться важным и при разработке в одно лицо. Например, возможность писать разные модули на разных языках, более подходящих под задачу.
Действительно уже как облако. Как-то брал всё время там чисто VDS и не заметил развития. Наверное, грань в возможности создавать, менять и освобождать вычислительные и близкие к ним (диски, сети и т. д.) виртуальные ресурсы в больших масштабах без задействования персонала провайдера.
Такое ощущение, что автора завтавили пересесть с уютного Spring'a на Serverless и он сразу пошел изливать свою боль. Из всей статьи я увидел только этот кусок по существу:
Развёртываешь систему, получаешь сообщение об ошибке и входишь в CloudWatch, чтобы понять, что же произошло — всё это выполняется пакетно, как в старые недобрые времена, поэтому процесс идёт медленно. По крайней мере, нам не приходится каждый раз бегать к принтеру, но это довольно красноречиво характеризует прогресс за прошедшие полвека. А, да, и ещё «функция» способна одновременно обрабатывать только один запрос, нам нужно много инстансов, так что получите свой счёт за хостинг AWS — надеюсь, вас не хватит удар. Да, мы обрабатываем нагрузки, с которыми бы справился ваш племянник на своём Raspberry Pi 4, но таково будущее энтерпрайза.
Последние два года я работаю с Serverless и поучаствовал уже в 5 проектах совершенно разной направленности. И я скажу честно — у меня нет никакого желания возвращаться обратно в Spring, после того как я окунулся в этот мир.
- Действительно, удобного удаленного дебага лямб как такового нет. Однако никто не мешает скопировать проблемный ивент и запустить код локально с дебаггером и разбираться сколько душе угодно.
- Мне интересно, получил ли автор свой счет за хостинг от AWS. Цены на лямбды это самая малая часть счета на всех проектах, что я видел. Как правило основной бюджет составляют другие сервисы.
- Не используйте Java в лямбдах. Если нужно удобство разработки — используйте скриптовые языки. Если вот прямо позарез нужна производительность — есть Go runtime.
Вообще у амазоновских лямбд вроде бы есть локальный запуск и дебаг через AWS SAM.
Цены на лямбды это самая малая часть счета на всех проектах, что я видел.
Это если весь проект на AWS. А если, поддавшись хайпу, решили перенести на лямбды только те части приложения на bare metal, которые грузили CPU/RAM тяжелыми асинхронными задачам типа перекодировки 4к+ видео, то:
а) существенную часть счетов составят именно лямбды
б) все счета будут восприниматься как счета за лямбды, потому что без какого-нить API Gateway лямбды снаружи не дернуть нормально и трафик туда-сюда тоже неотъемлемая часть лямбд.
Действительно, для таких задач лямбы будут проигрывать по стоимости у других вариантов. Но ведь в этом и суть AWS — там нет silver bullet, зато есть сотни специализированных сервисов (в том числе и по конвертации видео). Найти связку, удовлетворяющую требованиям наилучшим образом — задача архитектора. А вот опираться на хайп — это почти никогда не заканчивается хорошо.
Я проработал с «Облаком» уже достаточно долго для того, чтобы убедиться, что ему предстоит пройти ещё долгий путь, прежде чем оно станет лучше старой доброй аренды пары серверов и запуска своего ПО на них.
Ну-ну, а высокую доступность волшебные феи обеспечивать будут? Даже если автор предполагает, что нужно сразу писать свой монолит с собственным велосипедом для кластеризации на уровне приложения, то кто ему будет обеспечивать высокую доступность данных, сети? Как мы будем масштабироваться, выводить сервера для обслуживания? А если сервисов не одна штука, а десять, пятьдесят? Потребуются либо дорогие ops и серьёзные вложения в свою инфраструктуру (SAN/HCI, сервера, сеть), либо — внезапно — облако.
Автор — типичный элой, не желающий даже думать об этих ваших морлокских инфраструктурах, которые будут нужны для того, чтобы его код работал так, как нужно бизнесу.
А доступность в шесть девяток и способность обрабатывать миллионы rps в реальном времени всем нужна, да? А "девопсы" дешевые, да?
Облака удовольствие дорогое, но всё чаще встречается что бизнес требует переход в облака, ожидая что скорость разработки системы теми же силами как минимум не уменьшится, а надежность увеличится. Что у конкретного облачного провайдера команда из сотен сервисов безошибочно выберет и сконфигурирует те и только те, которые обеспечат на практике максимальную теоретически возможную эффективность, что счета будут выставляться за реально используемые ресурсы, а лимиты бюджета сработают ровно в тот момент, когда будут превышены. Что своих опсов можно будет разогнать, а программисты сами настроят всё в облаке и будут следить за оптимальностью расходов за него.
Ну-ну, а высокую доступность волшебные феи обеспечивать будут?
По-моему, вы несколько преувеличиваете сложность и дороговизну обеспечения высокой доступности. Поскольку я не специалист по Linux, а потому не могу подробно рассмотреть, как там обстоят дела с этим в нижнем ценовом сегменте, то расскажу про то, что может предложить людям экономным Windows Server во вполне стандартной комплекатции. Это, конечно, не экомом-класс (потому что сама цена на лицензию даже для Standard Edition весьма ощутима), но, по сравнению с ужасами кровавого энтерпрайза, все очень по-божески.
Начнем с отказоустойчивости приложения. Компонент отказоустойчивой (по-русски, точнее, но длиннее — способной обойти отказ, ибо по-английски это failover) кластеризации в эту самую стандартную редакцию встроен уже давно. И для задействования этого средства при написании приложения не нужно делать свой велосипед — достаточно реализовать небольшую DLL для взаимодействия со службой управления кластером. Более того, если приложение позволяет управление собой через COM, то вместо DLL можно ограничиться скриптом на JavaScript (или VBScript). А если приложение реализовано как служба Windows, и настолько просто, что его работоспособность/неработоспособность определяется исключительно по факту того, запущена ли служба, то для использования отказоустойчивой кластеризации можно вообще не писать никакой код: я, например, некогда написал статью про то, как можно сделать потешный (т.е. для развлечений, в бой совать его не надо) кластер DNS на базе стандартной службы из Windows Server. Ну, и для веб-приложений под IIS отказоустойчивая кластеризация тоже возможна (и есть руководство, как это настроить, где-то на сайте Microsoft), хотя для их развертывания в многосерверной конфигурации чаще применяют балансировку нагрузки (в том числе — и встроенную, которая есть в составе Windows Server).
Далее, высокую доступность сети для Windows Server можно обеспечить разными встроеными в него способами. Простейший и самый древний — объединить пару сетевых интерфейсов в виртуальный мост (он понимает STP) и подключить эти интерфейсы к разным коммутаторам, тоже понимающим STP. А кроме этого в Windows Server встроена агрегация сетевых интерфейсов (NIC Teaming) в нескольких вариантах: зависимая и независимая от коммутатора, статическая и динамическая — она тоже обеспечивает устойчивость к отказу сетевого адаптера/кабеля/коммутатора.
С отказоустойчивостью данных, да так чтобы обойтись без единой точки отказа доступа к ним (а не только обеспечить сохранность при отказе диска), если при этом ограничиться чисто Windows Server, немного сложнее. Но и тут вполне можно обойтись без дорогой SAN. Правда, стандартная редакция может предложить только построение на базе нескольких подключенных по iSCSI LUN на недорогих и не отказоустойчивых устройствах хранения (их требуется от 3-х штук) кластерного варианта Storage Spaces, на базе которого уже можно сделать отказоустойчивые виртуальные диски. Решение это несколько неуклюжее и костыльное (т.к. шатно Storage Spaces рассчитан на работу на базе локальных физических дисков), но, в принципе, работоспособное (хотя про необходимую полосу пропускания сети для него забывать нельзя). Но если появляется целесообразность использования более дорогой редакции Datacenter Edition (т.е. если служб становится больше некоего минимума), то в этой редакции есть гиперконвегентный вариант Storage Spaces — Storage Spaces Direct — который можно уже штатно использовать для построения хранилища на локальных дисках серверов без единой точки отказа.
Всё ровно наоборот, автор как раз из тех, кто понимает, как устроены и работают вещи, с нуля, с корней — а не так, как делают хипстеры и зумеры, наворачивающие слои за слоями, не зная основ, ведь так же "быстрее", главное почаще мантры про облака повторять. Ими же волшебники-маги занимаются, облако это не то что пару серверов поднять, это совсем другое! И не падают они никогда (привет Гуглу)!
Технология Serverless: снова привет, 1970-е