История изменений

Ну сделай мокинг на работающем сервисе с какой-нибудь орм и ооп. Удачи восстановить стейт всего этого говна на момент ошибки

Я не вижу в данном случае разницы между микросервисами и монолитами. Если участие состояния минимально, то и восстановливать его толком не придется. Если состояние сложно, вроде каких-то особым образом связанных записей в БД, то ты не сможешь этого просто сделать и на микросервисной архитектуре.

В каком-то смысле микросервисная архитектору — это на самом деле психологический прием «зачем решать настоящую сложную проблему, если можно придумать решение выдуманной простой проблемы?». Отладив межсервисное взаимодействие ты на самом деле выполнил нулевую работу, потому что вся необходимость этой отладки возникла из-за микросервисности, которая была отрицательной работой, то есть, увеличением числа проблем при неизменной задаче. Примерно как если я скажу «будем оптимизировать решение задачи. Для этого задействуем DSL!» — и буду месяц писать hello world на этом DSL. Даже после блестящей отладки реализации hello world я не выполнил полезной работы.

Настоящую работу ты выполняешь, когда решаешь проблемы хранения состояния, когда интегрируешь маленькие абстрактные алгоритмы в большое решение конкретной задачи — и это именно то, чего адепты микросервисов боятся как огня. Типа «да есть хорошо проверенные решения БД», «это не важно, потеря малой части пользовательских данных некритична», или каноничное «к пуговицам претензии есть? — нет, пришиты намертво, не оторвешь. А кто сшил костюм?».

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

Причем, самое безумное и беспощадное, что в данном случае можно сделать — посадить решать проблему девопса, который не имеет ни малейшего представления о деталях реализации системы, потому вместо решения проблемы просто подсунет костыль... как обычно это и делает.

Ну сделай мокинг на работающем сервисе с какой-нибудь орм и ооп. Удачи восстановить стейт всего этого говна на момент ошибки

Я не вижу в данном случае разницы между микросервисами и монолитами. Если участие состояния минимально, то и восстановливать его толком не придется. Если состояние сложно, вроде каких-то особым образом связанных записей в БД, то ты не сможешь этого просто сделать и на микросервисной архитектуре.

В каком-то смысле микросервисная архитектору — это на самом деле психологический прием «зачем решать настоящую сложную проблему, если можно придумать решение выдуманной простой проблемы?». Отладив межсервисное взаимодействие ты на самом деле выполнил нулевую работу, потому что вся необходимость этой отладки возникла из-за микросервисности, которая была отрицательной работой, то есть, увеличением числа проблем при неизменной задаче. Примерно как если я скажу «будем оптимизировать решение задачи. Для этого задействуем DSL!» — и буду месяц писать hello world на этом DSL. Даже после блестящей отладки реализации hello world я не выполнил полезной работы.

Настоящую работу ты выполняешь, когда решаешь проблемы хранения состояния, когда интегрируешь маленькие абстрактные алгоритмы в большое решение конкретной задачи — и это именно то, чего адепты микросервисов боятся как огня. Типа «да есть хорошо проверенные решения», «это не важно, потеря малой части пользовательских данных некритична», или каноничное «к пуговицам претензии есть? — нет, пришиты намертво, не оторвешь. А кто сшил костюм?».

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

Причем, самое безумное и беспощадное, что в данном случае можно сделать — посадить решать проблему девопса, который не имеет ни малейшего представления о деталях реализации системы, потому вместо решения проблемы просто подсунет костыль... как обычно это и делает.

Ну сделай мокинг на работающем сервисе с какой-нибудь орм и ооп. Удачи восстановить стейт всего этого говна на момент ошибки

Я не вижу в данном случае разны между микросервисами и монолитами. Если участие состояния минимально, то и восстановливать его толком не придется. Если состояние сложно, вроде каких-то особым образом связанных записей в БД, то ты не сможешь этого просто сделать и на микросервисной архитектуре.

В каком-то смысле микросервисная архитектору — это на самом деле психологический прием «зачем решать настоящую сложную проблему, если можно придумать решение выдуманной простой проблемы?». Отладив межсервисное взаимодействие ты на самом деле выполнил нулевую работу, потому что вся необходимость этой отладки возникла из-за микросервисности, которая была отрицательной работой, то есть, увеличением числа проблем при неизменной задаче. Примерно как если я скажу «будем оптимизировать решение задачи. Для этого задействуем DSL!» — и буду месяц писать hello world на этом DSL. Даже после блестящей отладки реализации hello world я не выполнил полезной работы.

Настоящую работу ты выполняешь, когда решаешь проблемы хранения состояния, когда интегрируешь маленькие абстрактные алгоритмы в большое решение конкретной задачи — и это именно то, чего адепты микросервисов боятся как огня. Типа «да есть хорошо проверенные решения», «это не важно, потеря малой части пользовательских данных некритична», или каноничное «к пуговицам претензии есть? — нет, пришиты намертво, не оторвешь. А кто сшил костюм?».

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

Причем, самое безумное и беспощадное, что в данном случае можно сделать — посадить решать проблему девопса, который не имеет ни малейшего представления о деталях реализации системы, потому вместо решения проблемы просто подсунет костыль... как обычно это и делает.