Як перехід на мікросервіси створює проблему з робочим часом?

Наступний коментатор пише :

Мікросервіси переносять вашу організаційну дисфункцію з проблеми часу компіляції на проблему часу виконання.

Цей коментатор розкриває питання, кажучи:

Особливість не помилка. Проблема із запуском часу => Проблеми з продуктом => сильніші, швидші відгуки про дисфункцію для відповідальних

Тепер я це розумію з мікросервісами :

• потенційно збільшити затримку вашої рекламної кампанії - що викликає занепокоєння у виробництві та на час експлуатації.
• збільшити кількість "мережевих інтерфейсів" у вашому коді, де можуть бути потенційні помилки під час розбору.
• може потенційно робити синьо-зелені розгортання. Їх можна було б перешкодити невідповідності інтерфейсів (див. Мережеві інтерфейси). Але якщо синьо-зелені розгортання працюють, то це більше викликає занепокоєння.

Моє запитання: Що означає, що перехід на мікросервіси створює проблему з робочим часом?

У мене є проблема. Давайте використовувати мікросервіси! Зараз у мене 13 розподілених проблем.

Розділити вашу систему на інкапсульовані, згуртовані та роз'єднані компоненти - хороша ідея. Це дозволяє вирішувати різні проблеми окремо. Але ви можете це зробити прекрасно в монолітному розгортанні (див. Фаулер: Microservice Premium ). Зрештою, саме цьому навчає ООП вже багато десятиліть! Якщо ви вирішили перетворити свої компоненти в мікросервіси, ви не отримаєте жодної архітектурної переваги. Ви отримуєте певну гнучкість щодо вибору технології та, можливо, (але не обов'язково!) Деякої масштабованості. Але вам гарантується головний біль, що виникає з (а) розподіленого характеру системи та (б) зв'язку між компонентами. Вибір мікросервісів означає, що у вас є інші проблеми, які настільки нагальні, що ви готові користуватися мікросервісами, незважаючи на ці проблеми.

Якщо ви не зможете розробити моноліт, чітко розділений на компоненти, ви також не зможете розробити мікросервісну систему. У монолітній кодовій базі біль буде досить очевидною. В ідеалі код просто не складеться, якщо він жахливо порушений. Але за допомогою мікропослуг кожна служба може розроблятися окремо, можливо, навіть різними мовами. Будь-які проблеми у взаємодії компонентів не стануть очевидними, поки ви не інтегруєте свої компоненти, і тоді вже запізно виправити загальну архітектуру.

Джерелом помилок №1 є невідповідність інтерфейсу. Можуть бути яскраві помилки на зразок відсутнього параметра або більш тонкі приклади, наприклад, забувши перевірити код помилки або забути перевірити попередню умову перед викликом методу. Статична типізація виявляє такі проблеми якомога раніше: у вашому IDE та у компіляторі, перш ніж код коли-небудь запуститься. Динамічні системи не мають такої розкоші. Він не підірветься, поки не виконаний цей несправний код.

Наслідки для мікропослуг жахливі. Мікросервіси за своєю суттю динамічні. Якщо ви перейдете на офіційну мову опису послуги, ви не можете перевірити правильність використання інтерфейсу. ви повинні тестувати, тестувати, тестувати! Але тести є дорогими і, як правило, не вичерпними, що залишає можливість того, що проблеми все ж можуть існувати у виробництві. Коли ця проблема стане очевидною? Тільки тоді, коли цей несправний шлях буде взято у виробничий час. Думка про те, що проблематика продуктів призведе до швидшого зворотного зв’язку, євесело небезпечно неправильно, якщо ви не розвеселили можливість втрати даних.

Перший твіт був моїм, тому я розкрию його:

Припустимо, у вас є 100 розробників, які працюють над монолітним додатком. Занадто багато людей, щоб ефективно спілкуватися між собою, тому компанії доводиться наполегливо працювати, щоб розділити їх на менші команди та створити між ними хороші моделі спілкування. Коли організація «нефункціональна», команди, ймовірно, не розмовляють між собою, вони не прив’язані до більшої мети, вони не погоджуються щодо пріоритетів тощо - як наслідок, їм потрібно що-небудь надсилати щось. Це "проблема часу компіляції" в тому сенсі, що дисфункція очевидна ще до створення програмного забезпечення. Проект, ймовірно, марш смерті або ніколи не збирається відправляти ("компілювати").

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

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

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

Моє запитання: Що означає, що перехід на мікросервіси створює проблему з робочим часом?

Це не те, що ці твіти говорять! Вони нічого не говорять про перехід до мікропослуг , а також нічого не говорять про створення проблем. Вони говорять лише про перенесення проблем .

І вони ставлять контекстуальне обмеження на свої твердження, а саме на те, що ваша організація є нефункціональною.

Отже, що в основному перший твіт говорить про дві речі:

• "якщо ваша організація не здатна зараз створити складні системи без мікросервісів, вона не зможе магічно спроектувати складні системи з мікропослугами" і
• "проблеми, спричинені тією нездатністю, які тепер проявляються під час компіляції, тобто під час розробки, потім з’являться під час виконання, тобто у виробництві" (технічно вони також можуть з'являтися під час тестування, але пам’ятайте, цитата обмежує себе нефункціональним організаціям, які, ймовірно, мають нестандартний режим тестування)

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

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

Це створює проблему виконання часу, на відміну від проблеми компіляції- time.

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

І в монолітних системах, і в мікросервісах ви повинні визначати інтерфейси між підсистемами. Інтерфейси повинні бути продуманими, добре задокументованими та максимально стійкими. Це те саме, що і в ООП.

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

Якщо інтерфейс не розроблений належним чином, у вас з’являться два типи проблем виконання:

1. Якщо інтерфейс використовується неправильно, ви отримаєте помилку під час виконання, а не під час компіляції.
2. Виклик веб-інтерфейсу відбувається досить повільно, тому у вас можуть виникнути проблеми з продуктивністю.

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