Implementácia mikroslužieb v produkčných prostrediach

Informatec Digital » Zdroje » Implementácia mikroslužieb v produkčných prostrediach

Prijatie architektúry mikroslužieb v reálnom prostredí neznamená len rozloženie monolitu na menšie časti; zahŕňa prehodnotenie infraštruktúry, tímov, procesov, údajov, bezpečnosti a operácií . Keď systém prechádza z teórie do produkčného klastra, vznikajú problémy týkajúce sa vyhľadávania služieb, zmlúv medzi tímami, CI/CD, pozorovateľnosti, odolnosti a škálovateľnosti. Ak sa tieto problémy správne neriešia, môžu zmeniť mikroslužby na distribuovaný chaos.

Dobrou správou je, že dnes máme bohaté skúsenosti z organizácií ako Netflix, Amazon, Google a ďalších veľkých korporácií, ktoré prevádzkujú stovky mikroslužieb v produkčnom prostredí . Na základe týchto poznatkov a osvedčených postupov v podnikových prostrediach využívajúcich Kubernetes a OpenShift môžeme vyvinúť veľmi robustný prístup k navrhovaniu, nasadzovaniu a prevádzke mikroslužieb vo veľkom meradle bez straty kontroly.

Prečo nasadzovať mikroslužby do produkčného prostredia (a kedy sa to neoplatí)

Dobre navrhnutá architektúra mikroslužieb vám umožňuje pracovať s malými, autonómnymi a multifunkčnými tímami , ktoré preberajú zodpovednosť za komplexnú službu. Každý tím pracuje v jasne definovanom kontexte, môže často nasadzovať a preberať plnú zodpovednosť za svoju službu, čím sa skracuje čas vývojového cyklu a urýchľuje dodávanie nových funkcií.

Ďalšou kľúčovou výhodou je nezávislé škálovanie pre každú službu . Nemusíte predimenzovať celú aplikáciu, ak iba katalóg, pokladňa alebo verejné API zaznamenávajú špičky v prevádzke. Každú mikroslužbu môžete upraviť horizontálne alebo vertikálne podľa jej vzorca zaťaženia, presne merať náklady na každú funkciu a zachovať dostupnosť, aj keď v konkrétnej oblasti dôjde k nárastu spotreby.

Spôsob, akým sú tieto služby zabalené a nasadené, umožňuje nepretržitú implementáciu s nízkym rizikom . Nezávislé vydávanie každej mikroslužby značne zjednodušuje testovanie nových nápadov a vrátenie problematických verzií: kanárkové nasadenia, modré/zelené vrátenia verzií a automatizované vrátenia verzií znižujú náklady na zlyhanie a poskytujú priestor na experimentovanie.

Z technologického hľadiska mikroslužby podporujú slobodu výberu jazykov, frameworkov a databáz pre každú službu. Nie všetky potreby sa zmestia do rovnakého technologického balíka: môžete mať obchodné služby v .NET alebo Jave, spracovanie údajov v Scala/Spark, špecializované služby v Pythone alebo F# alebo mikroslužby umelej inteligencie v R. Táto kontrolovaná diverzita vám umožňuje použiť správny nástroj pre každý prípad bez toho, aby ste nútili celú aplikáciu ku globálnemu technologickému posunu.

Rozdelenie systému na malé, dobre definované časti navyše uľahčuje opätovné použitie funkcií ako stavebných blokov . Mikroslužba pôvodne vytvorená ako súčasť väčšej funkcionality sa môže neskôr opätovne použiť ako závislosť iných častí systému bez prepisovania logiky. A keďže sú služby izolované, zlyhanie jednej z nich zvyčajne vedie k čiastočnej degradácii systému, nie k úplnému výpadku systému, za predpokladu, že odolnosť bola navrhnutá od začiatku.

Architektonický a servisný dizajn

Aby mikroslužby dobre fungovali v produkčnom prostredí, je nevyhnutné začať s dôkladným návrhom hraníc služieb a zodpovedností . V praxi to zvyčajne začína identifikáciou hrubozrnných služieb v rámci existujúceho monolitu: rozsiahlych funkčných oblastí alebo obchodných domén (napr. objednávky, katalóg, používatelia, fakturácia), ktoré už majú určité logické oddelenie.

