Неудивительно, что вы «безнадежно далеки от второго подхода», с учетом того, как предвзято вы его описали. Я, как человек, использующий в основном второй подход, поясню, почему он хорош.
Когда мы сталкиваемся с новой проблемой, мы некоторое время ее обдумываем, потом решаем. Но дефект нашего мышления в том, что мы думаем, что поняли, в чем именно проблема и как ее правильно решить. Это не так. По настоящему понять можно лишь погрузившись в проблему на практике, а не просто потыкав её теоретическими щупами. Потому что часть важной информации от нас обычно скрыта на старте.
Если вы с самого начала все обдумываете, строите полную архитектуру проекта, а потом ее реализовываете, то это не только замедлит вас в начале, но и не даст вам желаемого ускорения «в середине». Потому что через месяц-другой или вы увидите что-то, что упустили, или требования изменятся. В худшем случае потребуется переписывание крупной части проекта, если не всего целиком.
Гораздо быстрее будет осознанно в первый (а иногда и во второй, и в третий) раз писать быстро и некачественно (прототип), наткнуться на всевозможные стены лбом, переосмыслить чуть ли не полностью, а потом уже написать правильно и качественно.
PS Разумеется, это не относится к критически важным вещам, вроде системы управления полетом или там медицинского оборудования. Хотя даже в этих случаях есть этап исследования и быстрой проверки гипотез.
Технология для строительства АЭС, загородного дома и деревенского туалета — это три разных технологии. В вашем манифесте я вижу идею «Накрутим по максимуму, как если бы мы строили космический корабль. А то, что бизнесу требуется всего лишь простой воздушный змей — это проблема бизнеса».
Это называется саботаж. Можно еще пару пунктов в такой манифест добавить. Например, «завязывайте процессы на себя, пишите запутанный код, будьте незаменимым, чтобы вас не смогли уволить».
Понятно. Я-то думал, что «гигантская» проблема — дороговизна и малое вырабатываемое количество энергии от возобновляемых источников, относительно той же атомной электростанции, к примеру.
Накачал воздух в поплавок, отцепил — он устремился по воде вверх и выработал за счет этого немного энергии. На вершине спустил воздух, он ко дну пошел. Повторить.
Что-то я не понял. Смысл в том, что за счет гравитации при опускании бетонного блока будет вырабатываться энергия? Ну ок, опустили они за месяц все блоки, а дальше что? Ведь чтобы поднять их обратно, тоже потребуется энергия, даже больше, чем получится собрать при опускании.
Да, я так и писал — «в распределенном приложении».
>каковыми могут быть и монолиты — как несколько инстансов на разных узлах
А тут не соглашусь. Транзакции, в традиционном понимании этого слова — операция в бд, обычно реляционной. Сколько инстансов монолита общаются с этой бд — совершенно не важно.
Что такое транзакция, простыми словами? Это объединение нескольких запросов в базу — либо выполнятся все, либо не одна. Если во время исполнения транзации в приложении возникает ошибка — транзакция откатывается, изменений в базе нет.
А в распределенном приложении все по-другому. Изменения в базе уже есть еще на этапе выполнения похожей-на-транзакцию-операции. В случае, если произойдет какая-то ошибка, то приложение попытается создать новые изменения, которые вернут базу в «первоначальный» вид. А вот получится ли у него — бабка на двое сказала.
Проблем может быть целая куча. Ошибка в шине. Ошибка в микросервисе, который не сможет исполнить команду шины «откати». Падение микросервиса, который должен сделать откат. Недоступность базы в тот момент, когда микросервис пытается сделать откат.
Да, эти проблемы не будут встречаться в каждом втором запросе. Но транзакция гарантирует, что все будет ок, а псевдо-транзакция надеется, что все будет ок.
И в чем тогда разница? Просто переложили проблему с больной головы на здоровую и сделали вид что она решена, тогда как на самом деле она осталась нерешенной.
Да как бы — ну и будет у вас 10 очисток, и что? Одна из них реально почистит бд, остальные девять просто отработают вхолостую (и довольно быстро, к слову — старых записей-то в бд не останется уже после первой итерации). Да, выглядит не очень красиво, но для большинства ситуаций — рабочий вариант, если уж прям совсем не хочется заморачиваться.
Можно в бд хранить инфу, кто когда последний раз начинал очистку и смог ли завершить её. Кто первый из дубликатов монолита успеет пообщаться с бд, тот и выполнит очистку.
>Но не проще ли сделать отдельное приложение для этого?
Черт его знает, может и проще, но это не относится уже к обсуждаемой теме. Мы не обсуждаем, что лучше — монолит или микросервисы. Мы обсуждаем возможность горизонтального масштабирования монолита.
Пожалуйста, не смешивайте. Мы не говорим о преимуществах и недостатках монолита перед микросервисной архитектурой. Мы (по крайней мере я) рассуждаем о возможности (или невозможности) горизонтально масштабировать монолит.
Черт бы побрал этот планшет. Писал большой хороший коммент с примерами, но браузер скрашился.
Если в общем — бывают различные ситуации, но в большинстве случаев можно спроектировать монолит так, чтобы он горизонтально масштабировался.
Секрет прост — он должен быть стейтлесс. Всё, что имеет статус — вынести отдельно, не хранить в памяти приложения. О данных позаботится постгрес. О пользовательских сессиях и кешировании — редис. О доставке сообщений о фоновых задачах — один из десятков существующих систем очередей, хоть тот же редис использовать.
Единственное, с чем могут быть реальные сложности — пользовательские файлы. Хранить их в бд (постгресе или монге) — нерационально. S3 может быть слишком дорого. И вот лежат они на диске, рядом с монолитом, и никак второй сервер сюда не присобачишь. Но даже тут есть варианты, начиная от запуска облачной файловой системы — от клона S3 до какого-нибудь seaweedfs, написанного на go.
Когда мы сталкиваемся с новой проблемой, мы некоторое время ее обдумываем, потом решаем. Но дефект нашего мышления в том, что мы думаем, что поняли, в чем именно проблема и как ее правильно решить. Это не так. По настоящему понять можно лишь погрузившись в проблему на практике, а не просто потыкав её теоретическими щупами. Потому что часть важной информации от нас обычно скрыта на старте.
Если вы с самого начала все обдумываете, строите полную архитектуру проекта, а потом ее реализовываете, то это не только замедлит вас в начале, но и не даст вам желаемого ускорения «в середине». Потому что через месяц-другой или вы увидите что-то, что упустили, или требования изменятся. В худшем случае потребуется переписывание крупной части проекта, если не всего целиком.
Гораздо быстрее будет осознанно в первый (а иногда и во второй, и в третий) раз писать быстро и некачественно (прототип), наткнуться на всевозможные стены лбом, переосмыслить чуть ли не полностью, а потом уже написать правильно и качественно.
PS Разумеется, это не относится к критически важным вещам, вроде системы управления полетом или там медицинского оборудования. Хотя даже в этих случаях есть этап исследования и быстрой проверки гипотез.
Тогда да, в этом есть какой-то смысл.
Где же тут возобновляемые источники энергии?
Накачал воздух в поплавок, отцепил — он устремился по воде вверх и выработал за счет этого немного энергии. На вершине спустил воздух, он ко дну пошел. Повторить.
На одни только материалы, без учета затрат на проектирование, много денег ушло? Двигатель, наверное, как половина самого планера стоит.
срезать подковызаменять куски хода прямо на ходу.>каковыми могут быть и монолиты — как несколько инстансов на разных узлах
А тут не соглашусь. Транзакции, в традиционном понимании этого слова — операция в бд, обычно реляционной. Сколько инстансов монолита общаются с этой бд — совершенно не важно.
Что такое транзакция, простыми словами? Это объединение нескольких запросов в базу — либо выполнятся все, либо не одна. Если во время исполнения транзации в приложении возникает ошибка — транзакция откатывается, изменений в базе нет.
А в распределенном приложении все по-другому. Изменения в базе уже есть еще на этапе выполнения похожей-на-транзакцию-операции. В случае, если произойдет какая-то ошибка, то приложение попытается создать новые изменения, которые вернут базу в «первоначальный» вид. А вот получится ли у него — бабка на двое сказала.
Проблем может быть целая куча. Ошибка в шине. Ошибка в микросервисе, который не сможет исполнить команду шины «откати». Падение микросервиса, который должен сделать откат. Недоступность базы в тот момент, когда микросервис пытается сделать откат.
Да, эти проблемы не будут встречаться в каждом втором запросе. Но транзакция гарантирует, что все будет ок, а псевдо-транзакция надеется, что все будет ок.
Можно в бд хранить инфу, кто когда последний раз начинал очистку и смог ли завершить её. Кто первый из дубликатов монолита успеет пообщаться с бд, тот и выполнит очистку.
>Но не проще ли сделать отдельное приложение для этого?
Черт его знает, может и проще, но это не относится уже к обсуждаемой теме. Мы не обсуждаем, что лучше — монолит или микросервисы. Мы обсуждаем возможность горизонтального масштабирования монолита.
Черт бы побрал этот планшет. Писал большой хороший коммент с примерами, но браузер скрашился.Если в общем — бывают различные ситуации, но в большинстве случаев можно спроектировать монолит так, чтобы он горизонтально масштабировался.
Секрет прост — он должен быть стейтлесс. Всё, что имеет статус — вынести отдельно, не хранить в памяти приложения. О данных позаботится постгрес. О пользовательских сессиях и кешировании — редис. О доставке сообщений о фоновых задачах — один из десятков существующих систем очередей, хоть тот же редис использовать.
Единственное, с чем могут быть реальные сложности — пользовательские файлы. Хранить их в бд (постгресе или монге) — нерационально. S3 может быть слишком дорого. И вот лежат они на диске, рядом с монолитом, и никак второй сервер сюда не присобачишь. Но даже тут есть варианты, начиная от запуска облачной файловой системы — от клона S3 до какого-нибудь seaweedfs, написанного на go.