Mikroteenuste rakendamine tootmiskeskkondades

Informatec Digital » Ressursid » Mikroteenuste rakendamine tootmiskeskkondades

Mikroteenuste arhitektuuri kasutuselevõtt reaalses keskkonnas ei seisne ainult monoliidi jagamises väiksemateks tükkideks: see hõlmab ümber mõelda infrastruktuur, seadmed, protsessid, andmed, turvalisus ja toimingudKui süsteem liigub teooriast tootmisklastrisse, tekivad probleemid teenuste avastamise, meeskondade vaheliste lepingute, CI/CD, jälgitavuse, vastupidavuse ja skaleeritavusega, mis nõuetekohase lahendamata jätmise korral muudavad mikroteenused hajutatud kaoseks.

Hea uudis on see, et tänapäeval on meil palju kogemusi sellistelt organisatsioonidelt nagu Netflix, Amazon, Google või suurkorporatsioonid, mis tegutsevad Sadu mikroteenuseid tootmisesNende õppetundide ja Kubernetesi ning OpenShifti ettevõtluskeskkondade parimate tavade põhjal saab välja töötada väga kindla 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äikesed, autonoomsed ja multifunktsionaalsed meeskonnad mis 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 sõltumatu skaleerimine teenuse kohtaSa ei pea kogu rakendust üle mastaapima, kui ainult kataloog, kassa või avalik API kogeb liikluse järsku suurenemist. Saad iga mikroteenust horisontaalselt või vertikaalselt skaleerida vastavalt selle koormusmustrile, täpselt mõõta iga funktsiooni maksumust ja säilitada kättesaadavuse isegi siis, kui konkreetses piirkonnas tarbimine järsult suureneb.

Nende teenuste pakendamise ja juurutamise viis hõlbustab pidev rakendamine madala riskigaKui iga mikroteenus avaldatakse eraldi, on uute ideede testimine ja problemaatiliste versioonide tagasipööramine palju lihtsam: juhuslikud juurutused, sinised/rohelised juurutused ja automaatsed tagasipööramised vähendavad vigade maksumust ja jätavad ruumi katsetamiseks.

Tehnoloogilisest vaatenurgast edendavad mikroteenused vabadus valida keeli, raamistikke ja andmebaase teenuse kohta. 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 iga juhtumi jaoks kasutada õiget tööriista, ilma et kogu rakendust globaalsesse tehnoloogiamuutusse lohistaksite.

Lisaks hõlbustab selle jagamine väikesteks, täpselt määratletud osadeks funktsionaalsuste taaskasutamine ehitusplokkidenaAlgselt funktsiooni osana loodud mikroteenust saab hiljem uuesti kasutada 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 oli algusest peale sisse ehitatud.

Arhitektuuriline ja teenuste disain

Selleks, et mikroteenused tootmises hästi töötaksid, tuleb alustada a-st teenuste piiride ja vastutuse hoolikas kavandaminePraktikas 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 plokkidest, peate neid viimistlema, kuni saavutate peeneteralised mikroteenused, mis töötavad sidusa andmestiku kallalNeil peaks olema oma mudel ja nad peaksid täpselt teadma, mida nad peavad teistesse teenustesse lugema või kirjutama. Seda protsessi toetavad tavaliselt domeenipõhise disaini (DDD) kontseptsioonid ja piiratud kontekstid, mis takistavad mikroteenuse muutumist "minimonoliidiks".

Neid teenuseid pakkuvatel API-del peab olema täpselt määratletud ja stabiilsed lepingudSee hõlmab 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 disainifaasist alates, et süsteem ole valmis osalisteks ebaõnnestumisteksMustrid nagu kaitselülitid, uuestikatsed tagasilöögiga, täpselt määratletud ajalõpud, vaheseinad ja vasturõhk aitavad vältida ühe teenuse rikke mõju teistele. Chaos Engineering tööriistu, nagu Chaos Monkey või Gremlin, kasutatakse platvormi käitumise praktiliseks testimiseks simuleeritud katkestuste korral.

Paljudes keerukates süsteemides eksisteerivad suhteliselt lihtsad CRUD-teenused koos keerukamate teenustega, mis keskenduvad muutuvatele ärireeglitele. Kõik mikroteenused ei vaja keerukat sisemist arhitektuuriMõned võivad olla lihtsad HTTP-kontrollerid, millel on põhiline andmetele juurdepääs, samas kui teised, näiteks tellimis- või arveldusteenus, võivad ära kasutada keerukamaid mustreid (DDD, CQRS, domeenisündmused jne).

