Радує те що якщо років 10 назад майже кожна подібна стаття містила в собі опис того як потрібно сходу починати з мікросервісів і умовної кафки то зараз вже розуміння що monolith-fiirst або модульний моноліт це кращий вибір в більшості випадків на старті.

Насправді до таких штук команда розробки має бути готова перед тим як це імплементувати — правильно прописані SLO на кожен сервіс, налаштовані алерти, трекінг інцидентів, враховувати час того хто на on-call при плануванні задач і т.д.

Тут зараз в комментарі набіжить куча народу і будуть писать — нафіга воно таке треба, я би такі проекти десятою дорогою обходив і т.д. Але в багатьох продуктових великих компаніях такі активності є, і це заставляє команди розробки не просто займатись ***к-хуяк і в продакшин, а і бути відповідальним за свою частину солюшина (мікросервіса).
Це все має бути максимально формально прописано в відповідальності команд (в ідеалі).

Виходячи з вашого тексту — ви займаєтесь розробкою/суппортом якогось невеликого апплікейшина, де все тупо трималось на одній людині яка була пожежником у випадку коли шось траплялось. Зараз просто треба інший пожежник, якого менеджмент буде кошмарить коли буде треба.

Навіть якщо вам будуть доплачувать x2-x3 (чого скоріш за все не буде) головняка у вас буде дуже багато. А якщо інцидентів у вас до цього було немало, то потенційно це пряма дорога до тривожності стресу.

Ще раз повторюсь, до цього команда розробки/продукт має бути готовим.

Щоб відповісти на це питання треба зрозуміти що означає «закінчення війни».

Дуже багато говорящих голів на Ютубі задвигають історію про вибори в США і шо їм то мати тут успіхи в аккурат перед голосуванням. Але якщо подивитись на стан діда Джо, то є ненульова вірогідність шо так може статись, шо замість нього буде якийсь інший кандидат і всі ці сценарії і стратегії підуть лісом.

Все питання в ресурсах.
Виглядає так, що як мінімум на рік вести таку війну як зараз ресурси з обох боків будуть. Тому в такому форматі як зараз це ще мінімум рік.

В те, що F-16 якось кардинально щось змінять я не вірю.

Маркерами того куди воно йде для себе бачу наступні події

— Вихід до ЖД гілки Волоноваха — Токмак.
Скоріш за все після цього у орків будуть величезні проблеми з забезпеченням на півдні.

— Вихід СОУ до Азовського моря в любому місці.
Cкоріш за все після цього буде «жест доброй воли» і мосту керченському будуть гайки.

Звільнення півдня до кінця року вважаю супер-великою перемогою після якої наступним буде питання Криму і Донбасу.

Війну на роки в такому форматі як зараз ні орки ні ми не витримаємо. Чисто по ресурсам.

Іноді коли бачу що з’являється ідея дроблення мікросервісів на мілі/нано/etc одразу думка — десь там і з точки зору деплойменту/експлуатації є ускладнення. І по факту потім замість умовних 5 людей треба вже 10-15 щоб то всьо девелопати-підтримувати.

Мав мабуть з десяток інтерв’ю з колумбіцями. На диво середній рівень був досить ок. І так — перша ассоціація коли бачив назву Меделін — Пабло Ексобар та серіал Наркос )

God of War 4 одна з найулюбленіших що грав на PS. Як буде можливість — найближчим часом планую пограти і в Ragnarök

+

Раджу курс на OReilly від Марка Рідчарса і Ніла Форда. В ньому досить простими словами описується роль архітектора і необхідний набір майндсету/скілсету/тулсету.

Software Architecture Fundamentals. Neal Ford, Mark Richards
www.oreilly.com/...​ndamentals/9781491998991

По книжкам:

* Fundamentals of Software Architecture: An Engineering Approach
www.amazon.com/...​acteristics/dp/1492043451

* Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures
www.amazon.com/...​hitectures/dp/1492086894

* Designing Software Architectures: A Practical Approach
www.amazon.com/...​ngineering/dp/0134390784

* Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems
www.amazon.com/...​intainable/dp/1449373321

* Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith
www.amazon.com/...​-Transform/dp/1492047848

* Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
www.amazon.com/...​Deploying/dp/0321200683/r

Сайти, блоги
microservices.io
www.cloudcomputingpatterns.org
blog.bytebytego.com

По тому що я бачу зараз — то дуже часто для реалізації окремих нових веб-сервісів для яких важливий перформанс вибирают саме Golang замість Java. Тому є декілька аргументів, і хайп там взагалі не на першому місці.

+

