Python-mikropalvelut: Syväsukellus Service Mesh -toteutukseen

Ohjelmistokehityksen maisema on muuttunut perusteellisesti kohti mikropalveluarkkitehtuuria. Monoliittisten sovellusten pilkkominen pienempiin, itsenäisesti käyttöönotettaviin palveluihin tarjoaa vertaansa vailla olevan ketteryyden, skaalautuvuuden ja joustavuuden. Python, jossa on selkeä syntaksi ja tehokkaat kehykset, kuten FastAPI ja Flask, on tullut ensisijaiseksi valinnaksi näiden palveluiden rakentamiseen. Tämä hajautettu maailma ei kuitenkaan ole vailla haasteita. Palveluiden määrän kasvaessa kasvaa myös niiden vuorovaikutusten hallinnan monimutkaisuus. Tässä kohtaa service mesh astuu kuvaan.

Tämä kattava opas on tarkoitettu globaalille ohjelmistoinsinöörien, DevOps-ammattilaisten ja Pythonin kanssa työskentelevien arkkitehtien yleisölle. Tutkimme, miksi service mesh ei ole vain "mukava lisä", vaan olennainen osa mikropalveluiden suorittamista mittakaavassa. Selvitämme, mikä service mesh on, miten se ratkaisee kriittisiä operatiivisia haasteita, ja tarjoamme käytännöllisen katsauksen sen toteuttamiseen Python-pohjaisessa mikropalveluympäristössä.

Mitä Python-mikropalvelut ovat? Nopea kertaaus

Ennen kuin sukellamme mesh-verkkoon, luodaan yhteinen pohja. Mikropalveluarkkitehtuuri on lähestymistapa, jossa yksi sovellus koostuu monista löyhästi kytketyistä ja itsenäisesti käyttöönotettavista pienemmistä palveluista. Jokainen palvelu on itsenäinen, vastuussa tietystä liiketoimintaominaisuudesta ja kommunikoi muiden palveluiden kanssa verkon kautta, tyypillisesti API:en (kuten REST tai gRPC) kautta.

Python sopii erinomaisesti tähän paradigmaan, koska:

• Kehityksen yksinkertaisuus ja nopeus: Pythonin luettava syntaksi mahdollistaa tiimien rakentamisen ja palveluiden iteroinnin nopeasti.
• Rikas ekosysteemi: Laaja kokoelma kirjastoja ja kehyksiä kaikkeen verkkopalvelimista (FastAPI, Flask) datatieteeseen (Pandas, Scikit-learn).
• Suorituskyky: Nykyaikaiset asynkroniset kehykset, kuten FastAPI, joka on rakennettu Starlettelle ja Pydanticille, tarjoavat suorituskyvyn, joka on verrattavissa NodeJS:ään ja Go:hon I/O-sidotuissa tehtävissä, jotka ovat yleisiä mikropalveluissa.

Kuvittele globaali verkkokauppa-alusta. Sen sijaan, että kyseessä olisi yksi massiivinen sovellus, se voisi koostua mikropalveluista, kuten:

• Käyttäjäpalvelu: Hallinnoi käyttäjätilejä ja todennusta.
• Tuotepalvelu: Käsittelee tuoteluetteloa ja varastoa.
• Tilauspalvelu: Käsittelee uusia tilauksia ja maksuja.
• Toimituspalvelu: Laskee toimituskulut ja järjestää toimituksen.

Tilauspalvelun, joka on kirjoitettu Pythonilla, on kommunikoitava käyttäjäpalvelun kanssa asiakkaan vahvistamiseksi ja tuotepalvelun kanssa varaston tarkistamiseksi. Tämä viestintä tapahtuu verkon kautta. Kerro tämä nyt kymmenillä tai sadoilla palveluilla, ja monimutkaisuus alkaa nousta pintaan.

Hajautetun arkkitehtuurin luontaiset haasteet

Kun sovelluksesi komponentit kommunikoivat verkon kautta, perit kaikki verkon luontaiset epäluotettavuudet. Monoliitin yksinkertaisesta funktiokutsusta tulee monimutkainen verkkopyyntö, joka on täynnä mahdollisia ongelmia. Näitä kutsutaan usein "Päivä 2" -toimintaongelmiksi, koska ne tulevat ilmeisiksi alkuperäisen käyttöönoton jälkeen.

Verkon epäluotettavuus