Tootmisinfrastruktuur: pilv, konteinerid ja Kubernetes/OpenShift

Reaalse maailma kogemus näitab, et mikroteenused sobivad palju paremini, kui neid juurutada pilveinfrastruktuur konteinerite ja orkestreerimisega kui isoleeritud virtuaalmasinatel. Platvormid nagu Kubernetes ja OpenShift pakuvad vajalikke primitiivid teenuste konteineritesse pakkimiseks, skaleerimiseks, uuendamiseks, koormuse tasakaalustamiseks ja kõrge käideldavuse haldamiseks.

Tavaliselt on iga mikroteenus pakendamine konteineri pildil, mis põhineb ettevõtte baaspildil (näiteks OpenJDK 21 Java teenuste jaoks), mida haldab infrastruktuuri meeskond. Seda baaskujutist hoitakse ajakohasena turvapaikadega ja uue versiooni väljaandmisel vastutavad arendusmeeskonnad oma teenuste vastavates keskkondades ümberehitamise ja juurutamise eest.

Kuberneteses/OpenShiftis on peamine juurutusüksus kapsel, mis kapseldab ühte või mitut konteineritTavaliselt vastab mikroteenus teatud tüüpi pod'ile ja selle juurutamiseks kasutatakse ressursse, näiteks juurutusi (olekuta teenuste puhul) või olekukomplekte (kui on olemas seotud olek). Alguses määratletakse keskkonna kohta minimaalne koopiate arv, et testimis-, eeltootmis- ja tootmiskeskkondadel oleks nende kriitilisusele vastav kättesaadavuse tase.

Automaatne skaleerimine on rakendatud koos Horisontaalne Pod Autoscaler (HPA)See reguleerib koopiate arvu selliste näitajate põhjal nagu protsessori, mälu või muud kohandatud näitajad. Platvorm peab konfigureerima ka pod-i afiinsusvastased reeglid nii, et sama teenuse koopiad oleksid jaotatud erinevate sõlmede vahel, vältides sõlme rikke korral kõigi eksemplaride sulgemist.

Vertikaalse mõõtme osas mängib see ressursid.taotlused ja ressursid.limiidid Protsessori ja mälu vahemiku määratlemiseks, mida pod saab tarbida. Näiteks Java-teenuses minimaalselt 100 MB protsessori ja 256 MB mälu reserveerimine ning vastavalt kuni 500 MB ja 2 Gi lubamine, JVM-i (Xms, Xmx, Xss) kohandamine konteineri ressursside parimaks kasutamiseks.

Olekuhaldus: olekuteta ja olekuga mikroteenused

Enamik ärimikroteenuseid on loodud järgmiselt: kodakondsuseta teenusedSee tähendab, et pod ei salvesta teavet, mis peab taaskäivituste ajal ellu jääma; 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 olukordi, kus pole muud valikut kui omada püsivate mahtude toetatud olekupõhised mikroteenusedSee kehtib mõnede andmebaaside, hajusfailisüsteemide või komponentide kohta, mis vajavad kohalike andmete haldamist. Need podid juurutatakse tavaliselt StatefulSets-idega, lingitakse PersistentVolumes-iga PersistentVolumeClaims-i abil ja skaleeritakse vertikaalselt, mitte horisontaalselt.

Kui mikroteenus vajab püsivat salvestusruumi, siis PersistentVolumeClaim (PVC) koos suuruse, juurdepääsuviisi ja kavandatud kasutusotstarbegaOperatsioonide meeskond vastutab selle ettevalmistamise eest vastavalt platvormi poliitikatele. Sellele PVC-le viidatakse juurutamise manifestis ja see paigaldatakse podile, et teenus saaks andmeid püsivalt lugeda ja kirjutada.

Kuigi olekupõhine mudel võib olla vajalik teatud juhtudel, on üldine soovitus proovida teha võimalikult palju teenuseid jääb kodakondsusetaSee 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 tavaline, et andmebaasid ja salvestusruum tsentraliseeritakse efektiivsuse maksimeerimiseks. Mikroteenuste puhul on see lähenemisviis erinev. See on vastuolus meeskonna autonoomia ja lahtisidumise põhimõtetega.Kui paljudel teenustel on sama relatsiooniskeem, võib iga struktuurimuutus blokeerida mitu meeskonda ja tahtmatult ühilduvust rikkuda.

