Сообщение Re[2]: Docker - для релиза или для разработки? от 17.05.2020 6:54
Изменено 17.05.2020 6:59 User239
Re[2]: Docker - для релиза или для разработки?
Здравствуйте, gandjustas, Вы писали:
G>А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет.
Ну а как насчёт уменьшить время сборки, тем самым повысив продуктивности разработчиков (локально) и понизив время, которое требуется на релиз новой версии?
Допусти надо срочно сделать какое-то небольшое изменение, протестировать и выкатить его. В случае с монолитом единственный вариант собирать, тестировать и деплоить всё приложение. С отдельным сервисом, если изменение затрагивает только этот сервис, может оказаться быстрее, так как те же действия надо выполнить только для одного сервиса (в некоторых случаях протестировать ещё и зависимые от него сервисы).
Хотя, конечно, зависит от того, что называть "микросервисами". Какие-нибудь CustomerService, ProductService, OrderService, OrderItemService это наверное чересчур и создаёт больше проблем, чем решает. Но в то же время отделить, скажем, ProductReportingService от OrderProcessingService теоретически может иметь преимущества вроде описаных выше.
G>А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет.
Ну а как насчёт уменьшить время сборки, тем самым повысив продуктивности разработчиков (локально) и понизив время, которое требуется на релиз новой версии?
Допусти надо срочно сделать какое-то небольшое изменение, протестировать и выкатить его. В случае с монолитом единственный вариант собирать, тестировать и деплоить всё приложение. С отдельным сервисом, если изменение затрагивает только этот сервис, может оказаться быстрее, так как те же действия надо выполнить только для одного сервиса (в некоторых случаях протестировать ещё и зависимые от него сервисы).
Хотя, конечно, зависит от того, что называть "микросервисами". Какие-нибудь CustomerService, ProductService, OrderService, OrderItemService это наверное чересчур и создаёт больше проблем, чем решает. Но в то же время отделить, скажем, ProductReportingService от OrderProcessingService теоретически может иметь преимущества вроде описаных выше.
Re[2]: Docker - для релиза или для разработки?
Здравствуйте, gandjustas, Вы писали:
G>А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет.
Ну а как насчёт уменьшить время сборки, тем самым повысив продуктивности разработчиков (локально) и понизив время, которое требуется на релиз новой версии?
Допусти надо срочно сделать какое-то небольшое изменение, протестировать и выкатить его. В случае с монолитом единственный вариант собирать, тестировать и деплоить всё приложение. С отдельным сервисом, если изменение затрагивает только этот сервис, может оказаться быстрее, так как те же действия надо выполнить только для одного сервиса (в некоторых случаях протестировать ещё и зависимые от него сервисы).
Хотя, конечно, зависит от того, что называть "микросервисами". Повсеметно лепить какие-нибудь CustomerService, ProductService, OrderService, OrderItemService это наверное чересчур и создаёт больше проблем, чем решает. Но в то же время отделить, скажем, ProductReportingService от OrderProcessingService теоретически может иметь преимущества вроде описаных выше.
G>А вот в чем профит от "микросервисов" — я до сих пор не понял и даже внятных примеров нет.
Ну а как насчёт уменьшить время сборки, тем самым повысив продуктивности разработчиков (локально) и понизив время, которое требуется на релиз новой версии?
Допусти надо срочно сделать какое-то небольшое изменение, протестировать и выкатить его. В случае с монолитом единственный вариант собирать, тестировать и деплоить всё приложение. С отдельным сервисом, если изменение затрагивает только этот сервис, может оказаться быстрее, так как те же действия надо выполнить только для одного сервиса (в некоторых случаях протестировать ещё и зависимые от него сервисы).
Хотя, конечно, зависит от того, что называть "микросервисами". Повсеметно лепить какие-нибудь CustomerService, ProductService, OrderService, OrderItemService это наверное чересчур и создаёт больше проблем, чем решает. Но в то же время отделить, скажем, ProductReportingService от OrderProcessingService теоретически может иметь преимущества вроде описаных выше.