Vychádzajúc z týchto veľkých stavebných blokov, proces zahŕňa spresňovanie návrhu s cieľom získať jemne granulované mikroslužby, ktoré fungujú na koherentnej množine údajov , vlastnia vlastný model a presne vedia, čo potrebujú čítať alebo zapisovať do iných služieb. Tento proces sa zvyčajne spolieha na koncepty dizajnu riadeného doménou (DDD) a ohraničené kontexty, čím sa zabraňuje tomu, aby sa mikroslužba stala „mini monolitom“.

API, ktoré sprístupňujú tieto služby, musia mať dobre definované a stabilné zmluvy . To znamená prísnu dokumentáciu (REST s OpenAPI, gRPC so súbormi .proto atď.), explicitné verziovanie, udržiavanie spätnej kompatibility, kde je to možné, a automatizáciu overovania zmlúv na odhalenie kritických zmien predtým, ako sa dostanú do produkcie.

V prostrediach s desiatkami alebo stovkami služieb je kľúčové začleniť vzory odolnosti už od fázy návrhu, aby bol systém pripravený na čiastočné zlyhania . Vzory, ako sú ističe, opakované pokusy s odloženou prevádzkou, dobre definované časové limity, prepážky a protitlak, pomáhajú zabrániť tomu, aby zlyhanie jednej služby spôsobilo výpadok ostatných. Nástroje Chaos Engineering, ako napríklad ChaosMonkey alebo Gremlin, sú užitočné na praktické testovanie správania platformy pri simulovaných výpadkoch.

Mnohé zložité systémy kombinujú relatívne jednoduché služby CRUD so sofistikovanejšími službami, ktoré spracovávajú vyvíjajúce sa obchodné pravidlá. Nie všetky mikroslužby vyžadujú zložitú internú architektúru : niektoré môžu byť jednoduché HTTP ovládače so základným prístupom k údajom, zatiaľ čo iné, ako napríklad služby objednávok alebo fakturácie, môžu využívať pokročilejšie vzory (DDD, CQRS, udalosti domén atď.).

Produkčná infraštruktúra: cloud, kontajnery a Kubernetes/OpenShift

Reálne skúsenosti ukazujú, že mikroslužby fungujú oveľa lepšie, keď sú nasadené v cloudovej infraštruktúre s kontajnermi a orchestráciou, ako na izolovaných virtuálnych počítačoch. Platformy ako Kubernetes a OpenShift poskytujú potrebné primitívy na balenie služieb ako kontajnerov, škálovanie, aktualizáciu, vyrovnávanie záťaže a správu vysokej dostupnosti.

Každá mikroslužba je zvyčajne zabalená v kontajnerovom obraze založenom na základnom firemnom obraze (napríklad OpenJDK 21 pre služby Java), ktorý spravuje infraštruktúrny tím. Tento základný obraz je aktualizovaný bezpečnostnými záplatami a po vydaní novej verzie sú vývojové tímy zodpovedné za prestavbu a opätovné nasadenie svojich služieb v zodpovedajúcich prostrediach.

V Kubernetes/OpenShift je základnou jednotkou nasadenia pod, ktorý zapuzdruje jeden alebo viac kontajnerov . Mikroslužba zvyčajne zodpovedá typu pod a nasadzuje sa pomocou zdrojov, ako sú Deployments (pre bezstavové služby) alebo StatefulSets (ak existuje priradený stav). Od začiatku je definovaný minimálny počet replík na prostredie, aby testovacie, predprodukčné a produkčné prostredia mali úrovne dostupnosti zodpovedajúce ich kritickosti.

Automatické škálovanie je implementované pomocou HorizontalPodAutoscaler (HPA) , ktorý upravuje počet replík na základe metrík, ako je CPU, pamäť alebo iné vlastné metriky. Platforma musí tiež nakonfigurovať pravidlá anti-afinity podov, aby distribuovala repliky tej istej služby medzi rôzne uzly, čím sa zabráni zlyhaniu jedného uzla, ktoré by zničilo všetky inštancie.

Pokiaľ ide o vertikálne dimenzovanie, resources.requests a resources.limits sa používajú na definovanie rozsahu CPU a pamäte, ktoré môže pod spotrebovať. Napríklad rezervovanie minimálne 100 MB CPU a 256 MB pamäte a povolenie až 500 MB a 2 GB pre službu Java, úprava JVM (Xms, Xmx, Xss) tak, aby sa čo najlepšie využili zdroje kontajnera.

Správa stavu: bezstavové a stavové mikroslužby