Seetõttu on soovitatav tava, et iga mikroteenus oleks oma andmemudeli ja andmebaasi omanikKuigi arenduskeskkonnas võib see andmebaas juurutamise lihtsustamiseks klastris konteinerina töötada, kasutatakse tootmises tavaliselt pilvepõhiseid instansse või muid kõrge käideldavusega andmebaasiservereid, säilitades alati selge omandiõiguse piiri.

See ei tähenda, et andmete vahel puudub integratsioon: see tähendab, et Teenuste vahelist järjepidevust hallatakse sündmuste ja asünkroonse sõnumside abil.Mõistlikul juhul lõpliku järjepidevuse aktsepteerimine. Mikroteenuste vahelise oleku muutuste levitamiseks on tavaline kasutada sündmussiine (RabbitMQ, Azure Service Bus, Kafka jne), vähendades tugevaid sõltuvusi ühest andmebaasist.

Pilveplatvorm teeb meeskondadel valiku tegemise lihtsamaks iga teenuse jaoks optimaalne andmebaasi tüüp (relatsiooniline, dokumendipõhine, võtme-väärtuse, aegridade jne), ilma et kehtestataks ühte kindlat tehnoloogiat. Oluline on see, et disain arvestaks skeemide ja struktuuride migreerimise võimalusega ilma teiste teenustega lepinguid lõhkumata ning et andmeotsused tehtaks iga mikroteenuse domeenipiiridega kooskõlas.

Hajutatud juhtimine, meeskonnad ja organisatsioon

Mikroteenustele üleminek ilma organisatsiooni muutmata on tülikas. Klassikalise asemel Funktsionaalsed silod võrkude, süsteemide, andmebaaside, arenduse ja toimingute jaoksSoovitatakse tootemeeskondadel põhinevat struktuuri, mis koondab arendus-, kvaliteedikontrolli- ja DevOps-profiile ning vajaduse korral äri- või andmeanalüütikuid.

Iga meeskond vastutab ühe või mitme mikroteenuse eest samas funktsionaalses valdkonnas ja eeldab mõlemat arendus kui toiming (sina ehitad selle üles, sina juhid seda)See tähendab, et meeskond haldab oma CI/CD torustikke, teeb konkreetsete vajaduste rahuldamiseks koostööd infrastruktuuriga ning osaleb intsidentide jälgimises ja neile reageerimises. Infrastruktuuri ja pilveplatvormi valdkonnad keskenduvad ühiste ja standardiseeritud teenuste pakkumisele.

Selleks, et hajutatud valitsemine ei viiks anarhiani, on oluline määratleda kerged standardid ja jagatud kataloogidHeakskiidetud baaskujutised, juurutusmustrid, nimeruumide ja teenuste nimetamise konventsioonid, API juhised, Dockerfile'i ja Kustomize'i mallid jne. Need juhised toimivad meeskondade juhendamisel nn piiretena, takistamata nende otsustusvõimet.

Paljud ärikeskkonnad kasutavad projekti või domeeni järgi eraldatud nimeruumidvähemalt üks iga keskkonna kohta (arendus, eeltootmine, tootmine). 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 arhitektuuril on kümneid või sadu mikroteenuseid, on ainus viis nende töökorras hoidmiseks investeerida neisse ulatuslikult. otsast lõpuni automatiseerimineSee hõlmab järjepidevaid CI/CD torujuhtmeid, deklaratiivset juurutamise määratlust, automatiseeritud testimist ja automaatseid tagasipööramismehhanisme.

Tüüpiline pideva integratsiooni ja pideva edastuskanali haldab koostada koodi, käivitada teste, analüüsida kvaliteeti selliste tööriistadega nagu SonarQubeLooge konteineri kujutis ettevõtte Dockerfile'ist ja värskendage juurutamise manifeste. Sealt edasi rakendab süsteem nagu ArgoCD või sarnane muudatused klastrile GitOpsi lähenemisviisi järgides.

Iga mikroteenuste repositoorium sisaldab tavaliselt standardiseeritud Dockerfile, torujuhtme konfiguratsioonifail (nt ci.json)Kvaliteedianalüüsi atribuudid ja juurutamiskataloog Kubernetes'i definitsioonidega (Kustomize või Helm), mis on eraldatud keskkondade kaupa. Repositooriumi veebikonksud käivitavad torujuhtme selliste sündmuste korral nagu siltide saatmine või ühendamistaotlused.

