Мікросервіси

Віктор починає з фрази Саймона Брауна: «чому ви вважаєте, що зможете побудувати мікросервіси, якщо не можете побудувати моноліт?» (головна проблема мікросервісів). Він проходить по відомих витратах, які люди принаймні обговорюють: потрібна платформа оркестрації; rollback’и вимагають гарантій сумісності версій між сервісами; окрема база даних на кожен сервіс убиває транзакційність («розподілені транзакції — просто забудьте», з ілюстрацією на прикладі бухгалтерії); мережеві виклики падають так, як in-memory виклики в моноліті не падають ніколи; аргумент про поліглотність має сумнівну економіку; наймати людей стає складніше.

Але недооцінений вбивця, на його думку, — це знання домену: у перший день ви майже ніколи не розумієте домен достатньо добре, щоб правильно провести межі сервісів, — і, на відміну від моноліту, дешево перекроїти цей поділ уже не вийде. Неправильні абстракції трапляються і в монолітах, але виправити їх в одній кодовій базі легко; а між мікросервісами, написаними різними мовами й закріпленими за різними командами, — неймовірно важко. Спрощення кожного окремого сервісу теж не прибирає складність — вона мігрує на рівень комунікації і «перетворюється на кашу». Він пов’язує це з улюбленою ідеєю Роберта Мартіна: робота архітектора — відкладати рішення, бо розуміння домену покращується щодня, тож пізніші рішення кращі (те саме відео). Вердикт: у ~90% випадків починайте з модульного моноліту і розділяйте пізніше — як доказ він наводить статтю Medium про їхню міграцію.