Nedávno jsme pomáhali jednomu klientovi s modernizací jeho systému. Šlo o firmu, ve které dělali všechno podle nejlepších praktik – snažili se o jednotný datový model, minimalizovali duplicity, drželi se principu DRY (Don’t Repeat Yourself). Jenže po pěti sprintech zjistili, že místo zjednodušení mají ještě složitější systém než předtím. Kde byl problém? Snažili se vtěsnat potřeby všech oddělení do jednoho modelu. Slovo „zákazník“ znamenalo pro každého něco jiného:

Pro obchodníky to byl kontakt s několika nabídkami, různými cenami, bez nutnosti vyplňovat detaily. Potřebovali rychle poslat pět variant nabídky a sledovat, která zabere. Adresa? Telefon? To přijde až později. Jenže např. pro compliance musí mít zákazník kompletní údaje – adresu, IČO, pozici kontaktní osoby, jednu finální cenu. Bez toho nemůžou vystavit fakturu, natož splnit regulatorní požadavky.

Výsledek? Monstrózní kód plný podmínek typu „pokud je zákazník ve stavu nabídka, tak..., ale pokud je ve stavu smlouva, tak...“. Každá změna pro obchod rozbila něco v compliance. Každý požadavek compliance zpomalil obchodníky. Regresní testy trvaly věčnost.

Nebyla to jejich chyba. Dělali to, co dává intuitivně smysl – minimalizovat redundanci, mít jednu databázi, jeden zdroj pravdy. Jenže zapomněli na jednu věc: náklady na lidi mnohonásobně převyšují náklady na infrastrukturu.

Většina firem se snaží o stejnou věc – být agilní, rychle reagovat na změny. A většina IT oddělení reaguje stejně: vytvoří jednotný systém, který má obsloužit všechny. Dává to smysl, ne? Jedna databáze, žádné duplicity, jeden zdroj pravdy. Jenže pak přijde realita. Obchodník potřebuje flexibilitu – rychle vytvořit lead, poslat nabídky s různými cenami, neztratit čas vyplňováním zbytečností. Compliance zase potřebuje kompletnost – všechny údaje, audit trail, jednu závaznou cenu. Marketing chce segmentaci a kampaně. Finance chtějí fakturační údaje.

Intuitivně se snažíme vyhnout redundanci. Přece nebudeme mít zákazníka na dvou místech! Jenže tím vytváříme něco mnohem horšího – komplexní kód, kde každá změna vyžaduje koordinaci čtyř týmů, tříměsíční analýzu dopadů a armádu testerů. Ušetříme na jedné databázi, ale zaplatíme desetinásobek na lidech.

 

Tady přichází paradigmatický posun. Co když redundance není nepřítel, ale spojenec? Co kdybychom přestali optimalizovat počet databází a začali optimalizovat rychlost dodávky a náklady na změny?

Představte si: obchod má svůj mikroservis „Sales Leads“ s flexibilním modelem pro nabídky. Compliance má svůj „Contract Management“ s přísnými pravidly. Ano, některá data jsou na dvou místech, ale také díky tomu:

Mikroslužby neděláme kvůli technologii. Děláme je proto, aby se nám vyplatilo dělat změny. Cena za redundantní infrastrukturu je směšná proti ceně za koordinaci, analýzy, testování a opravy chyb v monolitickém systému.

Buďme upřímní – mikroservisní architektura není procházka růžovým sadem. Je komplexní, náročná na koordinaci a může být drahá. Pokud ji zavedete jen proto, že je to moderní, připravte se na peklo.

Viděl jsem projekty, kde rozdělili monolitickou aplikaci na 50 mikroslužeb bez jakékoliv doménové logiky. Výsledek? Technicky rozdrobený systém, který byl pomalejší, dražší a nikdo mu nerozuměl. Klasický případ, kdy lék byl horší než nemoc.

Ale když mikroslužby kopírují realitu vašeho byznysu – strukturu týmů, datové toky, obchodní procesy – vznikne něco úžasného. Systém, který je nejen technicky elegantní, ale hlavně srozumitelný všem zúčastněným.

V praxi to vypadá takto: tým zodpovědný za platby má svůj mikroservis, vlastní CI/CD pipeline a jasně definované rozhraní. Nemusí čekat na tým, který dělá objednávky. Nemusí se hádat, čí je to bug. Každý má svůj písek na hraní a jasná pravidla, jak si předávat hračky.

A když to celé běží na rozumné platformě, máte vyřešenou i infrastrukturu a tooling. Ale pozor – platforma bez správné doménové architektury je jen drahý CI/CD orchestrátor. A doménová architektura bez platformy? To je zase jen hezký dokument v Confluence, který nikdy nikdo nenasadí.

Po letech v oboru jsem pochopil jednu věc: Kód není produkt. Produkt je hodnota, kterou přinášíme. A tu hodnotu vytvoříme jen tehdy, když si všichni zúčastnění rozumí.

Mikroslužby nejsou cíl samy o sobě. Jsou prostředek, jak dosáhnout něčeho mnohem důležitějšího – společného jazyka mezi IT a byznysem. Nejde o počet repozitářů nebo Docker kontejnerů. Jde o to, aby tomu, co vytváříme, rozuměli ti, kdo to platí, provozují a používají. Když se nám to podaří, přestane být software překážkou. Stane se z něj akcelerátor byznysu. A to je přesně to, co všichni chceme, ne?