Подведение коммуникаций, планирование финансирования - это все часть как раз планирования работ, которое, как ты сам показываешь, даже для серийного строительства одинаковых многоэтажек идет с отставанием в половине случаев. Т.е. даже шаблонное строительство - не может быть нормально спланировано.
В крупных IT бизнесах обычно очень, очень фиговые процессы, так как бизнес от качества процессов не зависит, а найти компетентных менеджеров в достаточных количествах не получается. Статья прекрасная, по ней можно проводить обучение по списку плохих подходов к разработке, собрали чуть ли не полный джекпот.
Ага, особенно явно это относится к строительству АЭС, где и с деньгами все нормально и задержки по срокам от плана в два-три раза никого не удивляют. Это шаблонные многоэтажки из готовых блоков строят более-менее по плану и в срок, хотя и там задержки на четверть срока не редки. Все остальное, от ремонта квартиры и до АЭС - в сроки укладывается довольно редко и, скорее, случайно.
В PG - не все, но это особенности реализации решения на PG и никак не связано с необходимостью всегда делать "БД на сервис". Скорее уж "если для нас существенна изоляция исполнений по сервисам и мы взяли PG - то нужно делать много разных баз". Кстати, даже в этом случае скорее имеет смысл выделить два СУБД - для "основного функционала" и для "необязательного функционала", создавать по БД на сервис все равно не нужно.
Чем это отличается от планирования ограничений на отдельные сессии или клиентов средствами БД? Точно так же сервис не сможет запросом съесть всю память, не сможет занять все ядра и так далее, но только оверхеда будет в разы меньше (не нужна куча виртуалок, гораздо меньше расходов на работу самого сервера управления БД), перекидывать ресурсы будет гораздо проще (поменял ограничения и все), поддержка (с учетом репликации, контроля прав доступа и так далее) будет вообще кратно дешевле.
Т.е. используя одну СУБД - мы решаем все те же задачи, но при этом в разы дешевле. Зачем тогда создавать по БД на сервис?
Ну, это один из вариантов, но я про другое. На основании чего ты выделишь конкретное число ядер и памяти на каждый сервис? Как у тебя получится "подобрать нужные значения чтобы они работали во всех случаях, приложение ещё и развивается/меняется"?
Хм. Вот у тебя 8 ядер, 128GB RAM и 10 сервисов (20 экземпляров). Этого достаточно для штатной нагрузки при условии "все сервисы в одной БД". Как ты поделишь ресуры на 10 БД и при этом увеличишь надежность? Даже если все сервисы у тебя автономны (в реальности так не бывает).
Так если не удается спланировать соединения - точно так же не удастся спланировать ограничения на отдельные СУБД и точно так же оно начнет падать из-за нехватки ресурсов. А число сеансов на сервис как раз легко контролируется. В чем выигрыш-то от "одна база на сервис"?
Даже в PG есть инструменты (хотя и мало) ограничения ресурсов на сеанс. С памятью там сложнее, с IO возможностей больше. В более взрослых БД таких инструментов гораздо больше. И нежелание настраивать СУБД или осознанно выбирать конкретную СУБД - не повод выделять по серверу на каждый сервис.
И? У тебя 1000 соединений на PG, от одного сервиса в пуле 10, эти 10 стали тормозить - и в чем проблема для остальных? Ну, в теории да, кэш страниц вымывается - но и только.
И, главное, как от этого спасет разделение на несколько БД? Кроме того, что подобные проблемы будут происходить чаще?
Только очень мало кто умеет в обратную совместимость, так как это вообще технологически нетривиально. Для синхронных вызовов еще есть решения (особенно если забыть про RESTful), с БД уже сложнее, а вот с брокерами - совсем грустно. Хотя если не нужно уметь откатывать релиз при ошибках, то все чуть проще, но не надежно.
Так как сервисы все-таки взаимодействуют, они уже не являются совсем независимыми. И выбор разных стеков или БД - становится или очень дорогим или вообще невозможным.
Ты какие-то странные цитаты привел про АЭС. Почитай про https://ru.wikipedia.org/wiki/АЭС_«Олкилуото», например.
Подведение коммуникаций, планирование финансирования - это все часть как раз планирования работ, которое, как ты сам показываешь, даже для серийного строительства одинаковых многоэтажек идет с отставанием в половине случаев.
Т.е. даже шаблонное строительство - не может быть нормально спланировано.
В крупных IT бизнесах обычно очень, очень фиговые процессы, так как бизнес от качества процессов не зависит, а найти компетентных менеджеров в достаточных количествах не получается.
Статья прекрасная, по ней можно проводить обучение по списку плохих подходов к разработке, собрали чуть ли не полный джекпот.
Ага, особенно явно это относится к строительству АЭС, где и с деньгами все нормально и задержки по срокам от плана в два-три раза никого не удивляют.
Это шаблонные многоэтажки из готовых блоков строят более-менее по плану и в срок, хотя и там задержки на четверть срока не редки. Все остальное, от ремонта квартиры и до АЭС - в сроки укладывается довольно редко и, скорее, случайно.
В PG - не все, но это особенности реализации решения на PG и никак не связано с необходимостью всегда делать "БД на сервис". Скорее уж "если для нас существенна изоляция исполнений по сервисам и мы взяли PG - то нужно делать много разных баз".
Кстати, даже в этом случае скорее имеет смысл выделить два СУБД - для "основного функционала" и для "необязательного функционала", создавать по БД на сервис все равно не нужно.
Чем это отличается от планирования ограничений на отдельные сессии или клиентов средствами БД?
Точно так же сервис не сможет запросом съесть всю память, не сможет занять все ядра и так далее, но только оверхеда будет в разы меньше (не нужна куча виртуалок, гораздо меньше расходов на работу самого сервера управления БД), перекидывать ресурсы будет гораздо проще (поменял ограничения и все), поддержка (с учетом репликации, контроля прав доступа и так далее) будет вообще кратно дешевле.
Т.е. используя одну СУБД - мы решаем все те же задачи, но при этом в разы дешевле. Зачем тогда создавать по БД на сервис?
Т.е. по OOM сервера не падают, хорошо.
Про разделение ресурсов обсуждаем в другой ветке, не будем тут дублировать.
Ну, это один из вариантов, но я про другое.
На основании чего ты выделишь конкретное число ядер и памяти на каждый сервис? Как у тебя получится "подобрать нужные значения чтобы они работали во всех случаях, приложение ещё и развивается/меняется"?
Хм. Вот у тебя 8 ядер, 128GB RAM и 10 сервисов (20 экземпляров). Этого достаточно для штатной нагрузки при условии "все сервисы в одной БД".
Как ты поделишь ресуры на 10 БД и при этом увеличишь надежность? Даже если все сервисы у тебя автономны (в реальности так не бывает).
Да я вообще не видел БД, которая складывается от OOM. Это как-то очень криво надо ее настраивать (да и то не факт, что получится).
Так если не удается спланировать соединения - точно так же не удастся спланировать ограничения на отдельные СУБД и точно так же оно начнет падать из-за нехватки ресурсов. А число сеансов на сервис как раз легко контролируется.
В чем выигрыш-то от "одна база на сервис"?
Даже в PG есть инструменты (хотя и мало) ограничения ресурсов на сеанс. С памятью там сложнее, с IO возможностей больше. В более взрослых БД таких инструментов гораздо больше.
И нежелание настраивать СУБД или осознанно выбирать конкретную СУБД - не повод выделять по серверу на каждый сервис.
И? У тебя 1000 соединений на PG, от одного сервиса в пуле 10, эти 10 стали тормозить - и в чем проблема для остальных?
Ну, в теории да, кэш страниц вымывается - но и только.
И, главное, как от этого спасет разделение на несколько БД? Кроме того, что подобные проблемы будут происходить чаще?
А что DBA сказали? Или с ними не обсуждали, "умерло и умерло"?
И это точно было из-за твоего запроса?
Хмм, и какая БД ложиться по OOM от одного запроса?
Только очень мало кто умеет в обратную совместимость, так как это вообще технологически нетривиально. Для синхронных вызовов еще есть решения (особенно если забыть про RESTful), с БД уже сложнее, а вот с брокерами - совсем грустно.
Хотя если не нужно уметь откатывать релиз при ошибках, то все чуть проще, но не надежно.
Ни для одной из этих целей не нужны микросервисы.
Так как сервисы все-таки взаимодействуют, они уже не являются совсем независимыми. И выбор разных стеков или БД - становится или очень дорогим или вообще невозможным.
Это всего лишь одна из множества книг. Как и все прочие - как с верными, так и с неверными утверждениями.
И чье это определение? И кто его придерживается?
И связность никак не зависит от "одна БД" или "несколько БД".
Так и в монолите нет рисков. Добавил archunit для проверки доступов - и все автоматически проверяется.