Väčšina podnikových mikroslužieb je navrhnutá ako bezstavové služby . To znamená, že pod neukladá informácie, ktoré musia prežiť reštartovanie; stav sa uchováva v externých databázach, frontoch správ alebo inom úložisku. Tento prístup umožňuje dynamické horizontálne škálovanie a bezproblémové nasadenie, pretože akákoľvek replika dokáže spracovať akúkoľvek požiadavku.

Existujú však scenáre, kde neexistuje žiadna iná alternatíva, než mať stavové mikroslužby podporované perzistentnými zväzkami . To je prípad niektorých databáz, distribuovaných súborových systémov alebo komponentov, ktoré vyžadujú údržbu lokálnych údajov. Tieto pody sa zvyčajne nasadzujú so StatefulSets, prepájajú sa s PersistentVolumes pomocou PersistentVolumeClaims a škálujú sa vertikálne, nie horizontálne.

Keď mikroslužba potrebuje trvalé úložisko, vyžiada sa PersistentVolumeClaim (PVC) s jeho veľkosťou, režimom prístupu a zamýšľaným použitím a operačný tím ho zriadi podľa politík platformy. Toto PVC je uvedené v manifeste nasadenia a je pripojené k podu, aby služba mohla trvalo čítať a zapisovať údaje.

Hoci v špecifických prípadoch môžu byť stavové modely nevyhnutné, všeobecné odporúčanie je ponechať čo najviac služieb bez uchovávania štátnej príslušnosti . To zjednodušuje nasadenie, škálovanie, odolnosť a obnovu po havárii a znižuje prevádzkovú zložitosť v prostrediach s mnohými mikroslužbami.

Decentralizácia údajov a suverenita služieb

V tradičných infraštruktúrach je bežné centralizovať databázy a úložiská, aby sa maximalizovala efektivita. Pri mikroslužbách je tento prístup v konflikte s autonómiou a oddelením tímov . Ak mnoho služieb zdieľa rovnakú relačnú schému, akákoľvek štrukturálna zmena môže blokovať viacero tímov a neúmyselne narušiť kompatibilitu.

Preto sa odporúča, aby každá mikroslužba vlastnila svoj vlastný dátový model a databázu , hoci vo vývojovom prostredí táto databáza beží ako kontajner v rámci klastra, aby sa zjednodušilo nasadenie. V produkčnom prostredí sa zvyčajne používajú cloudovo spravované inštancie alebo iné databázové servery s vysokou dostupnosťou, pričom sa vždy zachováva jasná hranica vlastníctva.

To neznamená, že neexistuje žiadna integrácia údajov; znamená to, že konzistencia medzi službami je riadená udalosťami a asynchrónnym posielaním správ , pričom sa akceptuje prípadná konzistencia, keď je to primerané. Na šírenie zmien stavu medzi mikroslužbami sa bežne používajú zbernice udalostí (RabbitMQ, Azure Service Bus, Kafka atď.), čím sa znižuje silná závislosť od jednej databázy.

Cloudová platforma uľahčuje tímom výber optimálneho typu databázy pre každú službu (relačná, dokumentová, kľúč-hodnota, časový rad atď.) bez toho, aby bolo potrebné vnútiť jednu technológiu. Kľúčové je, aby návrh zohľadňoval možnosť migrácie schém a štruktúr bez porušenia zmlúv s inými službami a aby sa rozhodnutia o údajoch prijímali v súlade s hranicami domény každej mikroslužby.

Distribuované riadenie, tímy a organizácia

Prechod na mikroslužby bez zmeny organizácie si koleduje o problémy. Namiesto klasických funkčných silá sietí, systémov, databáz, vývoja a prevádzky sa odporúča štruktúra založená na produktových tímoch, ktoré spájajú profily z oblasti vývoja, QA, DevOps a prípadne aj obchodných alebo dátových analytikov.

Každý tím je zodpovedný za jednu alebo viac mikroslužieb v rámci tej istej funkčnej domény, pričom sa stará o vývoj aj prevádzku (vytvoríte to, vy to spustíte) . To znamená, že tím spravuje svoje CI/CD kanály, spolupracuje s infraštruktúrou pre špecifické potreby a podieľa sa na monitorovaní a reakcii na incidenty. Infraštruktúra a cloudová platforma sa zameriavajú na poskytovanie spoločných a štandardizovaných služieb.

