Могу слайды одолжить :)

Так я их уже нарисовал 😕 Хотя уверен, что в этом чате, в формате совместного творчества получилось бы быстрее и лучше

Возможно :) Вот если что https://www.slideshare.net/mobile/denisizmaylov/coreos-kubernetes

Есть конечно ещё что добавить за прошедший год, но сейчас out of capacity

👍

Денис, вопрос по вашей презнтации — поясните, пожалуйста, что такое "мнолоитное приложение"?

Один исполеняемый exe-шник? Или java-приложение с кучей класов? С exe-шниками я в принципе давно не сталкивался в кач-ве многофункциональных корпоративных приложений. А java-приложения давно не падают целиком из-за проблем во всего лишь одном из классов/нескольких формах.

Поэтому вопрос — разве описанная проблема является общим местом?

👍🏻

Архиверное замечание про вынос сложности из монолита в межсервисную эксплуатацию и конфигурацию. Отсюда как раз вытекает наличие сложности как отдельного независимого от технологии и архитектуры атрибута качества приложения, а по факту команды.

Еще про критику монолитных приложений — вы пишете о проблеме "Необходимость выкатывать все даже при небольших изменениях" — разве это проблема? это же не камни ворочать вручную :) Если говорить о деплое java-приложения на промышленном сервере приложений типа WebLogic, то там все сделано для того, чтобы бизнес-процессы не прерывались — одноврменная работа нескольких версий, постепенное переключение пользовательских сессий на новую версию приложения

@DenisIzmaylov, я поясню к чему я придираюсь :)

Из вашей презентации можно сделать вывод, что микросервисная архитектура рекомендована всем-всем-всем с монлитными приложениями, а Core OS/ Docler/ Kubernetes сделают процесс перехода легким-легким.

Но это же не так все очевидно. Недостатки монллитных приложений вылезают только когда нужно делать одновременно 100500 изменений в разных частях одного приложения с различающимся жизненным циклом обновления, когда изменения очень частые и компонентов (с программистами, которые их развивают) так много, что все начинают друг другу мешать. Я бы не сказал, что среднестатистическое корпоративное (особенно back office) приложение развивается с такой интенсивностью. А значит, примущества микросервисов для такого приложения совсем не очевидны. При этом гемрой можно отхватить вполне не иллюзорный, о чем хорошо написал уважаемый @dolphin278.

Очень интересно было бы познакомиться с характеристиками существующего процесса разработки и архитектуры существующего приложений при котором реально нужно рассматривать переход на микросервисную архитектуру. То есть начиная с какого момента недостатки монолитного приложения станут  для компании дороже чем стоимость гемороя с переходом на микросервисную архитектуру?

Есть такой опыт формулирования подобных критериев необходимости перехода на микросервисную архитектуру?

Соглашусь, кроме того показательным является тот факт, что успешное внедрение микросервисов с их плюсами и минусами в настоящий момент есть только в организациях с быстро меняющимися бизнес функциями и сложной командой. Типа Amazon, Uber и Netflix. А среднестатистический ынтерпрайз микросервисы в их каноническом исполнении могут принести лишнюю сложность и крайне мало выгод

Думаю, что когда несколько дней назад мы все начали обсуждение с вопроса "чем SOA отличается от MSA", на самом деле хотели знать, в каких случаях стоит применять микросервисы, а в каких можно обойтись другими SOA-based паттернами, например bpms

Угу. Маловато в реальности ситуаций, где оправдана микросервисная архитектура. Подходит только для "ранних последователей", которые готовы нести издержки на ее внедрение и эксплуатацию.

Кое-где она насаждается сверху

Надо сказать, что не смотря на наш кровавый ынтырпрайз, мы все-таки в микросервисной архитектуре (которая была создана заказчиками, а не ИТ). И опять же это говорит о зрелости команды (в расширенном смысле, с учетом постановщиков).

Поделитесь плиз статистикой. Сколько микросервисов, сколько разработчиков, сколько запросов на доработку по каждому сервису появляется в неделю? Не слишком много хочу знать? 😃

нет, у нас же кровавый ынтерпрайз. К нам кстати @mxsmirnov собирался прийти по приглашению руководства, но пока видимо до конкретики не дошло. Было бы интересно его заключение ).

микросервисов (у нас это называется расчетная система) порядка 60.