Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×
  • Микросервисы это зло

    Імхо, мікросервіси — то не про мікро і не про сервіси. Це про команди та розробку.

    Інтернетами блукає такий мандат ще Джефа Безоса, кажуть, ще з 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 допоможуть оминути ями лише якщо про них знати, тому й знати про них потрібно :)