GitOpsi muster väidab, et Taristu ja juurutamise tõe allikas on Giti repositooriumSeal versioonitakse juurutuste, teenuste, konfiguratsioonikaartide, PVC-de, sealedsecretside ja muude ressursside manifeste ning klastri oleku sünkroniseerimiseks Gitis määratletuga on olemas spetsiaalsed tööriistad. See pakub jälgitavust, pull-taotluste ülevaatamist ja lihtsaid tagasipööramisvõimalusi.

Seaded, saladused ja turvalisus

Küpses mikroteenuste platvormis tugineb konfiguratsioonihaldus järgmisele: ConfigMaps mittetundlike parameetrite jaoks ja Secrets konfidentsiaalse teabe jaoksIgal mikroteenusel on tavaliselt oma ConfigMap keskkonna kohta, mis salvestab omadusi, näiteks sõltuvate teenuste URL-e, funktsionaalsuse lippe või häälestamisparameetreid.

Saladusi (volitusi, võtmeid, märke, sertifikaate) käsitletakse koos ranged turvapoliitikadVähem kriitilistes keskkondades võib olla vastuvõetav hoida neid arendusmeeskonna hallatavas lihttekstis, kuid eeltootmises ja tootmises on soovitatav need krüpteerida selliste tööriistade abil nagu Sealed Secrets või spetsiaalsed välised pilvehaldurid.