Aby sa zabránilo tomu, aby sa táto distribuovaná správa riadení premenila na anarchiu, je nevyhnutné definovať jednoduché štandardy a zdieľané katalógy : schválené základné obrazy, vzory nasadenia, konvencie pomenovania pre menné priestory a služby, pokyny pre API, šablóny Dockerfile a Kustomize atď. Tieto pokyny slúžia ako „zábradlia“, ktoré orientujú tímy bez toho, aby blokovali ich schopnosť robiť rozhodnutia.

V mnohých podnikových prostrediach sa pre každý projekt alebo doménu používajú samostatné menné priestory , pričom aspoň jeden je pre každé prostredie (vývoj, predprodukcia, produkcia). Veľký projekt môže distribuovať svoje mikroslužby do niekoľkých menných priestorov za predpokladu, že je interná komunikácia správne nakonfigurovaná a sú dodržiavané bezpečnostné pravidlá.

CI/CD, automatizácia a model GitOps

Keď architektúra obsahuje desiatky alebo stovky mikroslužieb, jediný spôsob, ako ich udržať v prevádzke, je výrazne investovať do komplexnej automatizácie . To zahŕňa konzistentné kanály CI/CD, deklaratívne definície nasadenia, automatizované testovanie a mechanizmy automatického vrátenia zmien.

Typický kanál kontinuálnej integrácie a doručovania zabezpečuje kompiláciu kódu, spúšťanie testov, analýzu kvality pomocou nástrojov ako SonarQube , zostavenie obrazu kontajnera z firemného Dockerfile a aktualizáciu manifestov nasadenia. Odtiaľ systém ako ArgoCD alebo podobný aplikuje zmeny na klaster pomocou prístupu GitOps.

Každý repozitár mikroslužieb zvyčajne obsahuje štandardizovaný súbor Dockerfile, konfiguračný súbor kanála (napr. ci.json) , vlastnosti pre analýzu kvality a adresár nasadenia s definíciami Kubernetes (Kustomize alebo Helm) oddelenými podľa prostredia. Webhooky repozitára spúšťajú kanál, keď dôjde k udalostiam, ako sú napríklad odoslania značiek alebo požiadavky na zlúčenie.

Vzor GitOps zavádza repozitár Git ako zdroj informácií o infraštruktúre a nasadení . Manifesty pre nasadenia, služby, ConfigMaps, PVC, SealedSecrets a ďalšie zdroje sú verzované tam a špecifické nástroje spracovávajú synchronizáciu stavu klastra s tým, čo je definované v Gite. To poskytuje sledovateľnosť, kontroly pull requestov a jednoduché možnosti vrátenia zmien.

Nastavenia, tajomstvá a zabezpečenie

V rozvinutej platforme mikroslužieb sa správa konfigurácie spolieha na ConfigMaps pre necitlivé parametre a Secrets pre dôverné informácie . Každá mikroslužba má zvyčajne svoj vlastný ConfigMap špecifický pre dané prostredie, ktorý ukladá vlastnosti, ako sú URL adresy závislých služieb, príznaky funkčnosti a parametre ladenia.

Tajomstvá (poverenia, kľúče, tokeny, certifikáty) sú spracované podľa prísnych bezpečnostných politík . V menej kritických prostrediach môže byť prijateľné uchovávať ich v obyčajnom texte spravovanom vývojovým tímom, ale v predprodukčnom a produkčnom prostredí sa odporúča šifrovať ich pomocou nástrojov, ako sú Sealed Secrets alebo špecifických externých cloudových správcov.

Keď je potrebné zdieľať tajný kľúč medzi viacerými službami (napríklad prihlasovacie údaje OTEL Collector alebo spoločný úložisko kľúčov ), môže byť centralizovaný v konfiguračnom úložisku pre každý menný priestor. Projekty zdieľajúce tento menný priestor koordinujú jeho aktualizáciu podľa potreby a zachovávajú si kontrolu nad tým, kto môže tieto zdroje čítať alebo upravovať.

Z hľadiska bezpečnosti komunikácie je dominantným vzorom nulová dôvera : nič sa neberie ako samozrejmosť len preto, že prevádzka je „interná“. Všetky volania medzi službami, internými aj externými, musia byť overené a autorizované, ideálne pomocou tokenov mTLS, JWT alebo iných ekvivalentných mechanizmov. Mikroslužby slepo nedelegujú bezpečnosť na správcu API alebo sieť; vykonávajú aj vlastné kontroly.