Mitä tapahtuu, jos tuotepalvelu vastaa hitaasti tai on tilapäisesti käytettävissä, kun tilauspalvelu kutsuu sitä? Pyyntö saattaa epäonnistua. Sovelluskoodin on nyt käsiteltävä tämä. Pitäisikö sen yrittää uudelleen? Kuinka monta kertaa? Millä viiveellä (eksponentiaalinen backoff)? Entä jos tuotepalvelu on kokonaan alhaalla? Pitäisikö meidän lopettaa pyyntöjen lähettäminen joksikin aikaa, jotta se voi palautua? Tämä logiikka, mukaan lukien uudelleenyritykset, aikakatkaisut ja katkaisijat, on toteutettava jokaisessa palvelussa, jokaiselle verkkokutsulle. Tämä on redundanttia, virhealtista ja sotkee Python-liiketoimintalogiikkaasi.

Observabiliteetin tyhjiö

Monoliitissa suorituskyvyn ymmärtäminen on suhteellisen yksinkertaista. Mikropalveluympäristössä yksi käyttäjäpyyntö saattaa kulkea viiden, kymmenen tai jopa useamman palvelun läpi. Jos tämä pyyntö on hidas, missä on pullonkaula? Tämän selvittäminen edellyttää yhtenäistä lähestymistapaa:

• Metriikat: Jatkuvasti metriikoiden, kuten pyyntöviiveen, virheprosenttien ja liikennemäärän (ns. "Kultaiset signaalit"), kerääminen jokaisesta palvelusta.
• Kirjaus: Lokien yhdistäminen sadoista palveluesiintymistä ja niiden korrelointi tiettyyn pyyntöön.
• Hajautettu jäljitys: Yhden pyynnön matkan seuraaminen kaikkien sen koskettamien palveluiden läpi koko puhelugraafin visualisoimiseksi ja viiveiden paikantamiseksi.

Tämän manuaalinen toteuttaminen tarkoittaa laajojen instrumentointi- ja valvontakirjastojen lisäämistä jokaiseen Python-palveluun, mikä voi ajautua epäjohdonmukaisuuteen ja lisätä ylläpitokustannuksia.

Turvallisuuden labyrintti

Miten varmistat, että tilauspalvelusi ja käyttäjäpalvelusi välinen viestintä on turvallista ja salattua? Miten takaat, että vain tilauspalvelulla on oikeus käyttää tuotepalvelun arkaluontoisia varastopäätepisteitä? Perinteisessä asennuksessa saatat luottaa verkkotason sääntöihin (palomuurit) tai upottaa salaisuuksia ja todennuslogiikkaa kuhunkin sovellukseen. Tästä tulee uskomattoman vaikeaa hallita mittakaavassa. Tarvitset nollaluottamuksen verkon, jossa jokainen palvelu todentaa ja valtuuttaa jokaisen puhelun, konseptin, joka tunnetaan nimellä Mutual TLS (mTLS) ja hienojakoinen pääsynvalvonta.

Monimutkaiset käyttöönotot ja liikenteen hallinta

Miten julkaiset uuden version Python-pohjaisesta tuotepalvelustasi aiheuttamatta seisokkeja? Yleinen strategia on kanarialintuversio, jossa ohjaat hitaasti pienen prosenttiosuuden (esim. 1 %) live-liikenteestä uuteen versioon. Jos se toimii hyvin, lisäät asteittain liikennettä. Tämän toteuttaminen edellyttää usein monimutkaista logiikkaa kuormantasaajan tai API-yhdyskäytävän tasolla. Sama koskee A/B-testausta tai liikenteen peilausta testaustarkoituksiin.

Service Mesh: Palveluiden verkko

Service mesh on oma, konfiguroitava infrastruktuurikerros, joka vastaa näihin haasteisiin. Se on verkkoympäristö, joka sijaitsee olemassa olevan verkkosi (kuten Kubernetesin tarjoaman) päällä hallitaksesi kaikkea palveluiden välistä viestintää. Sen ensisijainen tavoite on tehdä tästä viestinnästä luotettavaa, turvallista ja havaittavaa.

Ydinosat: Ohjaustaso ja datataso

Service mesh -verkolla on kaksi pääosaa:

• Datataso: Tämä koostuu joukosta kevyitä verkkoproxyjä, joita kutsutaan sidecareiksi, jotka otetaan käyttöön mikropalvelusi jokaisen esiintymän ohella. Nämä välityspalvelimet sieppaavat kaiken saapuvan ja lähtevän verkkoliikenteen palveluusi ja palvelustasi. Ne eivät tiedä tai välitä, että palvelusi on kirjoitettu Pythonilla; ne toimivat verkkotasolla. Suosituin service mesheissä käytetty välityspalvelin on Envoy.
• Ohjaustaso: Tämä on service mesh -verkon "aivot". Se on joukko komponentteja, joiden kanssa sinä, operaattori, olet vuorovaikutuksessa. Annat ohjaustasolle korkean tason sääntöjä ja käytäntöjä (esim. "yritä epäonnistuneita pyyntöjä tuotepalveluun enintään 3 kertaa"). Ohjaustaso muuntaa sitten nämä käytännöt kokoonpanoiksi ja työntää ne ulos kaikkiin datatason sidecar-välityspalvelimiin.

Tärkein takeaway on tämä: service mesh siirtää verkkohuolien logiikan pois yksittäisistä Python-palveluistasi ja alustatason kerrokseen. FastAPI-kehittäjäsi ei enää tarvitse tuoda uudelleenyrityskirjastoa tai kirjoittaa koodia mTLS-varmenteiden käsittelyyn. He kirjoittavat liiketoimintalogiikkaa, ja mesh hoitaa loput läpinäkyvästi.

Pyyntö tilauspalvelusta tuotepalveluun kulkee nyt näin: Tilauspalvelu → Tilauspalvelun sidecar → Tuotepalvelun sidecar → Tuotepalvelu. Kaikki taika – uudelleenyritykset, kuormantasaus, salaus, metriikoiden keruu – tapahtuu kahden sidecarin välillä, joita ohjaustaso hallinnoi.

Service Mesh -verkon ydinpilarit

Pilkotkaamme hyödyt, joita service mesh tarjoaa neljään avainpilariin.

1. Luotettavuus ja joustavuus

Service mesh tekee hajautetusta järjestelmästäsi vankemman muuttamatta sovelluskoodiasi.

• Automaattiset uudelleenyritykset: Jos puhelu palveluun epäonnistuu ohimenevän verkkovirheen vuoksi, sidecar voi automaattisesti yrittää pyyntöä uudelleen määritetyn käytännön perusteella.
• Aikakatkaisut: Voit pakottaa johdonmukaiset, palvelutason aikakatkaisut. Jos alavirran palvelu ei vastaa 200 ms:n kuluessa, pyyntö epäonnistuu nopeasti, mikä estää resurssien pidättämisen.
• Katkaisijat: Jos palveluesiintymä epäonnistuu jatkuvasti, sidecar voi väliaikaisesti poistaa sen kuormantasauspoolista (katkaisemalla piirin). Tämä estää ketjureaktiohäiriöt ja antaa epäterveelliselle palveluajalle aikaa palautua.

2. Syvä observabiliteetti

Sidecar-välityspalvelin on täydellinen näköalapaikka liikenteen havainnointiin. Koska se näkee jokaisen pyynnön ja vastauksen, se voi automaattisesti luoda runsaasti telemetriatietoja.

• Metriikat: Mesh luo automaattisesti yksityiskohtaisia mittareita kaikelle liikenteelle, mukaan lukien latenssi (p50, p90, p99), onnistumisprosentit ja pyyntömäärä. Työkalu, kuten Prometheus, voi poimia nämä ja visualisoida ne kojelaudassa, kuten Grafana.
• Hajautettu jäljitys: Sidecarit voivat injektoida ja levittää jäljitysotsikoita (kuten B3 tai W3C Trace Context) palvelupuheluiden välillä. Tämän avulla jäljitystyökalut, kuten Jaeger tai Zipkin, voivat yhdistää pyynnön koko matkan, mikä antaa täydellisen kuvan järjestelmäsi käyttäytymisestä.
• Käyttölokit: Hanki johdonmukaiset, yksityiskohtaiset lokit jokaisesta palveluiden välisestä puhelusta, jotka näyttävät lähteen, kohteen, polun, viiveen ja vastauskoodin, kaikki ilman yhtäkään print()-lausetta Python-koodissasi.

Työkalut, kuten Kiali, voivat jopa käyttää näitä tietoja luodakseen reaaliaikaisen riippuvuuskaavion mikropalveluistasi, jotka näyttävät liikenteen virtauksen ja terveystilan reaaliajassa.

