— усі команди публікують функціонал через інтерфейси — усі команди використовують лише ті інтерфейси — оці інтерфейси повинні бути мережевими, жодних бекдорів — начхати на технології, що CORBA, що REST — всі інтерфейси потенціально публічні
У цього мандату є такі наслідки: — кожен інтерфейс є контрактом щонайменше двох команд — жоден розобник не може піти і просто змінити щось у інтерфейсі — кожен сервіс може мати свій SLA та деплоймент — зміну кожного сервісу можна тестувати окремо, використовуючи решту як надійне оточення — кожен сервіс/команда має свободу вибору технологій (стек, база)
Я як описую ці принципи своїм розробниками, вони мені кажуть, що то ж мікросервіси і є :)
Як ці принципи застосувати, то й патерни запрацюють як треба. От, наприклад, сага: якщо сервіси доступні 99.9% часу, всі про це знають та використовують circuit breaker, та є ідемпотентні дії та компенсуючі дії, то сага може надійно забезпечити потрібний рівень цілісності даних. Вартість того буде вище, ніж в одній базі, але ж і розподіляється значно краще. А як передумови не виконати, то буде ж дурня, звичайно.
Там ще Кріс Річардсон пише про дорожні ями на шляху до мікросервісів. Він добре розповідає про них на усіляких конференціях: m.youtube.com/watch?v=RFiOjywaELg Імхо, усі ті патерни чи Architecture Assessment Platform допоможуть оминути ями лише якщо про них знати, тому й знати про них потрібно :)
Імхо, мікросервіси — то не про мікро і не про сервіси. Це про команди та розробку.
Інтернетами блукає такий мандат ще Джефа Безоса, кажуть, ще з 2002 року: homepages.dcc.ufmg.br/...v/pmcc/modularization.pdf
— усі команди публікують функціонал через інтерфейси
— усі команди використовують лише ті інтерфейси
— оці інтерфейси повинні бути мережевими, жодних бекдорів
— начхати на технології, що CORBA, що REST
— всі інтерфейси потенціально публічні
У цього мандату є такі наслідки:
— кожен інтерфейс є контрактом щонайменше двох команд
— жоден розобник не може піти і просто змінити щось у інтерфейсі
— кожен сервіс може мати свій SLA та деплоймент
— зміну кожного сервісу можна тестувати окремо, використовуючи решту як надійне оточення
— кожен сервіс/команда має свободу вибору технологій (стек, база)
Я як описую ці принципи своїм розробниками, вони мені кажуть, що то ж мікросервіси і є :)
Як ці принципи застосувати, то й патерни запрацюють як треба. От, наприклад, сага: якщо сервіси доступні 99.9% часу, всі про це знають та використовують circuit breaker, та є ідемпотентні дії та компенсуючі дії, то сага може надійно забезпечити потрібний рівень цілісності даних. Вартість того буде вище, ніж в одній базі, але ж і розподіляється значно краще. А як передумови не виконати, то буде ж дурня, звичайно.
Там ще Кріс Річардсон пише про дорожні ями на шляху до мікросервісів. Він добре розповідає про них на усіляких конференціях: m.youtube.com/watch?v=RFiOjywaELg Імхо, усі ті патерни чи Architecture Assessment Platform допоможуть оминути ями лише якщо про них знати, тому й знати про них потрібно :)