в Україні є свої бізнес традиції, одна з них — всі бізнеси мають працювати по сірому або по чорному. Кожні ~ 6 місяців — 1 рік в кілька етапів відбувається атака на всі білі бізнеси, які ± заробляють якісь гроші. В ЗМІ починають розказувати які несправедливі там умови, і як мало вони платять податків і як потрібно відрегулювати і навести ’справедливість’. Ключові тези в ЗМІ: ’неврегульовані’, ’бюджет недоотримує’, ’будівництво доріг’, ’зарплати вчителям’. Притому всі ЗМІ роблять це в один час і повторюють одні і ті ж тези чим створюють ілюзію масової підтримки. Нові умови завжи висуваються так що бізнесу можна або закриватись або перейти на сірі схеми. Потім з залежності від домовленостей, або дають задню і повертаються через пів року або створюють і продають нову посаду/орган, яка буде ’регулювати’ нові правила. Якийсь кац назвав цей паттерн ’Наїзд-відкат-від’їзд’ по якому силовики і законотворці ’спілкуються’ з бізнесом і до нас підходить.

архітектор який розуміє що в нього в проект спроектований на 3 з 10 не буде читати книги. Як тільки він підніме кваліфікацію оцінка проекту знизиться до 1 з 10 і буде геть сумно.

нетипізовані вказівники callback* це жесть, я уявляю якщо розвести по 2 командах, і використовувати різні версії + параметри змінювати. Це неможливо підтримувати.

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

Для цього одна людина має знати, як оті усі модулі працюють. А потім — мержи та пулл реквести та код ревью. І треш затягнеться на тиждень на рівному місці.

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

В мікросервісах всі умовні 50% делегуються відразу іншій команді, в якій свої пріорітети, і в найпростішому випадку в Вас задача сформулювати вимоги, і домовитись з іншою командою і чекати. В складніший — гра в пінгпонг і поламаний телефон.

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

в моноліті більшіть інтерфейсів працюють через пам’ять а не мережу. Версіонування їх не потрібне, тому що консистентність таких інтерфейсів зашита на рівні коду. Є компілятор який стежить за цим.

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

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

в мене моноліт, і тому все консистентно. всі модулі робочі і працюють. Навантаження на систему я знімаю лоад балансером. Де я зекономлю на мікросервісах? 150 МБ жорсткого диску ? ) Модуль навіть не завантажується в пам’ять якщо його не використовувати. Не говорячи про CPU. Виходить я трохи місця на жорсткому диску зекономив?

Має значення не розмір коду, а оперативка та проц. В моноліті купа модулів завантажені, кожний тримає свій стан.

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

в моноліті усім командам треба домовлятись про зміни

Бо моноліт може не влазити в один бокс,

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

а не влазити в один бокс... не знаю в скількох % проектів розмір артифактів dll має значення. Це мають бути гігабайти dll. Ніхто не згадує про кеш і лоад балансери.

погано те що дуже прості сценарії перестають бути такими з мікросервісами. Тут приводили статтю dwmkerr.com/...​oservice-madness-in-2018
Але простіше я вже говорив: 2 менші системи в загальному випадку складніше ніж одна для розробки і деплойменту. При тому значно складніше. Прості сценарії: невідповідність в DTO, пейджинація, невідповідність реквайрментів і коду. В монолітах таких проблем або немає за дизайном або вони вирішуються на етапі компіляції.

Не можна сказати що варто або ні запихати в один солюшен. Потрібні деталі. Але точто можна сказати коли що одну схему в одні базі підтримувати простіше ніж 2 схеми в двох базах які посилаються на одні дані. В загальному випадку неможливо навіть пейджинацію зробити. З цього можна картину малювати «адепт мікросервісу пояснює чому не можна заімплементити пейджинацію», з хмарками : гугл, амазон, майкрософт!!!!

Ви не знаєте точних умов. Суть в тому щоб сказати що краще, 1 солюшен на 20 проектів, на якому є умовний білд + тести, або 2 солюшени по 10 проектів.

можна уявити середній солюшен 20 проектів розбити на 2 по 10, закинути їх в 2 різні репозиторії і поєднати через json/xml. Спочатку це буде один розробник, і не буде складності з комунікацією. В якому випадку буде більше фейлів? Тепер переходимо від одного розробника до команд 5-10. Малюємо варіанти. А тепер уявити що склеювати до купи це все також будуть треті люди, які не знають деталей ні першого ні другого, обмежені в часі, і яким не можна або складно відмовити.

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

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

після тренду на мікросервіси кілька років тому в мене підірвалася віра в адекватне сприйняття реальності людьми. Купа проблем була очевидна при одному описі підходу: відмова від зберігання коду в одному місці і доступу туди всіх людей. Ок, припустимо, а костистентнісь як підтримувати, як версійність підтримувати? Дебаг не показав помилку, значить її немає? І звичайно на практиці все це вилазить. Просто кілька сценаріїв: переіменувати проперті, дізнатись як працює код залежності, подивитись логи сусіднього сервісу, видалити метод, дізнатись чи було щось виправлено в залежних сервісах. Ці всі проблеми були очевидними тільки при описі підходу. Такі підходи вигідні тільки аутсорсерам і клауд сервісам, а просувають їх в більшості теоретики, які не в курсі того як відбувається реальна розробка.

що він несе? мабуть хворий на голову

я гарантую.

цього не буде.

автопілоти краще вирішать цю проблему. Наче в тесли вийшло, явно не по скраму працюють

якщо коли вперше почули про автопілот тесли не схопилися за волосся або лисину