А мне нравится: сначала идет основная логика, сразу ясно, что выполняет функция. Детали — позже.

Видел многих олд-скульных специалистов, которые были когда-то очень хороши в какой-то области знаний, но вместо того, чтобы учиться чему-то новому сидели в зоне комфорта

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

Однако если от вам требуется выпускать что-то новое регулярно, то, увы, работа в зоне комфорта не годится

Часто работаю над чем-то новым и интересным в отличной команде. Если команда занята чем-то серьезным, то скрам-мастер предоставить возможность выбора: стендап сейчас, позже или сегодня не нужен. Новые фичи продакт-менеджер приходит просто обсудить в комнату к команде, когда это надо, а не парит заранее назначенными на полгода вперед митингами груминга.
Это моя зона комфорта, это agile, а не та хайповая фигня, которую нам тюхали до этого.

А, ну да, надо обязательно «в гамаке и на лыжах»(с) Комфорт, это когда ты получаешь удовольствие от работы. Что здесь плохого?

Agile это не только способ управления задачами и требованиями и его суть не в итерациях. Его суть в непрерывной адаптации всего ко всему

Частые изменения не являются зоной комфорта для многих людей (естественное, мое мнение). Были у нас такие ковбои методологии, что-то постоянно меняли: «А почему у вас нет клевой доски для развешивания задач на бумажечках? А что-то не видно, кто делает задачу. Аватарки на бумажках будет само то! А что это у вас разработчики БД не пишут CSS для фронтенда? Как-то не эджайл… Нам нужен ретроспектив, на котором мы укрепим работу команды построением башни из макарон!»
Когда заезжие гастролеры наконец-то оставили нас в покое, люди начали заниматься тем, для чего их нанимали: писать код,… ь.
А когда люди стали заниматься любимым делом, то они стали проявлять инициативу.

Да всегда был популярен, хорошая технология для сервисов. А что не так то?

Спасибо за перевод. Конкретно статья — странная. Не то реклама чего-то, не то автор обломился написать что-то более емкое. Пардон, но капитанство ИМХО…

Не думаю, что это ваша ошибка. Семья строится не одним человеком. Что-то не сложилось… Моя жена постоянно интересуется моей работой, успехами и проблемами. А я стараюсь интересоваться «котиками и погодой» платьями, сумками, ее Фотошопом и т.п.

Звучит просто, но увы не только лишь все понимают необходимость и важность информационного обмена

Виталий, ты?

Так я про преимущества спрашивал, не про особенности. Мне вот интересно, чем в данном случае оправдано применение сложной распределенной системы и почему это лучше простого LB?

А в чем в данном случае преимущество общения микросервисов через Kafka (messaging) по сравнению с обычным синхронным request/response + load balancer?

Конечно точно, это ж мой пример :)

Например, что поддержка такого-то алгоритма/бизнес-процесса и т.п. еще не реализована.

Да, исключение. И, возможно, более осмысленное, нежели NRE или ошибка приведения типов. Но, надо отдать должное автору, контекста в данном вопросе — ноль. Так что, спорить что лучше я не буду :)

// вариант 3
switch (thing)
{
   case Foo foo:
        foo.DoSomething();
.....
}

Из разряда «из двух неправильных вариантов выберите менее неправильный»

Он (IIS) ваще пихается в Nano Container не задумываясь. Там уменьшение размера идет за счет перехода .NET Core.
Речь идеть просто об альтернативном подходе. Не мил IIS, не используйте.

Нет, не слишком. Слишком, это когда из одного сервиса торчит другой. А еще, из WCF делать RESTful, имея в своем распоряжении ASP.NET стек. Тем более, если из WS-* используется практически ничего. Но, это дело вкуса и других требований.
На самом деле, нашим LeanOps проще иметь дело с IIS-hosted приложениями, отсюда и переход на ASP.NET c Windows Service. Сначала, мне тоже это казалось странным. Теперь — совсем нет. Кроме того, как я уже говорил, легко прикручиваются очень полезные web-страницы для мониторинга, управления настройками и проч.

А можно и вообще обойтись одним ASP.NET MVC/WEB API. Настраивается Autostart и RunAlways на IIS и не требуется такая гремучая смесь технологий. Плюс возможность создания страниц мониторинга, конфинурации сервиса и проч. Очень удодно и практично.
MS, конечно, обещал добавить WCF в .NET Core, но изначально ее там не было и они стараются перетянуть всех на ASP.NET MVC (который теперь и Web API)

У нас общая система мониторинга также выдавала алерты с минимальным уровнем детализации и полезности. Удобство UI и скорость его работы оставляла желать намного лучшего (в принципе, практически отбивала охоту что-либо далее исследовать).
В итоге, для одного из ключевых сервисов мы начали писать большой объем мониторинговой информации, который постоянно считывается и анализируется алерт-сервисом: агрегация ошибок по времени (кол-во в минуту), содержанию (стек трейс). Оповещения с алертами отправляются зачастую уже с указанием причины/источника ошибки. Думаем добавить выбор целевой аудитории для каждого типа ошибки. Кроме того, проводится анализ на различные бизнес- и секьюрити правила…

SOAP сервисы всегда можно было писать на разных технологиях, хоть почтой. Не суть.

Сомнение вызывает подход решения кадровых проблем. Возьмем другой пример. Админы (или команда, кто там всем занимается), сказали, что Zookeeper — гавно и f..ck you. Его как и на что менять будут и сколько времени это займет с таким подходом? Более того, Kafka чем там еще кроме Zookeeper'а может управляться? А потом команда, которая пилила bubuku для управления Kafka, сказала что и Python тоже гавно. И потянулась цепочка…