3. Yleinen turvallisuus

Service mesh voi pakottaa nollaluottamuksen turvallisuusmallin klusterisi sisällä.

• Mutual TLS (mTLS): Mesh voi automaattisesti myöntää kryptografisia identiteettejä (varmenteita) jokaiselle palvelulle. Se käyttää näitä sitten kaiken palveluiden välisen liikenteen salaamiseen ja todentamiseen. Tämä varmistaa, että mikään todentamaton palvelu ei voi edes puhua toiselle palvelulle, ja kaikki siirrettävät tiedot salataan. Tämä otetaan käyttöön yksinkertaisella määrityskytkimellä.
• Valtuutuskäytännöt: Voit luoda tehokkaita, hienojakoisia pääsynvalvontasääntöjä. Voit esimerkiksi kirjoittaa käytännön, jossa todetaan: "Salli GET-pyynnöt palveluista, joilla on 'tilauspalvelu'-identiteetti 'tuotepalvelun' /products-päätepisteeseen, mutta kiellä kaikki muu." Tämä pakotetaan sidecartasolla, ei Python-koodissasi, mikä tekee siitä paljon turvallisemman ja auditoitavamman.

4. Joustava liikenteen hallinta

Tämä on yksi service mesh -verkon tehokkaimmista ominaisuuksista, joka antaa sinulle tarkan hallinnan siihen, miten liikenne kulkee järjestelmäsi läpi.

• Dynaaminen reititys: Reititä pyynnöt otsikoiden, evästeiden tai muiden metatietojen perusteella. Reititä esimerkiksi betakäyttäjät palvelun uuteen versioon tarkistamalla tietty HTTP-otsikko.
• Kanarialintuversiot ja A/B-testaus: Toteuta kehittyneitä käyttöönottostrategioita jakamalla liikennettä prosentteina. Lähetä esimerkiksi 90 % liikenteestä Python-palvelusi versioon v1 ja 10 % uuteen v2. Voit valvoa v2:n mittareita, ja jos kaikki näyttää hyvältä, siirrä asteittain enemmän liikennettä, kunnes v2 käsittelee 100 %.
• Vian injektio: Järjestelmäsi joustavuuden testaamiseksi voit käyttää mesh-verkkoa tarkoituksellisesti vikatilanteiden, kuten HTTP 503 -virheiden tai verkkoviiveiden, injektoimiseen tietyille pyynnöille. Tämä auttaa sinua löytämään ja korjaamaan heikkouksia ennen kuin ne aiheuttavat todellisen katkoksen.

Service Mesh -verkon valinta: Globaali näkökulma

Saatavilla on useita kypsiä, avoimen lähdekoodin service mesh -verkkoja. Valinta riippuu organisaatiosi tarpeista, olemassa olevasta ekosysteemistä ja toimintakyvystä. Kolme näkyvintä ovat Istio, Linkerd ja Consul.

Istio

• Yleiskatsaus: Googlen, IBM:n ja muiden tukema Istio on monipuolisin ja tehokkain service mesh. Se käyttää taistelukentillä testattua Envoy-välityspalvelinta.
• Vahvuudet: Vertaansa vailla oleva joustavuus liikenteen hallinnassa, tehokkaat tietoturvakäytännöt ja elinvoimainen ekosysteemi. Se on tosiasiallinen standardi monimutkaisille, yritystason käyttöönotoille.
• Huomioitavaa: Sen teho tulee monimutkaisuuden mukana. Oppimiskäyrä voi olla jyrkkä, ja sillä on suuremmat resurssikustannukset verrattuna muihin mesh-verkkoihin.

Linkerd

• Yleiskatsaus: CNCF:n (Cloud Native Computing Foundation) valmistunut projekti, joka priorisoi yksinkertaisuuden, suorituskyvyn ja toiminnallisen helppouden.
• Vahvuudet: Se on uskomattoman helppo asentaa ja aloittaa. Sillä on erittäin pieni resurssijalanjälki sen mukautetun, erittäin kevyen, Rustilla kirjoitetun välityspalvelimen ansiosta. Ominaisuudet, kuten mTLS, toimivat heti laatikosta ilman määrityksiä.
• Huomioitavaa: Sillä on mielipiteellisempi ja kohdennetumpi ominaisuusjoukko. Vaikka se kattaa havainnoinnin, luotettavuuden ja turvallisuuden ydinkäyttötapaukset poikkeuksellisen hyvin, siitä puuttuu joitain Istion edistyneitä, esoteerisia liikenteen reititysominaisuuksia.