Komunikácia medzi mikroslužbami, API a systémom správ

V rozvinutej architektúre mikroslužieb je komunikačná vrstva rozdelená do niekoľkých prípadov. Pre prevádzku z klientov (prehliadače, mobilné aplikácie, tretie strany) do back-endu sa používajú publikované API riadené správcom API . Tieto API sú zvyčajne RESTful (často používajúce OpenAPI) alebo v niektorých prípadoch gRPC sprístupnené cez bránu.

Hovory medzi mikroslužbami nachádzajúcimi sa v rovnakom mennom priestore alebo dokonca vo viacerých menných priestoroch v rámci toho istého projektu zvyčajne spracovávajú interné služby Kubernetes s interným DNS . Tieto volania obchádzajú verejného API Managera, ale dodržiavajú pravidlá zabezpečenia, autentifikácie a autorizácie. V týchto scenároch je možné použiť sieť služieb alebo interné brány, ktoré vynucujú spoločné pravidlá.

Keď mikroslužby patria do rôznych funkčných domén alebo projektov , komunikácia sa na organizačnej úrovni považuje za „verejnú“. V týchto prípadoch je bežnou praxou používať API Manager alebo zbernicu interoperability, kde sa spravujú zmluvy, kvóty, zabezpečenie, verziovanie a audit, čím sa zabraňuje priamemu prepojeniu medzi nezávislými klastrami alebo mennými priestormi.

Pokiaľ ide o integráciu so staršími alebo externými systémami, ktoré nemusia vždy sprístupniť moderné API, je bežné spoliehať sa na špecifické konektory cez zbernicu interoperability . Týmto spôsobom mikroslužby hovoria spoločným jazykom (napríklad udalosti alebo interné REST API) a konektor spracováva preklad do a zo staršieho systému, vždy so zvýšeným zabezpečením.

Okrem synchrónnej komunikácie zohráva kľúčovú úlohu aj asynchrónne zasielanie správ . Používa sa na oddelenie procesov, absorbovanie špičiek, šírenie obchodných udalostí medzi službami a zlepšenie odolnosti. Každá udalosť má zvyčajne dobre definovanú a verziovanú schému s mechanizmami sledovania, ktoré zabraňujú poruchám medzi výrobcami a spotrebiteľmi počas ich vývoja.

Pozorovateľnosť, OTEL kolektor a prevádzka

V systéme zloženom z mnohých mikroslužieb je diagnostika problému bez dobrej pozorovateľnosti takmer nemožná. Preto sú metriky, centralizované protokolovanie a distribuované sledovania integrované už od fázy návrhu , čo umožňuje pochopiť, čo sa deje na úrovni služby aj platformy.

Ústredným komponentom tejto schémy je OpenTelemetry Collector (OTEL Collector) , ktorý je nasadený v mennom priestore alebo centrálne na zhromažďovanie metrík, protokolov a trás zo všetkých komponentov. Mikroslužby potrebujú vedieť iba to, že by mali odoslať svoju telemetriu do Collectoru; Collector ju potom prepošle do systémov pozorovateľnosti (Prometheus, Grafana, Jaeger, Elastic atď.) bez toho, aby služba potrebovala poznať podrobnosti.

Pre vrstvu infraštruktúry sa na zhromažďovanie metrík CPU, pamäte, disku, siete a protokolov z podov používajú zberače a exportéry na úrovni uzlov , ktoré sa odosielajú do Prometheus a Elasticsearch. Nástroje ako Grafana a Kibana sa používajú na vizualizáciu týchto informácií, vytváranie dashboardov a definovanie upozornení s inteligentnými prahovými hodnotami a súvisiacimi runbookmi.

Keď projekt vyžaduje veľmi špecifické spracovanie svojich metrík alebo sledovaní, môže nasadiť vlastnú inštanciu OTEL Collector vo svojom mennom priestore, za predpokladu, že má prevádzkové schválenie a model údržby produkcie je jasný.

Stratégia testovania, zmluvy a skúsenosti s lokálnym vývojom

Testovanie distribuovanej architektúry mikroslužieb si vyžaduje sofistikovanejšiu stratégiu testovania ako testovanie monolitu. Jednotkové testy zostávajú nevyhnutné, ale čoraz dôležitejšie sú zmluvné testy (pre API a udalosti), integračné testy medzi službami a end-to-end testy, ktoré prechádzajú celými tokmi.

