Многие не могут позволить Я.сервисы, а их более дешевые конкуренты не так стабильны.
Сомневаюсь, что надежность self-hosted docker swarm выше чем у конкурентов. И не забываем, что распределенный софт (без единой точки отказа) - это крайне сложная задача.
Мы сами сначала сидели на одном сервачке с компоузом и разными сетями, постепенно поднимая мощность, однако постоянные сбои заставили нас попробовать другой хостинг, который также оказался нестабильным.
Без понимания причин и характера сбоев, лично для меня звучит скорее как "пытались на коленках все запускать - было плохо, занялись вопросом плотнее, перешли на docker swarm - стало лучше". Но тогда заслуга тут не в docker swarm, а в "занялись вопросом плотнее".
Говоря про изоляцию, имелось в виду именно про разные сервера для разных окружений (prod/dev).
Разные окружения должны быть полностью изолированы, без общих точек отказа. Т.е. в рамках одного сервера / docker swarm они не должны жить.
В случае отказа, сварм позволит просто подключить новую машинку и на ней все задеплоить (поменяв лейбл деплоя).
Только если речь идет о state-less сервисах или полноценной репликации у сервиса.
Docker swarm я вижу скорее в сценарии с state-less воркерам, на которых выполняются ресурсоемкие задачи. Тогда да, просто масштабировать, выше надежность. Но единые точки отказа остаются - как минимум в виде мастера с централизованными сервисами (как минимум БД, очереди, внешнее API и т.д.).
Также столкнулись с тем, что если падает одна машинка, то о таком инциденте бот хостинга единожды сообщает в лс и дальше молчание...
Внешний мониторинг нужен - на хостера не надейтесь в этом вопросе вообще. Даже 2я нода на этом же хостере - не лучший выбор. Есть бесплатные мониторинги (от selectel, например) - для простых сценариев должно хватить (как минимум проверять доступность).
Отсюда могу сделать вывод, что отказоустойчивость, в таких условиях, явно выше.
Вот не знаю... Docker-compose сейчас в сам docker встраивается, так что надежность с swarm должна быть сравнимой - продукт одной компании (и более чем уверен, механики работы общие). Если с compose были проблемы надежности, то и swarm им же подвержен.
Но пока лично для себя причин перехода с compose на swarm я не понял. Только если ресурсоемкие задачи на отдельных серверах гонять не сильно заморачиваясь с инфраструктурой и доступами.
В какой-то мере масштабирование - да, но без полноценной репликации, больше точек отказа не дадут большую надежность.
Мы говорим о надежности железа или о работоспособности сервиса?
Если железо - да, живучей 3 будет (хотя процент "повышенной живучести" будет небольшой, с учетом того, что хостер один и тот же), то для повышенной надежности сервиса надо полноценно дублировать все сервисы. Не говоря уже о реализации сервисов для работы в распределенном режиме.
Но в статье речь о нескольких серверах из-за проблем масштабирования. Так что это не повышает надежность сервиса, а только понижает - точек отказа становится больше.
Монолитная с докером — если не самый надежный хостинг, то сильно страдает надежность, а с вертикальным расширением сильно растет и цена. Также сложно поддерживать изолированно различные окружения (dev/test/prod).
На мой взгляд, уж лучше начинать с простого docker (docker-compose). И уже потом смотреть на docker swarm.
Цена VPS не сказать что нелинейно растет с масштабом - в два раза более мощный сервер стоит примерно в два раза дороже. Т.е. разницы с двумя серверами особой нет (а если и есть - то зачастую в пользу более мощного сервера).
Пара серверов у ненадежного хостера не сильно выиграют в надежности.
Уж если делить по серверам - то выделять лучше сервер для "офисных" нужд (VPN-ка, Git-хранилище, CI/CD, работа с документами и т.д.) и для прода (отдельные на dev/tst/prd если так хочется).
Да, docker swarm может помочь с масштабированием - но и только. Все равно проще вертикально расти (пока есть возможность) - меньше накладных расходов. Резервирование же требует очень грамотного подхода.
P.S. совсем не понял про изоляцию окружения - и как этот вопрос решает docker swarm. Docker-compose дает изоляцию на уровне сети, установленные лимиты должны помочь с потреблением ресурсов сервисами. Какая еще нужна изоляция? Особенно если прод на отдельном сервере держать хотя бы из соображений безопасности.
Вопрос: а как организована передача сложных значений в Component Model и в WASIp2? В WASIp1 было понятно - запросил размер у хоста, подготовил буфер, в буфер хост записал данные.
Но в WASIp2 схема не такая - многие аргументы просто передаются по ссылке. При этом wit-bindgen упорно генерирует cabi_realloc, который позволяет хосту выделять память и изменять ее размер. Но в спеках Component Model нет описания этой функции (максимум realloc упоминается, да и то в двух разных сигнатурах - с 2 и 4 аргументами).
При этом cabi_realloc генерируется с разным поведением и разными проверками (на разных языках) - всех нюансов я не смог понять.
Хотелось бы понять, как именно передаются сложные данные между хостом и WASM в рамках WASIp2.
И непонятно, кто и когда должен очищать буферы после cabi_realloc. Думал "очистка" - это realloc с newSize в 0, но некоторые реализации это явно запрещают (а другие наоборот, разрешают).
P.S. я понимаю, что cabi_realloc - это сокращение Canonical ABI и realloc, но именно концов, откуда пошло такое имя, найти не удалось. Ну и полную спецификацию найти бы. P.P.S. и как будут разные модули взаимодействовать, если на разных языках написаны? Или все должны строго cabi_realloc использовать для работы с памятью? А там какую реализацию подсунули - с той и работаем?
Да, как это ни смешно прозвучит, но самым заметным апгрейдом характерным именно для современных систем стал для меня именно корпус.
Лет 10-15 назад были корпуса с подобным подходом (скрытая прокладка кабелей, продуваемость, сетки от пыли, место для помпы и вывода шлангов и т.д.). Разве что корзина для дисков была полноценной и с системой быстрого крепления. Как пример - Zalman Z9 (Plus).
Современные же модели мне больше нравятся компактностью - при желании можно в совсем небольшом корпусе сделать сборку (при некоторых компромиссах). Пускай и будет несколько дороже.
Полезная нагрузка в виде "hello world" - не сказать что эталон по объему ответа. Результаты могли исказиться так или иначе - служебного трафика сильно больше полезного.
Но тут тогда сразу и разный объем ответа просится на тестирование - чтобы выявить разницу при разных объемах ответа. Что удлинит тест в разы.
А не пробовали сразу Golang-сервис запустить с HTTPS? Т.е. без обратного прокси. Как отправная точка тоже было бы полезно (помимо голого HTTP). Правда тогда бекенд тоже с 32 vCPU и 128 ГБ RAM надо было бы запускать...
Такой вопрос: как организовали синхронизацию потоков при работе с WASM и с файловой системой в частности?
В том же примере с SQLite - SQLite не поддерживает многопоточный доступ (на запись, для многопоточного чтения WAL-режим нужен). Получается конкурирующие запросы будут конкурировать за файлы? Или как-то синхронизируется доступ к файлам между потоками?
P.S. В недостатках WASIp1 сказано "нет сокетов", но в WASIp1 есть файловые сокеты.
Основывать крупный и долгосрочный проект на альфа-бета версии любого фреймворка - сомнительная идея.
MVP - еще ладно. Небольшой проект/сервис, который реально за разумные сроки переписать - допустимо.
Ну а все остальные случаи - было сомнительной затеей и в 2007 году. Поэтому больших объемов сомнительного кода вообще не должно было возникнуть. А небольшие объемы - должны были без проблем исправиться по мере дальнейшего развития системы.
Поэтому, да, историческую ретроспективу надо обязательно учитывать, прежде чем критиковать чужой код.
С одной стороны хочется согласиться. Но историческая ретроспектива не должна влиять на допустимость критики кода. Есть или обоснованные решения (и надо знать эти решения), или накопленный тех.долг (и его надо исправлять или переносить в 1ю категорию). А "это старый код, ему можно попахивать" - такого быть не должно.
В отдельных редких случаях может и полезно. Еще полезнее было бы - пример, инициализация чтением файла на этапе компиляции, без встраивания всего файла. Пригодилось бы, например справочник какой из CSV/JSON подгружать.
Ну и да. Коммиты в main мы убрать не сможем. Но плюс в том, что они станут атомарными и мы сможем быстро вычленить и при желании нивелировать те изменения, которые они привносят. Тоже плюс.
Но можно запретить пуши в main ) Называется Protected branches в GitLab. И все правки в main идут через Merge Request.
Много лет назад начал использовать балансирующий коленный стул - и очень доволен до сих пор. Сначала боялся что без спинки будет неудобно, но в реальности оказалось очень и очень удобно. И стоит заметно дешевле )
За наводку на Bimawen 13.3 4K спасибо - очень интересный девайс.
Это было в прошлом году, на свежей Fedora, rootless. И это явно была бага - потому как повторялась нестабильно. Чаще всего перезапуск контейнера не приводил к проблемам, даже если запускать контейнер сразу же.
К слову, это был не единственный прикол с портами. Я использую подход "разработка в контейнере", под каждый стек - свой контейнер. К контейнеру цепляюсь через SSH. И иногда не с 1й попытки удавалось достучаться из VSCode до контейнера. Иногда VSCode не мог достучаться, пока я вручную через консоль не подключусь разок.
Ну и завершающим штрихом было то, что в половине случаев я не мог загрузить систему нормально. После входа, при загрузке gnome - просто серый экран и все. Система ни на что не реагирует. В логах никакого криминала не увидел, поиск по симптомам в интернете ничего не дал. Так что могу только косвенно подозревать, что podman что-то не поделил при старте и произошел deadlock (возможно с docker "подрался"). Но именно что подозревать - перестал использовать podman и проблема ушла (хотя я его не удалял даже). И да, я знаю, что docker и podman не рекомендуют использовать совместно.
Так что лично у меня podman оставил не лучшие впечатления. Слишком много неожиданностей, помимо ожидаемого некоторого изменения поведения команд (относительно docker). Работать, конечно, можно, но стабильной работу не назвать.
P.S. а самый прикол в том, что все описанные проблемы могут быть вызваны одним сбойным модулем, сбои которого вполне могут быть именно локальными особенностями моей системы.
Я очень хорошо представляю, что такое SQL и для чего он нужен. Как и касательно PHP. Впрочем, в "предназначении" ни там, ни там не значится "бизнес-логика".
Да, бизнес-логика в хранимках - рабочее решение. И очень хорошо рабочее, спору нет. Пускай и приходится логику писать максимально близко к данным - но особого криминала в этом не вижу, бизнес-логика все равно сильно на данные опирается.
Но мы сейчас сравниваем "непонятно что" на PHP и другое "непонятно что" на SQL. Судя по описанию, на SQL получилось лучше, чем на PHP. Но вина ли в этом PHP? Не думаю. Как и не думаю, что заслуга SQL есть в том, что получилось лучше. А вот человеческий фактор - уверен что есть.
Могу вспомнить про базы данных, где "нормальная форма" было ругательством, наверное. Или где разрабы не знали ничего, кроме 1й нормальной формы, ведь "не зря же она первая, изучать другие не нужно".
Так что все тут очень относительно.
P.S. а криминал с бизнес-логикой в хранимках скорее вижу в том, что таблицы, ограничения, триггеры, хранимки - очень плотно между собой переплетаются. И работа такого софта становится крайне непрозрачной (помимо БД нужен еще и клиент - не SQL-запросами же оперируют пользователи). И что еще хуже - в отличие от классического кода в IDE, навигация по объектам сильно менее удобна, что затрудняет работу разработчика.
P.P.S. ну а повсеместный веб - это реалии современности. За это можно ругать, но, в первую очередь, это удобно. Кросс-платформенный интерфейс "из коробки" и простота обновления. Нет необходимости обновлять клиентов вручную, нет 100500 ошибок автоматического обновления и прочее-прочее-прочее. Ушел очень большой пласт проблем в общем. Конечно, добавился новый пласт проблем с зоопарком браузеров и настроек системы. Но в целом стало сильно проще.
При всей своей нелюбви к PHP должен сказать, что хранимками и PHP решаются разные задачи. И я сильно сомневаюсь, что если весь функционал засунуть в хранимки - они будут лучше работать. Как минимум потому, что PHP и SQL сильно разные проблемы решают.
Написана, отлажена, оттестирована, отдокументирована, и теперь используется. ВСЁ! Прибито гвоздями к служебной схеме, и фактически уже не подлежит изменению. А повод к корректировке - либо изменение бизнес-требований, либо законодательства. То есть применительно к отдельно взятой процедуре событие достаточно редкое.
Примерно так и использовалось. Разве что гвоздями не прибивали, а правили по мере необходимости без зазрения совести. Просто когда хранимок много, а продукт активно развивается много лет - отдельные хранимки часто приходится править под изменения.
Усуглублялось тем, что у разных клиентов (в разных регионах) могли быть разные требования к отдельным хранимкам - и эти отличия от стандартных надо было вовремя учитывать, когда с БД работаешь или отправляешь обновление.
Разумеется имя то же самое. Более того - ничего не менялось, даже образ оставался тот же. Хотя при ручной остановке контейнера - имя не важно все-таки. Порты должны становиться доступными в любом случае. Причем подобное происходило неоднократно.
Много лет плотно работал с SQL Server - и да, было достаточно удобно. А уж как дебаггер выручал - не передать. Но и признаю, что критика такого подхода появилась не на пустом месте. Версионность, консистентность набора хранимок - регулярно с этим возникали проблемы. Особенно когда работа идет с множеством баз данных.
Да и кодом несколько проще в IDE работать, чем с кучей хранимок (хотя может и изменилось что за последние годы).
И да, многие раработчики не знают SQL - и совершенно зря. ORM и query builder зачастую могут очень неожиданным образом отработать, особенно на хоть сколько-нибудь сложных запросах. Не говоря уже о навыках проектирования баз данных.
Сомневаюсь, что надежность self-hosted docker swarm выше чем у конкурентов. И не забываем, что распределенный софт (без единой точки отказа) - это крайне сложная задача.
Без понимания причин и характера сбоев, лично для меня звучит скорее как "пытались на коленках все запускать - было плохо, занялись вопросом плотнее, перешли на docker swarm - стало лучше". Но тогда заслуга тут не в docker swarm, а в "занялись вопросом плотнее".
Разные окружения должны быть полностью изолированы, без общих точек отказа. Т.е. в рамках одного сервера / docker swarm они не должны жить.
Только если речь идет о state-less сервисах или полноценной репликации у сервиса.
Docker swarm я вижу скорее в сценарии с state-less воркерам, на которых выполняются ресурсоемкие задачи. Тогда да, просто масштабировать, выше надежность. Но единые точки отказа остаются - как минимум в виде мастера с централизованными сервисами (как минимум БД, очереди, внешнее API и т.д.).
Внешний мониторинг нужен - на хостера не надейтесь в этом вопросе вообще. Даже 2я нода на этом же хостере - не лучший выбор. Есть бесплатные мониторинги (от selectel, например) - для простых сценариев должно хватить (как минимум проверять доступность).
Вот не знаю... Docker-compose сейчас в сам docker встраивается, так что надежность с swarm должна быть сравнимой - продукт одной компании (и более чем уверен, механики работы общие). Если с compose были проблемы надежности, то и swarm им же подвержен.
Но пока лично для себя причин перехода с compose на swarm я не понял. Только если ресурсоемкие задачи на отдельных серверах гонять не сильно заморачиваясь с инфраструктурой и доступами.
В какой-то мере масштабирование - да, но без полноценной репликации, больше точек отказа не дадут большую надежность.
Мы говорим о надежности железа или о работоспособности сервиса?
Если железо - да, живучей 3 будет (хотя процент "повышенной живучести" будет небольшой, с учетом того, что хостер один и тот же), то для повышенной надежности сервиса надо полноценно дублировать все сервисы. Не говоря уже о реализации сервисов для работы в распределенном режиме.
Но в статье речь о нескольких серверах из-за проблем масштабирования. Так что это не повышает надежность сервиса, а только понижает - точек отказа становится больше.
На мой взгляд, уж лучше начинать с простого docker (docker-compose). И уже потом смотреть на docker swarm.
Цена VPS не сказать что нелинейно растет с масштабом - в два раза более мощный сервер стоит примерно в два раза дороже. Т.е. разницы с двумя серверами особой нет (а если и есть - то зачастую в пользу более мощного сервера).
Пара серверов у ненадежного хостера не сильно выиграют в надежности.
Уж если делить по серверам - то выделять лучше сервер для "офисных" нужд (VPN-ка, Git-хранилище, CI/CD, работа с документами и т.д.) и для прода (отдельные на dev/tst/prd если так хочется).
Да, docker swarm может помочь с масштабированием - но и только. Все равно проще вертикально расти (пока есть возможность) - меньше накладных расходов. Резервирование же требует очень грамотного подхода.
P.S. совсем не понял про изоляцию окружения - и как этот вопрос решает docker swarm. Docker-compose дает изоляцию на уровне сети, установленные лимиты должны помочь с потреблением ресурсов сервисами. Какая еще нужна изоляция? Особенно если прод на отдельном сервере держать хотя бы из соображений безопасности.
Вопрос: а как организована передача сложных значений в Component Model и в WASIp2?
В WASIp1 было понятно - запросил размер у хоста, подготовил буфер, в буфер хост записал данные.
Но в WASIp2 схема не такая - многие аргументы просто передаются по ссылке.
При этом wit-bindgen упорно генерирует
cabi_realloc, который позволяет хосту выделять память и изменять ее размер. Но в спеках Component Model нет описания этой функции (максимум realloc упоминается, да и то в двух разных сигнатурах - с 2 и 4 аргументами).При этом
cabi_reallocгенерируется с разным поведением и разными проверками (на разных языках) - всех нюансов я не смог понять.Хотелось бы понять, как именно передаются сложные данные между хостом и WASM в рамках WASIp2.
И непонятно, кто и когда должен очищать буферы после
cabi_realloc. Думал "очистка" - это realloc с newSize в 0, но некоторые реализации это явно запрещают (а другие наоборот, разрешают).P.S. я понимаю, что
cabi_realloc- это сокращение Canonical ABI и realloc, но именно концов, откуда пошло такое имя, найти не удалось. Ну и полную спецификацию найти бы.P.P.S. и как будут разные модули взаимодействовать, если на разных языках написаны? Или все должны строго
cabi_reallocиспользовать для работы с памятью? А там какую реализацию подсунули - с той и работаем?Да, nvme сильно шагнули вперед. Но это не так ощутимо, как при переходе с HDD на SSD.
Лет 10-15 назад были корпуса с подобным подходом (скрытая прокладка кабелей, продуваемость, сетки от пыли, место для помпы и вывода шлангов и т.д.). Разве что корзина для дисков была полноценной и с системой быстрого крепления. Как пример - Zalman Z9 (Plus).
Современные же модели мне больше нравятся компактностью - при желании можно в совсем небольшом корпусе сделать сборку (при некоторых компромиссах). Пускай и будет несколько дороже.
Полезная нагрузка в виде "hello world" - не сказать что эталон по объему ответа. Результаты могли исказиться так или иначе - служебного трафика сильно больше полезного.
Но тут тогда сразу и разный объем ответа просится на тестирование - чтобы выявить разницу при разных объемах ответа. Что удлинит тест в разы.
А не пробовали сразу Golang-сервис запустить с HTTPS? Т.е. без обратного прокси. Как отправная точка тоже было бы полезно (помимо голого HTTP). Правда тогда бекенд тоже с 32 vCPU и 128 ГБ RAM надо было бы запускать...
Т.е. это лок от SQLite, а не WASM-движка. ОК, значит обычная конкурентная среда.
Такой вопрос: как организовали синхронизацию потоков при работе с WASM и с файловой системой в частности?
В том же примере с SQLite - SQLite не поддерживает многопоточный доступ (на запись, для многопоточного чтения WAL-режим нужен). Получается конкурирующие запросы будут конкурировать за файлы? Или как-то синхронизируется доступ к файлам между потоками?
P.S. В недостатках WASIp1 сказано "нет сокетов", но в WASIp1 есть файловые сокеты.
Основывать крупный и долгосрочный проект на альфа-бета версии любого фреймворка - сомнительная идея.
MVP - еще ладно. Небольшой проект/сервис, который реально за разумные сроки переписать - допустимо.
Ну а все остальные случаи - было сомнительной затеей и в 2007 году. Поэтому больших объемов сомнительного кода вообще не должно было возникнуть. А небольшие объемы - должны были без проблем исправиться по мере дальнейшего развития системы.
С одной стороны хочется согласиться. Но историческая ретроспектива не должна влиять на допустимость критики кода. Есть или обоснованные решения (и надо знать эти решения), или накопленный тех.долг (и его надо исправлять или переносить в 1ю категорию). А "это старый код, ему можно попахивать" - такого быть не должно.
Так монолит же - зачем JSON-ки гонять? Хватит и простых DTO )
В отдельных редких случаях может и полезно.
Еще полезнее было бы - пример, инициализация чтением файла на этапе компиляции, без встраивания всего файла. Пригодилось бы, например справочник какой из CSV/JSON подгружать.
Но можно запретить пуши в main ) Называется Protected branches в GitLab. И все правки в main идут через Merge Request.
Много лет назад начал использовать балансирующий коленный стул - и очень доволен до сих пор. Сначала боялся что без спинки будет неудобно, но в реальности оказалось очень и очень удобно. И стоит заметно дешевле )
За наводку на Bimawen 13.3 4K спасибо - очень интересный девайс.
Это было в прошлом году, на свежей Fedora, rootless.
И это явно была бага - потому как повторялась нестабильно. Чаще всего перезапуск контейнера не приводил к проблемам, даже если запускать контейнер сразу же.
К слову, это был не единственный прикол с портами. Я использую подход "разработка в контейнере", под каждый стек - свой контейнер. К контейнеру цепляюсь через SSH. И иногда не с 1й попытки удавалось достучаться из VSCode до контейнера. Иногда VSCode не мог достучаться, пока я вручную через консоль не подключусь разок.
Ну и завершающим штрихом было то, что в половине случаев я не мог загрузить систему нормально. После входа, при загрузке gnome - просто серый экран и все. Система ни на что не реагирует. В логах никакого криминала не увидел, поиск по симптомам в интернете ничего не дал. Так что могу только косвенно подозревать, что podman что-то не поделил при старте и произошел deadlock (возможно с docker "подрался"). Но именно что подозревать - перестал использовать podman и проблема ушла (хотя я его не удалял даже). И да, я знаю, что docker и podman не рекомендуют использовать совместно.
Так что лично у меня podman оставил не лучшие впечатления. Слишком много неожиданностей, помимо ожидаемого некоторого изменения поведения команд (относительно docker). Работать, конечно, можно, но стабильной работу не назвать.
P.S. а самый прикол в том, что все описанные проблемы могут быть вызваны одним сбойным модулем, сбои которого вполне могут быть именно локальными особенностями моей системы.
Я очень хорошо представляю, что такое SQL и для чего он нужен. Как и касательно PHP. Впрочем, в "предназначении" ни там, ни там не значится "бизнес-логика".
Да, бизнес-логика в хранимках - рабочее решение. И очень хорошо рабочее, спору нет. Пускай и приходится логику писать максимально близко к данным - но особого криминала в этом не вижу, бизнес-логика все равно сильно на данные опирается.
Но мы сейчас сравниваем "непонятно что" на PHP и другое "непонятно что" на SQL. Судя по описанию, на SQL получилось лучше, чем на PHP. Но вина ли в этом PHP? Не думаю. Как и не думаю, что заслуга SQL есть в том, что получилось лучше. А вот человеческий фактор - уверен что есть.
Могу вспомнить про базы данных, где "нормальная форма" было ругательством, наверное. Или где разрабы не знали ничего, кроме 1й нормальной формы, ведь "не зря же она первая, изучать другие не нужно".
Так что все тут очень относительно.
P.S. а криминал с бизнес-логикой в хранимках скорее вижу в том, что таблицы, ограничения, триггеры, хранимки - очень плотно между собой переплетаются. И работа такого софта становится крайне непрозрачной (помимо БД нужен еще и клиент - не SQL-запросами же оперируют пользователи). И что еще хуже - в отличие от классического кода в IDE, навигация по объектам сильно менее удобна, что затрудняет работу разработчика.
P.P.S. ну а повсеместный веб - это реалии современности. За это можно ругать, но, в первую очередь, это удобно. Кросс-платформенный интерфейс "из коробки" и простота обновления. Нет необходимости обновлять клиентов вручную, нет 100500 ошибок автоматического обновления и прочее-прочее-прочее. Ушел очень большой пласт проблем в общем. Конечно, добавился новый пласт проблем с зоопарком браузеров и настроек системы. Но в целом стало сильно проще.
При всей своей нелюбви к PHP должен сказать, что хранимками и PHP решаются разные задачи. И я сильно сомневаюсь, что если весь функционал засунуть в хранимки - они будут лучше работать. Как минимум потому, что PHP и SQL сильно разные проблемы решают.
Примерно так и использовалось. Разве что гвоздями не прибивали, а правили по мере необходимости без зазрения совести. Просто когда хранимок много, а продукт активно развивается много лет - отдельные хранимки часто приходится править под изменения.
Усуглублялось тем, что у разных клиентов (в разных регионах) могли быть разные требования к отдельным хранимкам - и эти отличия от стандартных надо было вовремя учитывать, когда с БД работаешь или отправляешь обновление.
Разумеется имя то же самое. Более того - ничего не менялось, даже образ оставался тот же.
Хотя при ручной остановке контейнера - имя не важно все-таки. Порты должны становиться доступными в любом случае.
Причем подобное происходило неоднократно.
Много лет плотно работал с SQL Server - и да, было достаточно удобно. А уж как дебаггер выручал - не передать. Но и признаю, что критика такого подхода появилась не на пустом месте. Версионность, консистентность набора хранимок - регулярно с этим возникали проблемы. Особенно когда работа идет с множеством баз данных.
Да и кодом несколько проще в IDE работать, чем с кучей хранимок (хотя может и изменилось что за последние годы).
И да, многие раработчики не знают SQL - и совершенно зря. ORM и query builder зачастую могут очень неожиданным образом отработать, особенно на хоть сколько-нибудь сложных запросах. Не говоря уже о навыках проектирования баз данных.