Laravel architektura: Proč většina projektů nepotřebuje microservices

V posledních letech se microservices objevují na každé konferenci, v každém blogpostu a v každé druhé firmě, která chce působit moderně. Ale potřebuje je opravdu každý projekt?

Sám jsem si tím prošel. Laravel projekty stavím roky, pracoval jsem na různě velkých systémech. A čím dál víc si stojím za tím, že dobře navržený monolit je v drtivé většině případů ta nejlepší možná cesta.

Proč (většinou) ne microservices

Microservices se často prodávají jako řešení pro škálování. Jenže tohle je hodně zjednodušené. Pokud má váš tým jen pár vývojářů (napočítáte je na prstech), microservices vám přinesou spíš problémy:

• Náročný DevOps: každá služba potřebuje své CI/CD, konfiguraci, monitoring, deployment. To není zdarma a vůbec ne lehké to vše uhlídat.
• Distributing tracing: sledovat chybu napříč více službami je výrazně náročnější.
• Závislosti mezi službami: když služba B spadne, co udělá A? Retry? Queue? Timeout? Logika se komplikuje.
• Orchestrace a verzování: API změny se musí plánovat, testovat, zohledňovat zpětnou kompatibilitu.
• Onboarding a vývoj trvá déle: nový vývojář se učí architekturu několika repozitářů místo jednoho.

Zkrátka – rychlost vývoje dramaticky klesá. Microservices možná dobře škálují horizontálně, ale týmově to nefunguje bez správné struktury, kultury a seniorních lidí.

Monolit: často podceňovaná architektura

Dobře navržený monolit v Laravelu (i kdekoliv jinde) vám přinese:

• Rychlejší vývoj: Všechno je v jednom repozitáři, tým může iterovat rychle.
• Snadnější refaktoring: Jedna CI pipeline, jedno prostředí, jasná struktura.
• Lepší onboarding: Nový vývojář se rychleji zorientuje.
• Jednodušší provoz: Méně běžících služeb, méně komplikací.

V kombinaci s modulární architekturou (např. Domains, Modules, Services, Actions) a přísným oddělením logiky od controllerů je možné udržet i větší aplikaci přehlednou a dlouhodobě životaschopnou.

Moje doporučení: Navrhujte monolit tak, jako byste ho jednoho dne museli rozdělit na microservices – i když ten den možná nikdy nepřijde.

Startup? Microservices? Spíš ne.

Tady je to úplně jasné. Startupy by se microservices měly obloukem vyhnout. Potřebujete validovat nápad, dodat MVP, rychle reagovat. Rozsekání na služby vás akorát zpomalí.

Proč by měl tým o třech lidech řešit orchestraci, event-driven komunikaci, vlastní API gateway a deployment pro pět různých repozitářů, když ještě neví, jestli projekt přežije první měsíc?

Monolit vám umožní dělat rychlé změny, upravit business logiku v jednom místě, a hlavně – iterovat bez overheadu. A o to jde v prvních měsících nejvíc.

Microservices mají své místo. Ale až později.

Neznamená to, že microservices jsou špatné. Jen jsou často nasazované moc brzo – ve chvíli, kdy by mnohem jednodušší řešení bohatě stačilo. Skutečný přínos microservices se totiž projeví až tehdy, když monolit přestává stíhat:

• pokud potřebujete nezávisle škálovat různé části systému
• pokud máte více týmů, které potřebují autonomii
• pokud potřebujete kombinovat různé technologie (např. PHP + Go + Node)

V takové situaci už má smysl o mikroarchitektuře uvažovat. Ale i tehdy se často ukáže, že bohatě stačí hybridní řešení – například API-first backend s odděleným frontendem nebo pár samostatných služeb tam, kde to opravdu dává smysl.

Jak poznat, že monolit už přestává stačit?

Monolit vám může sloužit roky, ale i ten má své limity. Tady je několik signálů, že možná nastal čas začít přemýšlet o oddělení některých částí systému:

• Různé části aplikace se vyvíjejí rozdílným tempem – např. API pro mobilní aplikaci vyžaduje časté změny, zatímco administrace zůstává stabilní.
• Tým se rozrůstá a naráží na konflikty v kódu – více lidí ve stejném repozitáři může zpomalovat vývoj.
• Některé části systému mají odlišné požadavky na škálování nebo dostupnost – třeba front-end API musí zvládat tisíce requestů za sekundu, zatímco CMS běží v klidu.
• Build trvá dlouho, testy se zpomalují a vývoj začíná být těžkopádný – v tu chvíli může dávat smysl oddělit např. reporting, API nebo joby do samostatné služby.

Ale i v těchto případech se dá často začít malým krokem – například vytěžením konkrétní části do balíčku, který se udržuje samostatně, ale zůstává součástí monolitu.

Kontext > trendy

Technologie nejsou cílem. Jsou prostředkem. A pokud je vaším cílem:

• doručit funkční produkt,
• validovat nápad,
• udržet tým produktivní,
• mít systém, který se dá rozvíjet bez chaosu,

…pak je dobře navržený monolit v Laravelu téměř vždy ta nejrychlejší a nejrozumnější volba.

Na závěr jen drobná poznámka: architektura je živá věc. Monolit, který dobře slouží teď, může být za dva roky potřeba rozdělit. A to je v pořádku – pokud jste s tím od začátku počítali a psali kód tak, aby to šlo. Tohle není výzva k tomu, abyste nikdy nepřemýšleli o microservices. Ale spíš výzva, abyste začali přemýšlet v kontextu.