Consul Connect

• Yleiskatsaus: Osa HashiCorp-työkalujen laajempaa valikoimaa (joka sisältää Terraformin ja Vaultin). Sen tärkein erottava tekijä on sen ensiluokkainen tuki monialustaympäristöille.
• Vahvuudet: Paras valinta hybrid ympäristöihin, jotka kattavat useita Kubernetes-klustereita, eri pilvipalveluntarjoajia ja jopa virtuaalikoneita tai paljasmetallipalvelimia. Sen integrointi Consul-palveluluetteloon on saumatonta.
• Huomioitavaa: Se on osa laajempaa tuotetta. Jos tarvitset vain service mesh -verkon yhdelle Kubernetes-klusterille, Consul saattaa olla enemmän kuin tarvitset.

Käytännön toteutus: Python-mikropalvelun lisääminen service mesh -verkkoon

Käydään läpi käsitteellinen esimerkki siitä, miten lisäisit yksinkertaisen Python FastAPI -palvelun mesh-verkkoon, kuten Istioon. Tämän prosessin kauneus on siinä, miten vähän sinun tarvitsee muuttaa Python-sovellustasi.

Skenaario

Meillä on yksinkertainen `user-service`, joka on kirjoitettu Pythonilla käyttäen FastAPI:tä. Siinä on yksi päätepiste: `/users/{user_id}`.

Vaihe 1: Python-palvelu (Ei mesh-verkkokohtaista koodia)

Sovelluskoodisi pysyy puhtaana liiketoimintalogiikkana. Istiolle, Linkerdille tai Envoylille ei ole tuonteja.

main.py:

            from fastapi import FastAPI

app = FastAPI()

users_db = {
    1: {"name": "Alice", "location": "Global"},
    2: {"name": "Bob", "location": "International"}
}

@app.get("/users/{user_id}")
def read_user(user_id: int):
    return users_db.get(user_id, {"error": "User not found"})
            

              
                Copy
              
            
          

Mukana oleva Dockerfile on myös vakio, ilman erityisiä muutoksia.

Vaihe 2: Kubernetes-käyttöönotto

Määrität palvelusi käyttöönoton ja palvelun tavallisessa Kubernetes YAML:ssä. Jälleen, ei mitään erityistä service mesh -verkolle tässä vaiheessa.

            apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service-v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: user-service
      version: v1
  template:
    metadata:
      labels:
        app: user-service
        version: v1
    spec:
      containers:
      - name: user-service
        image: your-repo/user-service:v1
        ports:
        - containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-service
  ports:
  - port: 80
    targetPort: 8000
            

              
                Copy
              
            
          

Vaihe 3: Sidecar-välityspalvelimen injektointi

Tässä taika tapahtuu. Kun olet asentanut service mesh -verkkosi (esim. Istion) Kubernetes-klusteriisi, otat automaattisen sidecar-injektoinnin käyttöön. Istiolle tämä on kertaluonteinen komento nimiavaruudellesi:

            kubectl label namespace default istio-injection=enabled
            

              
                Copy
              
            
          

Nyt, kun otat user-service:si käyttöön käyttämällä kubectl apply -f your-deployment.yaml, Istio-ohjaustaso muuttaa automaattisesti pod-spesifikaatiota ennen sen luomista. Se lisää Envoy-välityspalvelinkontin podiin. Podissasi on nyt kaksi konttia: Python user-service ja istio-proxy. Sinun ei tarvinnut muuttaa YAML:ääsi ollenkaan.

Vaihe 4: Service Mesh -käytäntöjen soveltaminen

Python-palvelusi on nyt osa mesh-verkkoa! Kaikki liikenne siihen ja siitä on välitetty. Voit nyt soveltaa tehokkaita käytäntöjä. Otetaan käyttöön tiukka mTLS kaikille nimiavaruuden palveluille.

peer-authentication.yaml:

            apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT
            

              
                Copy
              
            
          

Soveltamalla tätä yhtä, yksinkertaista YAML-tiedostoa, olet salannut ja todentanut kaiken palveluiden välisen viestinnän nimiavaruudessa. Tämä on valtava tietoturvavoitto ilman sovelluskoodin muutoksia.