Якщо зони відповідальності поділити так що кожен в команді буде дуже добре знати тільки свій модуль — це дає короткострокові плюси, але у випадку коли хтось випадає на певний термін або взагалі звільняється — потім то може бути великою проблемою.

Я чого спитав стосовно In Progress) Тому що в статті сказано що команди відмовились від естімації:

У результаті, відмовились від оцінки задач в годинах або story points. Адже оцінки за визначенням не є точними і на них впливають численні фактори ризику. Kanban пропонує прогнози майбутнього на основі даних, заснованих на ймовірності, використовуючи лише минулий досвід.

Насправді в Scrum прогнозування і планування також базуються на історичних данних попередніх іттерацій. Правда це в теоріїї, реальність завжди трошки інша. Два різни деви можуть закривати одну і ту ж задачу досить по різному)

Цікаво)
Мав нагоду спостерігати за рухом досить великої інжинірингової організації як раз в інший бік — від Kanban підходу та No estimation до іттеративного Scrum-like процессу з оцінюванням. Для чого? Мати більш керованний і прогнозованний процес делівері. Правда у них не було такого фактору як війна.
Дійсно, в часи коли реальний горизонт планування — максимум неділя-дві і не знаєш коли і куди завтра калібр прилетить — Kanban більш кращий спосіб організувати процес.

У мене є два питання:

1. У вас є якись формальний ліміт скільки одна задача може бути в In progress? Умовно кажучи чи може задача «Зміни колір кнопки» бути в In progress декілька днів 🙂 ?

2. Як ви вірішуєте проблему коли один дев наприклад систематично витягує прості карточки із ToDo а іншим залишаються більш складніші?

Круте відео, стисло коротко.

Свого часу Хабр був можливо одним із основних джерел звідки дізнавався про релізи нових тулів, фреймворків. Можу погодитись с комментарем що успіх тоді був як раз за рахунок того що то було місце збору всіх гіків рунету. Тоді запостити щось на Хабр — було дуже круто)
А далі вони почали сегментувати контент і я забив. Поступово Твіттер і англомовні ресурси повністю замінили Хабр.

По суті зараз ДОУ частково є тим самим Хабром.

+

Коротка відповідь — при правильному підході так, робиться порівняльний аналіз з урахування важливих характеристих.

Наприклад — якщо це MVP де в процесі розробки залучено до 5 людей і немає супер великих вимог по перфомансу на початку — модульний моноліт виглядає більш пріорітетним ніж та ж мікросервісна архітектура, і навпаки — якщо є вимоги що велика кількість людей повинная бути якимось чином поділена на зони відповідальності і чітко відповідати за певний функціональний компонент з перспективою легкого масштабування — тут вже це аргументи в сторону мікросервісного підходу.

Треба більш чітко розуміти реальні вимоги і не намагатись вирішувати потенційних проблем яких взгалі може не бути.

Питання із ряду вічних-холіварних. Насправді Microservice architecture != Event driven architecture.

У Марка Річардса в його курсі на O’reilly є досить крута порівняльна таблиця архітектурних паттернів по декільком важливим параметрам: Agility, Deployment, Testability, Performance, Scalability, Development.

www.oreilly.com/...​re-architecture-patterns

+

net стек — в моєму розумінні, це як правило великий ентерпрайз зі всіма його плюсами і мінусами.
тут подивився список вакансія в розділі .net — там через одну також і мінімальні знання js потрібно. Думаю причина проста — вміти і фронт якщо треба правити. Досить часто бекендери того не люблять)

node.js став популярним в першу чергу коли великі апплікейний почали дробити на більш меньші сервіси. Плюс досить часто node.js апплікейшиний — це backend для frontend.

Наскільки я знаю, то сучасний .net стек це вже не чітко microsoft-based, всякі кубернетуси, докери там також активно використовуються.

Треба розуміти що сучастний node.js. апплікейший, це не тільки знання JS + express/nest.js. Тут як правило потрібно також знання linux на базовому рівні, докер, sql/nosql бази, cloud native підходи.

Стосовно перспектив для входу треба розуміти цілі — якщо просто потрібно запригнути і почати працювати, тут тупо рекомендація одна — на те що зараз є попит.

Якщо дивитись на горизонт планування в років 5 і що буде актуально тоді — майже впевненний що .net стек все ще буде досить актуальним. Зараз дуже багато всього на ньому роблять, і питання підтримки нікуди не зникне.

В свій час коли я пробував різні мови і технології .net шлях мені не зайшов причині того, що то був чіткий Microsoft напрямок (Visual Studio, MS SQL, etc).