Kui saladust on vaja jagada mitme teenuse vahel (näiteks OTEL Collectori volikirjad või ühine võtmehoidlaSelle saab tsentraliseerida nimeruumi konfiguratsioonihoidlasse. Projektid, mis seda nimeruumi jagavad, koordineerivad selle vajadusel värskendamist, säilitades kontrolli selle üle, kes saab neid ressursse lugeda või muuta.

Sideturvalisuse valdkonnas on domineeriv muster Null usaldusMiski ei ole iseenesestmõistetav ainuüksi seetõttu, et liiklus on "sisemine". Kõik teenustevahelised kõned, nii sisemised kui ka välised, peavad olema autentitud ja autoriseeritud, ideaalis 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 järgmist: API-d avaldatakse ja hallatakse API halduri kauduNeed API-d on tavaliselt REST-liidesed (sageli OpenAPI abil) või mõnel juhul gRPC-liidesed, mis on avatud lüüsi kaudu.

Samas nimeruumis või isegi sama projekti mitmes nimeruumis asuvate mikroteenuste vahelisi kõnesid haldab tavaliselt Sisemised Kubernetes teenused sisemise DNS-igaNeed ei läbi avalikku API haldurit, kuid järgivad siiski turva-, autentimis- ja autoriseerimispoliitikaid. Sellistel juhtudel saab kasutada teenusevõrku või sisemisi lüüsi, mis jõustavad ühiseid poliitikaid.

Kui mikroteenused kuuluvad erinevad funktsionaalsed valdkonnad või erinevad projektidOrganisatsiooni tasandil peetakse suhtlust avalikuks. Sellistel juhtudel on tavaline, et see toimub API-halduri või koostalitlusvõime siini kaudu, kus kontrollitakse lepinguid, kvoote, turvalisust, versioonimist ja auditeerimist, vältides otsest ühendamist sõltumatute klastrite või nimeruumide vahel.

Mis puutub integratsiooni pärand- või väliste süsteemidega, mis ei pruugi alati kaasaegseid API-sid pakkuda, siis on tavaline loota koostalitlusvõime siinil olevad spetsiifilised pistikudSel viisil räägivad mikroteenused ühist keelt (näiteks sündmused või sisemised REST API-d) ja konnektor vastutab pärandsüsteemi tõlkimise eest, alati tugevdatud turvalisusega.

Lisaks sünkroonsele kommunikatsioonile ka Asünkroonsel sõnumivahetusel on võtmerollSeda kasutatakse protsesside lahtisidumiseks, tippude neeldumiseks, ä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 integreeritakse need juba projekteerimisetapis. mõõdikud, tsentraliseeritud logimine ja hajutatud jäljed, mis võimaldavad meil mõista, mis teenuse ja platvormi tasandil toimub.

Selle skeemi keskne element on OpenTelemetry koguja (OTEL koguja)See juurutatakse nimeruumis või tsentraalselt, et koguda mõõdikuid, logisid ja jälgi kõigilt komponentidelt. Mikroteenused peavad teadma ainult seda, et nad peavad saatma oma telemeetria kogujale; koguja edastab selle seejärel jälgimissüsteemidele (Prometheus, Grafana, Jaeger, Elastic jne) ilma, et teenus peaks üksikasju teadma.

Taristuplaani jaoks kasutatakse järgmist sõlme tasemel kogujad ja eksportijad Need süsteemid koguvad podidest protsessori, mälu, ketta, võrgu ja logi mõõdikuid ning saadavad 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 a keerukam testimisstrateegia kui monoliitis. Ühiktestid on endiselt põhilised, kuid lepingutestid (API-de ja sündmuste jaoks), teenustevahelised integratsioonitestid ja otsast lõpuni testid, mis läbivad terveid vooge, on üha olulisemad.

Ühilduvust rikkuvate muudatuste vältimiseks kasutatakse selliseid tehnikaid nagu tarbijakeskne lepingute testiminekus kliendid määratlevad API ootused ja teenusepakkujad täidavad neid. Iga lepingumuudatus läbib automatiseeritud testid, mis töötavad CI-torujuhtmetes, vältides juurutusi, mis võivad rikki minna mis tahes teadaoleva tarbija jaoks.

Kui teenuste arv kasvab üle saja, muutub kogu süsteemi lokaalne replikeerimine ebapraktiliseks. Seetõttu tugineb arenduskogemus sõltuvate teenuste simulatsioonid või tunneldamine kaugkeskkondadesseTavaliselt juurutavad arendajad ainult alamhulka mikroteenuseid ja varjavad ülejäänu võltsingute, võltsingute või simulaatoritega või suunavad teatud kõned jagatud integratsioonikeskkonda.

Lõpp-otsa testimine tugineb üha enam ajutised keskkonnad või funktsiooniharudest loodud „eelvaated”Need tööriistad loovad isoleeritud keskkonna koos selle funktsionaalsusega seotud teenustega. See minimeerib meeskondadevahelist hõõrdumist, vähendab "see töötab minu masinal" efekti ja tuvastab integratsiooniprobleemid enne, kui need jõuavad kallimatesse keskkondadesse, näiteks eeltootmisse.

Mikroteenuste juurutamise mustrid tootmises

Lisaks Kubernetesele on tootmises mitmeid mikroteenuste juurutamise mustreid, mida tasub teada, kuna need käsitlevad erinevad isolatsiooni, maksumuse ja küpsuse stsenaariumidÜks vanimaid mustreid on mitme teenuse eksemplari kasutamine hosti kohta, kus sama füüsiline või virtuaalne host käitab mitut erinevate teenuste eksemplari, tavaliselt jagatud rakendusserveris.

Mustri järgi teenuse eksemplar virtuaalmasina kohtaIga teenus on pakendatud virtuaalmasina kujutisena (nt EC2 AMI) ja töötab omaette eksemplaris. See tagab tugeva isolatsiooni suurema ressursitarbimise ja aeglasema käivitusaja hinnaga. Tööriistad nagu Packer või pilveteenuse pakkuja spetsiifilised lahendused muudavad tootmisvalmis virtuaalmasina kujutiste loomise lihtsaks.

Tänapäeval on kõige levinum muster selline, teenuse eksemplar konteineri kohtakus iga mikroteenus luuakse konteineri kujutisena ja juurutatakse orkestraatorisse (Kubernetes, OpenShift jne). Konteinerid on virtuaalmasinatest kergemad, käivituvad väga kiiresti ja võimaldavad teil pakendada kõike teenuse jaoks vajalikku, lihtsustades juurutamist ja automaatset skaleerimist.

Lõpuks on lähenemisviisid populaarsust kogunud serverita, nagu AWS LambdaSee muster hõlmab pakkimisfunktsioone, 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 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übriidökosüsteem: süsteemi põhiosa töötab konteinerites ja orkestraatorites, samas kui teatud abikomponendid on rakendatud serverita funktsioonidena või spetsiaalsete virtuaalmasinatena, alati koos selged liidesed ja täpselt määratletud protokollid et need tervikusse integreerida.

Kõige selle tootmisse viimisel ei ole oluline mitte ainult valitud tehnoloogia, vaid ka sellise arhitektuuri loomine, mis See on veataluv, skaleerub vastavalt vajadusele, juurub 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.