Luodaan nyt liikenteen reitityssääntö kanarialintuversion suorittamiseksi. Oletetaan, että olet ottanut käyttöön user-service-v2:n.

virtual-service.yaml:

            apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: user-service
spec:
  hosts:
  - user-service
  http:
  - route:
    - destination:
        host: user-service
        subset: v1
      weight: 90
    - destination:
        host: user-service
        subset: v2
      weight: 10
            

              
                Copy
              
            
          

Tämän VirtualService:n ja vastaavan DestinationRule:n avulla (joka määrittää v1- ja v2-alijoukot) olet ohjeistanut Istiota lähettämään 90 % liikenteestä vanhaan palveluusi ja 10 % uuteen. Kaikki tämä tehdään infrastruktuuritasolla, täysin läpinäkyvästi Python-sovelluksille ja niiden kutsujille.

Milloin service mesh -verkkoa kannattaa käyttää? (Ja milloin ei)

Service mesh on tehokas työkalu, mutta se ei ole yleispätevä ratkaisu. Sen käyttöönotto lisää hallittavaa infrastruktuurikerrosta.

Ota service mesh -verkko käyttöön, kun:

• Mikropalveluidesi määrä kasvaa (tyypillisesti yli 5-10 palvelua), ja niiden vuorovaikutusten hallinnasta on tulossa päänsärkyä.
• Toimit monikielisessä ympäristössä, jossa Pythonilla, Gollalla ja Javalla kirjoitettujen palveluiden johdonmukaisten käytäntöjen pakottaminen on vaatimus.
• Sinulla on tiukat tietoturva-, observabiliteetti- ja joustavuusvaatimukset, joita on vaikea täyttää sovellustasolla.
• Organisaatiossasi on erilliset kehitys- ja toimintatiimit, ja haluat antaa kehittäjille mahdollisuuden keskittyä liiketoimintalogiikkaan samalla kun operaatiotiimi hallinnoi alustaa.
• Olet investoinut voimakkaasti konttien orkestrointiin, erityisesti Kubernetesiin, jossa service mesh -verkot integroituvat saumattomimmin.

Harkitse vaihtoehtoja, kun:

• Sinulla on monoliitti tai vain kourallinen palveluita. Mesh-verkon operatiiviset kustannukset ylittävät todennäköisesti sen edut.
• Tiimisi on pieni, eikä sillä ole kapasiteettia oppia ja hallita uutta, monimutkaista infrastruktuurikomponenttia.
• Sovelluksesi vaatii alhaisimman mahdollisen viiveen, eikä sidecar-välityspalvelimen lisäämä mikrosekuntitason yläpuolella oleva kustannus ole hyväksyttävissä käyttötapauksessasi.
• Luotettavuus- ja joustavuustarpeesi ovat yksinkertaisia, ja ne voidaan ratkaista riittävästi hyvin ylläpidetyillä sovellustason kirjastoilla.

Johtopäätös: Python-mikropalveluidesi tehostaminen

Mikropalvelumatka alkaa kehityksestä, mutta siitä tulee nopeasti operatiivinen haaste. Kun Python-pohjainen hajautettu järjestelmäsi kasvaa, verkkojen, tietoturvan ja observabiliteetin monimutkaisuus voi hukuttaa kehitystiimit ja hidastaa innovaatioita.

Service mesh vastaa näihin haasteisiin suoraan abstrahoimalla ne pois sovelluksesta ja omaan, kieliriippumattomaan infrastruktuurikerrokseen. Se tarjoaa yhtenäisen tavan hallita, suojata ja havainnoida palveluiden välistä viestintää riippumatta siitä, millä kielellä ne on kirjoitettu.

Ottamalla käyttöön service mesh -verkon, kuten Istion tai Linkerdin, annat Python-kehittäjillesi mahdollisuuden tehdä sen, mitä he parhaiten osaavat: rakentaa erinomaisia ominaisuuksia ja tuottaa liiketoiminta-arvoa. Heidät vapautetaan monimutkaisen, standardinmukaisen verkkologiikan toteuttamisen taakasta, ja he voivat sen sijaan luottaa alustaan joustavuuden, turvallisuuden ja näkemyksen tarjoamisessa. Kaikille organisaatioille, jotka suhtautuvat vakavasti mikropalveluarkkitehtuurinsa skaalaamiseen, service mesh on strateginen investointi, joka maksaa osinkoa luotettavuudessa, turvallisuudessa ja kehittäjien tuottavuudessa.