Na predchádzanie problémom s kompatibilitou sa používajú techniky, ako je testovanie zmlúv orientované na spotrebiteľa , kde klienti definujú očakávania API a poskytovatelia služieb ich plnia. Každá zmena zmluvy prechádza automatizovaným testovaním v rámci CI kanálov, čím sa zabráni nasadeniam, ktoré narušia akýchkoľvek známych spotrebiteľov.

Keď počet služieb presiahne sto, lokálna replikácia celého systému sa stáva nepraktickou. Vývoj sa preto spolieha na simulácie závislých služieb alebo tunelovanie do vzdialených prostredí . Vývojári zvyčajne spúšťajú iba podmnožinu mikroslužieb a zvyšok blokujú pomocou napodobenín, falzifikátov alebo simulátorov, prípadne presmerujú určité volania do zdieľaného integračného prostredia.

Komplexné testovanie sa čoraz viac spolieha na prchavé prostredia alebo „ukážky“ vytvorené z vetiev funkcií , ktoré vytvárajú izolované prostredie so službami relevantnými pre danú funkcionalitu. To minimalizuje trenie medzi tímami, znižuje efekt „funguje to na mojom počítači“ a odhaľuje problémy s integráciou predtým, ako sa dostane do drahších prostredí, ako je napríklad predprodukcia.

Vzory nasadenia mikroslužieb v produkčnom prostredí

Okrem Kubernetes existuje v produkčnom prostredí niekoľko vzorov nasadenia mikroslužieb, ktoré sa oplatí poznať, pretože riešia rôzne scenáre izolácie, nákladov a zrelosti . Jedným z najstarších vzorov sú viaceré inštancie služieb na hostiteľa, kde jeden fyzický alebo virtuálny hostiteľ spúšťa niekoľko inštancií rôznych služieb, zvyčajne na zdieľanom aplikačnom serveri.

V vzore inštancie služby pre jednotlivé virtuálne počítače je každá služba zabalená ako obraz virtuálneho počítača (napríklad EC2 AMI) a beží na vlastnej inštancii. To ponúka silnú izoláciu za cenu vyššej spotreby zdrojov a pomalších časov spustenia. Nástroje ako Packer alebo riešenia špecifické pre poskytovateľov cloudu uľahčujú generovanie obrazov virtuálnych počítačov pripravených na produkciu.

Najrozšírenejším vzorom je dnes inštancia služby na kontajner , kde je každá mikroslužba zostavená ako obraz kontajnera a nasadená na orchestrator (Kubernetes, OpenShift atď.). Kontajnery sú ľahšie ako virtuálne počítače, spúšťajú sa veľmi rýchlo a umožňujú vám zabaliť všetko potrebné pre službu, čo zjednodušuje nasadenie a umožňuje automatické škálovanie.

Nakoniec si získali popularitu aj bezserverové prístupy, ako napríklad AWS Lambda . Tieto balíky obsahujú funkcie, ktoré reagujú na HTTP požiadavky alebo udalosti z iných služieb (S3, DynamoDB, fronty atď.), pričom používatelia platia iba za to, čo používajú. Tento vzor je obzvlášť vhodný pre veľmi malé mikroslužby alebo krátkodobé úlohy riadené udalosťami, hoci zavádza ďalšie aspekty týkajúce sa pozorovateľnosti, studeného štartu a limitov vykonávania.

V praxi mnoho organizácií skončí s hybridným ekosystémom: jadro systému beží na kontajneroch a orchestrátoroch, zatiaľ čo niektoré pomocné komponenty sú implementované ako bezserverové funkcie alebo ako špecializované virtuálne počítače, vždy s jasnými rozhraniami a dobre definovanými protokolmi na ich integráciu do celku.

Pokiaľ ide o uvedenie všetkých týchto prvkov do produkčného prostredia, rozdielom nie je len zvolená technológia, ale aj vybudovanie architektúry, ktorá toleruje chyby, škáluje sa podľa potreby, automaticky sa nasadzuje a je pozorovateľná . Vďaka tímom zosúladeným s produktmi, dobre spravovaným zmluvám, decentralizovaným údajom a robustnej cloudovej platforme sa mikroslužby menia z prísľubu na efektívny a udržateľný spôsob vývoja zložitých aplikácií na roky.