- Mikroteenused nõuavad teenuste, andmete, vastupidavuse ja lepingute hoolikat kavandamist, et need oleksid tootmises elujõulised.
- Kubernetes/OpenShift, CI/CD ja GitOps võimaldavad suuremahuliste juurutuste, skaleerimise ja toimimise automatiseerimist.
- Platvormi alustaladeks on nullusaldusväärsus, tugev konfiguratsioonihaldus ja OpenTelemetry jälgitavus.
- Tootemeeskonna korraldus ja hajutatud juhtimine on sama olulised kui valitud tehnoloogia.
Mikroteenuste arhitektuuri kasutuselevõtt reaalses keskkonnas ei tähenda ainult monoliidi väiksemateks osadeks lammutamist; see hõlmab infrastruktuuri, meeskondade, protsesside, andmete, turvalisuse ja toimingute ümbermõtestamist . Kui süsteem liigub teooriast tootmisklastrisse, tekivad probleemid teenuste avastamise, meeskondadevaheliste lepingute, CI/CD, jälgitavuse, vastupidavuse ja skaleeritavusega. Kui neid probleeme korralikult ei lahendata, võivad need muuta mikroteenused hajutatud kaoseks.
Hea uudis on see, et tänapäeval on meil rikkalik kogemustepagas sellistelt organisatsioonidelt nagu Netflix, Amazon, Google ja teised suurettevõtted, mis käitavad tootmises sadu mikroteenuseid . Tuginedes neile õppetundidele koos parimate tavadega ettevõttekeskkondades, kus kasutatakse Kubernetesit ja OpenShifti, saame välja töötada väga tugeva lähenemisviisi mikroteenuste kavandamiseks, juurutamiseks ja käitamiseks ulatuslikult, kaotamata kontrolli.
Miks juurutada mikroteenuseid tootmiskeskkonda (ja millal see pole seda väärt)
Hästi läbimõeldud mikroteenuste arhitektuur võimaldab teil töötada väikeste, autonoomsete ja valdkondadevaheliste meeskondadega , kes võtavad vastutuse tervikliku teenuse eest. Iga meeskond tegutseb täpselt määratletud kontekstis, saab sageli juurutada ja võtab oma teenuse eest täieliku vastutuse, vähendades arendustsükli aega ja kiirendades uute funktsioonide tarnimist.
Teine oluline eelis on teenusepõhine iseseisev skaleerimine . Te ei pea kogu rakendust üle mastaapima, kui ainult kataloog, kassas või avalikus API-s esineb liikluse järsku suurenemist. Saate iga mikroteenust horisontaalselt või vertikaalselt vastavalt selle koormusmustrile reguleerida, täpselt mõõta iga funktsiooni maksumust ja säilitada kättesaadavuse isegi siis, kui konkreetses piirkonnas toimub tarbimise järsk tõus.
Nende teenuste pakendamise ja juurutamise viis hõlbustab pidevat ja väikese riskiga juurutamist . Iga mikroteenuse eraldi väljaandmine muudab uute ideede testimise ja problemaatiliste versioonide taastamise palju lihtsamaks: juhuslikud juurutused, sinised/rohelised tagasipööramised ja automatiseeritud tagasipööramised vähendavad ebaõnnestumise kulusid ja pakuvad ruumi katsetamiseks.
Tehnoloogilisest vaatenurgast soodustavad mikroteenused vabadust valida iga teenuse jaoks keeli, raamistikke ja andmebaase. Kõik vajadused ei mahu samasse tehnoloogiapaketti: teil võivad olla äriteenused .NET-is või Javas, andmetöötlus Scalas/Sparkis, spetsialiseeritud teenused Pythonis või F#-s või tehisintellekti mikroteenused R-is. See kontrollitud mitmekesisus võimaldab teil kasutada iga juhtumi jaoks õiget tööriista, ilma et kogu rakendust globaalseks tehnoloogiliseks nihkeks sunnitaks.
Lisaks hõlbustab süsteemi väikesteks, täpselt määratletud osadeks jagamine funktsionaalsuste taaskasutamist ehitusplokkidena . Algselt suurema funktsionaalsuse osana loodud mikroteenust saab hiljem taaskasutada süsteemi teiste osade sõltuvusena ilma loogikat ümber kirjutamata. Ja kuna teenused on isoleeritud, põhjustab ühe neist rike tavaliselt osalist süsteemi halvenemist, mitte täielikku süsteemi seisakut, eeldusel, et vastupidavus on algusest peale sisse ehitatud.
Arhitektuuriline ja teenuste disain
Selleks, et mikroteenused tootmises hästi toimiksid, on oluline alustada teenuste piiride ja vastutuse hoolika kavandamisega . Praktikas algab see tavaliselt olemasoleva monoliidi jämedateraliste teenuste tuvastamisega: suured funktsionaalsed alad või ärivaldkonnad (nt tellimused, kataloog, kasutajad, arveldamine), millel on juba teatav loogiline eraldatus.
Alustades nendest suurtest ehitusplokkidest, hõlmab protsess disaini täiustamist, et saada peenelt detailseid mikroteenuseid, mis töötavad sidusa andmestiku peal , omavad oma mudelit ja teavad täpselt, mida nad peavad teistelt teenustelt lugema või neile kirjutama. See protsess tugineb tavaliselt domeenipõhisele disainile (DDD) ja piiratud kontekstidele, mis takistab mikroteenuse muutumist "minimonoliidiks".
Neid teenuseid pakkuvatel API-del peavad olema täpselt määratletud ja stabiilsed lepingud . See eeldab ranget dokumentatsiooni (REST OpenAPI-ga, gRPC .proto-failidega jne), selgesõnalist versioonimist, võimaluse korral tagasiühilduvuse säilitamist ja lepingute valideerimise automatiseerimist, et tuvastada vigased muudatused enne nende tootmiskeskkonda jõudmist.
Keskkondades, kus on kümneid või sadu teenuseid, on oluline kaasata vastupidavusmustrid juba projekteerimisetapis, et süsteem oleks osalisteks riketeks valmis . Mustrid, nagu kaitselülitid, uuestikatsed taganemisrežiimiga, täpselt määratletud ajalõpud, vaheseinad ja vasturõhk, aitavad vältida ühe teenuse rikke põhjustatud teiste teenuse riket. Kaose inseneritööriistad, nagu ChaosMonkey või Gremlin, on kasulikud platvormi käitumise praktiliseks testimiseks simuleeritud katkestuste korral.
Paljud keerulised süsteemid ühendavad suhteliselt lihtsaid CRUD-teenuseid keerukamate teenustega, mis käsitlevad arenevaid ärireegleid. Kõik mikroteenused ei vaja keerukat sisemist arhitektuuri : mõned võivad olla lihtsad HTTP-kontrollerid, millel on põhiline andmetele juurdepääs, samas kui teised, näiteks tellimis- või arveldusteenused, saavad kasutada keerukamaid mustreid (DDD, CQRS, domeenisündmused jne).
Tootmisinfrastruktuur: pilv, konteinerid ja Kubernetes/OpenShift
Reaalne kogemus näitab, et mikroteenused toimivad palju paremini pilveinfrastruktuuris konteinerite ja orkestreerimise abil juurutades kui isoleeritud virtuaalmasinates. Platvormid nagu Kubernetes ja OpenShift pakuvad vajalikke primitiivid teenuste konteineritesse pakkimiseks, skaleerimiseks, värskendamiseks, koormuse tasakaalustamiseks ja kõrge käideldavuse haldamiseks.
Tavaliselt on iga mikroteenus pakendatud konteinerikujutisse, mis põhineb ettevõtte baaskujutisel (näiteks OpenJDK 21 Java-teenuste jaoks), mida haldab infrastruktuurimeeskond. Seda baaskujutist hoitakse ajakohasena turvapaikadega ja uue versiooni väljaandmisel vastutavad arendusmeeskonnad oma teenuste ümberehitamise ja juurutamise eest vastavates keskkondades.
Kuberneteses/OpenShiftis on põhiliseks juurutusüksuseks pod, mis kapseldab ühe või mitu konteinerit . Tavaliselt vastab mikroteenus podi tüübile ja juurutatakse ressursside, näiteks juurutuste (olekuta teenuste puhul) või StatefulSet'ide (kui on olemas seotud olek), abil. Alguses määratletakse minimaalne koopiate arv keskkonna kohta, et testimis-, eeltootmis- ja tootmiskeskkondadel oleks nende kriitilisusele vastav kättesaadavuse tase.
Automaatne skaleerimine toimub HorizontalPodAutoscaleri (HPA) abil , mis reguleerib koopiate arvu selliste näitajate põhjal nagu protsessori, mälu või muud kohandatud näitajad. Platvorm peab konfigureerima ka podi afiinsusvastased reeglid, et levitada sama teenuse koopiaid erinevate sõlmede vahel, takistades ühe sõlme rikke korral kõigi eksemplaride sulgemist.
Vertikaalse suuruse osas kasutatakse resources.requests ja resources.limits funktsioone podi tarbitava protsessori ja mälu vahemiku määratlemiseks. Näiteks Java-teenuse jaoks minimaalselt 100 MB protsessorit ja 256 MB mälu reserveerimine ning vastavalt kuni 500 MB ja 2 GB mälu lubamine, JVM-i (Xms, Xmx, Xss) kohandamine konteineri ressursside parimaks kasutamiseks.
Olekuhaldus: olekuteta ja olekuga mikroteenused
Enamik ärimikroteenuseid on loodud olekuta teenustena . See tähendab, et pod ei salvesta teavet, mis peab taaskäivituste üle elama; olek säilitatakse välistes andmebaasides, sõnumijärjekordades või muudes salvestusruumides. See lähenemisviis hõlbustab dünaamilist horisontaalset skaleerimist ja sujuvat juurutamist, kuna iga koopia saab hakkama mis tahes päringuga.
Siiski on stsenaariume, kus pole muud alternatiivi kui püsivate köidete poolt toetatud olekuga mikroteenused . See kehtib mõnede andmebaaside, hajusfailisüsteemide või komponentide kohta, mis vajavad kohalike andmete haldamist. Need podid juurutatakse tavaliselt StatefulSetsidega, lingitakse PersistentVolume'idega PersistentVolumeClaims'i abil ja skaleeritakse vertikaalselt, mitte horisontaalselt.
Kui mikroteenus vajab püsivat salvestusruumi, taotletakse PersistentVolumeClaim (PVC) nõuet koos selle suuruse, juurdepääsurežiimi ja kavandatud kasutusotstarbega ning operatsioonimeeskond varustab selle platvormi poliitikate kohaselt. Sellele PVC-le viidatakse juurutamise manifestis ja see paigaldatakse podile, et teenus saaks andmeid püsivalt lugeda ja kirjutada.
Kuigi olekupõhised mudelid võivad teatud juhtudel olla vajalikud, on üldine soovitus hoida võimalikult palju teenuseid olekuta . See lihtsustab juurutamist, skaleerimist, vastupidavust ja katastroofidejärgset taastamist ning vähendab tegevuse keerukust keskkondades, kus on palju mikroteenuseid.
Andmete detsentraliseerimine ja teenuste suveräänsus
Traditsioonilistes infrastruktuurides on efektiivsuse maksimeerimiseks tavaline andmebaaside ja salvestusruumi tsentraliseerimine. Mikroteenuste puhul on see lähenemisviis vastuolus meeskonna autonoomia ja lahtisidumise põhimõttega . Kui paljudel teenustel on sama relatsiooniskeem, võib iga struktuurimuutus blokeerida mitu meeskonda ja tahtmatult ühilduvust rikkuda.
Seetõttu on soovitatav tava, et igal mikroteenusel oleks oma andmemudel ja andmebaas , kuigi arenduskeskkonnas töötab see andmebaas klastri konteinerina, et lihtsustada juurutamist. Tootmises kasutatakse tavaliselt pilvepõhiseid hallatavaid eksemplare või muid kõrge käideldavusega andmebaasiservereid, säilitades alati selge omandiõiguse piiri.
See ei tähenda, et andmete integratsiooni ei toimuks; see tähendab, et teenuste vahelist järjepidevust hallatakse sündmuste ja asünkroonse sõnumside abil , aktsepteerides lõplikku järjepidevust mõistlikul juhul. Mikroteenuste vahel oleku muutuste levitamiseks on tavaline kasutada sündmussiine (RabbitMQ, Azure Service Bus, Kafka jne), vähendades tugevaid sõltuvusi ühest andmebaasist.
Pilveplatvorm teeb meeskondadele iga teenuse (relatsioon-, dokumendi-, võtme-väärtuse, aegridade jne) jaoks optimaalse andmebaasitüübi valimise lihtsaks , ilma et peaks peale suruma ühte kindlat tehnoloogiat. Peamine on see, et disain arvestab skeemide ja struktuuride migreerimise võimalusega ilma teiste teenustega lepinguid lõhkumata ning et andmeotsused tehakse iga mikroteenuse domeenipiiridega kooskõlas.
Hajutatud juhtimine, meeskonnad ja organisatsioon
Mikroteenustele üleminek ilma organisatsiooni muutmata on tülikas. Klassikaliste funktsionaalsete silosüsteemide (võrgud, süsteemid, andmebaasid, arendus ja operatsioonid) asemel julgustatakse tootemeeskondadel põhinevat struktuuri, mis koondab arenduse, kvaliteedikontrolli, DevOpsi ja vajaduse korral äri- või andmeanalüütikute profiile.
Iga meeskond vastutab ühe või mitme mikroteenuse eest samas funktsionaalses valdkonnas, tegeledes nii arenduse kui ka käitamisega (sina ehitad selle, sina käitad seda) . See tähendab, et meeskond haldab oma CI/CD torustikke, teeb konkreetsete vajaduste rahuldamiseks koostööd infrastruktuuriga ning osaleb jälgimises ja intsidentidele reageerimises. Infrastruktuur ja pilveplatvorm keskenduvad ühiste ja standardiseeritud teenuste pakkumisele.
Selleks, et vältida hajutatud juhtimise langemist anarhiaks, on oluline määratleda kerged standardid ja jagatud kataloogid : heakskiidetud baaskujutised, juurutusmustrid, nimeruumide ja teenuste nimetamise konventsioonid, API juhised, Dockerfile'i ja Kustomize'i mallid jne. Need juhised toimivad "piiretena", mis suunavad meeskondi, takistamata nende otsuste langetamist.
Paljudes ettevõttekeskkondades kasutatakse iga projekti või domeeni jaoks eraldi nimeruume , vähemalt ühte iga keskkonna (arendus, eeltootmine, tootmine) kohta. Suur projekt saab oma mikroteenuseid levitada mitme nimeruumi vahel, eeldusel, et sisemine kommunikatsioon on õigesti konfigureeritud ja turvareegleid järgitakse.
CI/CD, automatiseerimine ja GitOps mudel
Kui arhitektuur koosneb kümnetest või sadadest mikroteenustest, on ainus viis nende töökorras hoidmiseks investeerida ulatuslikult otsast lõpuni automatiseerimisse . See hõlmab järjepidevaid CI/CD torujuhtmeid, deklaratiivseid juurutamismääratlusi, automatiseeritud testimist ja automaatseid tagasipööramismehhanisme.
Tüüpiline pidev integratsiooni ja edastustoru tegeleb koodi kompileerimise, testide käivitamise, kvaliteedi analüüsimisega selliste tööriistadega nagu SonarQube , konteineri kujutise loomisega ettevõtte Dockerfile'ist ja juurutusmanifestide värskendamisega. Sealt edasi rakendab süsteem nagu ArgoCD või sarnane muudatused klastrile GitOpsi lähenemisviisi abil.
Iga mikroteenuste repositoorium sisaldab tavaliselt standardiseeritud Dockerfile'i, konveieri konfiguratsioonifaili (nt ci.json) , kvaliteedianalüüsi omadusi ja juurutamiskataloogi, kus Kubernetes'i definitsioonid (Kustomize või Helm) on eraldatud keskkondade kaupa. Repositooriumi veebikonksud käivitavad konveieri selliste sündmuste korral nagu siltide saatmine või ühendamistaotlused.
GitOpsi muster määrab Giti repositooriumi taristu ja juurutamise tõese allikana . Seal versioonitakse juurutuste, teenuste, konfiguratsioonikaartide, PVC-de, sealedsecretside ja muude ressursside manifeste ning spetsiifilised tööriistad sünkroonivad klastri olekut Gitis määratletuga. See pakub jälgitavust, pull-taotluste ülevaatamist ja lihtsaid tagasipööramisvõimalusi.
Seaded, saladused ja turvalisus
Küpses mikroteenuste platvormis tugineb konfiguratsioonihaldus mittetundlike parameetrite puhul ConfigMapsidele ja konfidentsiaalse teabe puhul Secretsidele . Igal mikroteenusel on tavaliselt oma keskkonnaspetsiifiline ConfigMap, mis salvestab omadusi, nagu sõltuvate teenuste URL-id, funktsionaalsuse märgid ja häälestamisparameetrid.
Saladusi (volitusi, võtmeid, märke, sertifikaate) käideldakse rangete turvapoliitikate alusel . Vähem kriitilistes keskkondades võib olla vastuvõetav hoida neid arendusmeeskonna hallatavas lihttekstina, kuid eeltootmise ja tootmiskeskkondades on soovitatav need krüpteerida selliste tööriistade abil nagu Sealed Secrets või spetsiaalsed pilvepõhised välised haldurid.
Kui saladust on vaja jagada mitme teenuse vahel (näiteks OTEL Collectori identimisandmed või ühine võtmehoidla ), saab selle koondada nimeruumipõhisesse konfiguratsioonihoidlasse. Nimeruumi jagavad projektid koordineerivad selle vajadusel värskendamist, säilitades kontrolli selle üle, kes saab neid ressursse lugeda või muuta.
Sideturvalisuse osas on domineerivaks mustriks nullusaldus : midagi ei peeta enesestmõistetavaks ainuüksi seetõttu, et liiklus on "sisemine". Kõik teenustevahelised kõned, nii sisemised kui ka välised, peavad olema autentitud ja autoriseeritud, ideaaljuhul mTLS-i, JWT-tokenite või muude samaväärsete mehhanismide abil. Mikroteenused ei delegeeri turvalisust pimesi API-haldurile ega võrgule; nad teevad ka oma kontrolle.
Mikroteenuste, API-de ja sõnumside vaheline suhtlus
Küpses mikroteenuste arhitektuuris on kommunikatsioonikiht jagatud mitmeks juhtumiks. Klientidelt (brauserid, mobiilirakendused, kolmandad osapooled) taustsüsteemi suunduva liikluse jaoks kasutatakse API-halduri hallatavaid avaldatud API-sid . Need API-d on tavaliselt RESTful (sageli OpenAPI-d kasutades) või mõnel juhul gRPC, mis on avaldatud lüüsi kaudu.
Samas nimeruumis või isegi sama projekti mitmes nimeruumis asuvate mikroteenuste vahelised kõned hallatakse tavaliselt sisemiste Kubernetes'i teenuste abil, millel on sisemine DNS . Need kõned mööduvad avalikust API haldurist, kuid järgivad turva-, autentimis- ja autoriseerimispoliitikaid. Selliste stsenaariumide puhul saab kasutada teenusevõrku või sisemisi väravaid, mis jõustavad ühiseid poliitikaid.
Kui mikroteenused kuuluvad erinevatesse funktsionaalsetesse domeenidesse või projektidesse , peetakse suhtlust organisatsiooni tasandil avalikuks. Sellistel juhtudel on tavaline kasutada API-haldurit või koostalitlusvõime siini, kus hallatakse lepinguid, kvoote, turvalisust, versioonimist ja auditeerimist, takistades otsest ühendamist sõltumatute klastrite või nimeruumide vahel.
Mis puutub integratsiooni pärand- või välissüsteemidega, mis ei pruugi alati kaasaegseid API-sid pakkuda, siis on tavaline toetuda konkreetsetele konnektoritele koostalitlusvõime siini kaudu . Sel viisil räägivad mikroteenused ühist keelt (näiteks sündmused või sisemised REST API-d) ja konnektor tegeleb tõlkega pärandsüsteemi ja sealt tagasi, alati täiustatud turvalisusega.
Lisaks sünkroonsele suhtlusele mängib võtmerolli ka asünkroonne sõnumivahetus . Seda kasutatakse protsesside lahtisidumiseks, pingetõusude leevendamiseks, ärisündmuste levitamiseks teenuste vahel ja vastupidavuse parandamiseks. Igal sündmusel on tavaliselt täpselt määratletud ja versioonitud skeem koos jälgimismehhanismidega, et vältida tootjate ja tarbijate vahelisi katkestusi nende arenedes.
Jälgitavus, OTEL-i koguja ja toimimine
Paljudest mikroteenustest koosnevas süsteemis on probleemi diagnoosimine ilma hea jälgitavuseta peaaegu võimatu. Seetõttu on mõõdikud, tsentraliseeritud logimine ja hajutatud jäljed integreeritud juba projekteerimisetapis , võimaldades mõista, mis toimub nii teenuse kui ka platvormi tasandil.
Selle skeemi keskne komponent on OpenTelemetry Collector (OTEL Collector) , mis juurutatakse nimeruumis või tsentraalselt, et koguda mõõdikuid, logisid ja jälgi kõigilt komponentidelt. Mikroteenused peavad teadma ainult seda, et nad peaksid saatma oma telemeetria Collectorile; Collector edastab selle seejärel jälgimissüsteemidele (Prometheus, Grafana, Jaeger, Elastic jne) ilma, et teenus peaks üksikasju teadma.
Taristukihi puhul kasutatakse sõlme tasemel kogujaid ja eksportijaid, et koguda podidest protsessori, mälu, ketta, võrgu ja logi mõõdikuid ning saata need vastavalt Prometheusele ja Elasticsearchile. Tööriistu nagu Grafana ja Kibana kasutatakse selle teabe visualiseerimiseks, armatuurlaudade loomiseks ning nutikate läviväärtuste ja seotud käitusraamatutega teadete määratlemiseks.
Kui projekt vajab oma mõõdikute või jälgede väga spetsiifilist töötlemist, saab ta oma nimeruumis juurutada oma OTEL Collectori eksemplari, eeldusel, et sellel on toimimise heakskiit ja tootmise hooldusmudel on selge.
Testimisstrateegia, lepingud ja kohaliku arenduse kogemus
Hajutatud mikroteenuste arhitektuuri testimine nõuab keerukamat testimisstrateegiat kui monoliidi testimine. Ühiktestid on endiselt olulised, kuid lepingutestid (API-de ja sündmuste jaoks), teenustevahelised integratsioonitestid ja otsast lõpuni testid, mis läbivad terveid vooge, on üha olulisemad.
Ühilduvusprobleemide vältimiseks kasutatakse selliseid tehnikaid nagu tarbijakeskne lepingute testimine , kus kliendid määratlevad API ootused ja teenusepakkujad täidavad neid. Iga lepingumuudatus läbib konfiguratsiooniinterneti (CI) torujuhtmetes automaatse testimise, mis hoiab ära juurutamise, mis rikuvad teadaolevate tarbijate funktsioone.
Kui teenuste arv kasvab üle saja, muutub kogu süsteemi lokaalne replikeerimine ebapraktiliseks. Seetõttu tugineb arendus sõltuvate teenuste simulatsioonidele või tunneldamisele kaugkeskkondadesse . Arendajad käivitavad tavaliselt ainult osa mikroteenustest ja asendavad ülejäänud võltsingute, võltsingute või simulaatoritega või suunavad teatud kõned jagatud integratsioonikeskkonda.
Lõpptestimine tugineb üha enam ajutistele keskkondadele või funktsiooniharudest loodud "eelvaadetele" , mis loovad isoleeritud keskkonna selle funktsionaalsusega seotud teenustega. See minimeerib meeskondadevahelist hõõrdumist, vähendab "see töötab minu masinas" efekti ja tuvastab integratsiooniprobleemid enne kallimate keskkondade, näiteks eeltootmise, kasutamist.
Mikroteenuste juurutamise mustrid tootmises
Lisaks Kubernetesele on tootmises mitmeid mikroteenuste juurutamise mustreid, mida tasub teada, kuna need käsitlevad erinevaid isolatsiooni, kulu ja küpsuse stsenaariume . Üks vanimaid mustreid on mitu teenuse eksemplari hosti kohta, kus üks füüsiline või virtuaalne host käitab mitut erinevate teenuste eksemplari, tavaliselt jagatud rakendusserveris.
VM-i teenuse eksemplari mustris on iga teenus pakendatud VM-i kujutisena (näiteks EC2 AMI) ja töötab omaette eksemplaril. See pakub tugevat isolatsiooni suurema ressursitarbimise ja aeglasema käivitusaja hinnaga. Tööriistad nagu Packer või pilveteenuse pakkuja spetsiifilised lahendused muudavad tootmisvalmis VM-i kujutiste loomise lihtsaks.
Tänapäeval on kõige levinum muster teenuse eksemplar konteineri kohta , kus iga mikroteenus luuakse konteineri kujutisena ja juurutatakse orkestraatorisse (Kubernetes, OpenShift jne). Konteinerid on virtuaalmasinatest kergemad, käivituvad väga kiiresti ja võimaldavad pakendada kõike teenuse jaoks vajalikku, lihtsustades juurutamist ja võimaldades automaatset skaleerimist.
Lõpuks on populaarsust kogunud serverita lähenemisviisid, näiteks AWS Lambda . Need paketid sisaldavad funktsioone, mis vastavad HTTP-päringutele või sündmustele teistelt teenustelt (S3, DynamoDB, järjekorrad jne), kusjuures kasutajad maksavad ainult selle eest, mida nad kasutavad. See muster sobib eriti hästi väga väikeste mikroteenuste või lühiajaliste sündmustepõhiste ülesannete jaoks, kuigi see toob kaasa täiendavaid kaalutlusi jälgitavuse, külmkäivituste ja täitmispiirangute kohta.
Praktikas on paljudel organisatsioonidel hübriidne ökosüsteem: süsteemi põhiosa töötab konteineritel ja orkestraatoritel, samas kui teatud abikomponendid on rakendatud serverita funktsioonidena või spetsiaalsete virtuaalmasinatena, millel on alati selged liidesed ja täpselt määratletud protokollid nende tervikusse integreerimiseks.
Kõige selle tootmiskeskkonda viimisel ei ole oluline mitte ainult valitud tehnoloogia, vaid ka arhitektuur, mis talub vigu, skaleerub vastavalt vajadusele, juurutub automaatselt ja on jälgitav . Tootega kooskõlastatud meeskondade, hästi hallatud lepingute, detsentraliseeritud andmete ja tugeva pilveplatvormi abil muutuvad mikroteenused lubadusest tõhusaks ja jätkusuutlikuks viisiks keerukate rakenduste arendamiseks aastateks.