I cloud-native miljøer, hvor virtualisering implementeres via containere og apps udløst via mikroservices, hvor er det optimale niveau for at håndhæve sikkerhed? For et par uger siden rapporterede ZDnet-kollega Steven J. Vaughan-Nichols om en udbyder, der leverede den via en agent på OS-niveau.
Nu søger en anden opstart at løse dette på mikroserviceniveau med en tilgang, der opdeler forskellen mellem API -gateways og servicemasker.
API -gateways har traditionelt været centraliserede punkter til styring af forbindelser i applikationslaget. De administrerer trafik mellem klienter og mikrotjenester, ofte omtalt som nord-syd trafik, fordi den ofte kommer fra klienter uden for datacenteret.
I modsætning hertil har servicemasker med deres afhængighed af proxyer fundet trækkraft i distribuerede miljøer til at styre forbindelsen til appen og transportlagene. De håndterer typisk det, der kaldes øst-vest-trafik i en Kubernetes-klynge eller datacenter. Hver proxy er korrekt designet og koder for regler, hvorpå mikrotjenester kan tale med hinanden.
I nogle tilfælde har der været en fremkommelse af de to, hvor servicemasker delegerer noget appforbindelsesstyring til API -gateways, der fungerer som et underlag af tilslutningsmuligheder. Og ja, der er udgivet e-bøger om emnet.
Grundlæggerne af Solo.io oplevede et truende problem, da servicesmasker begyndte at vinde indpas takket være Kubernetes -platforme som Anthos og OpenShift. Den udfordring, de så komme, var en af skalerbarheden af ledelsen: politikker eller regler for hver proxy skulle udvikles en efter en. De var ingen måde at administrere på tværs af flere proxyer. Af hensyn til styring eller sikkerhed kræver disse platforme typisk eksterne gateways eller alternativer på OS-niveau til håndhævelse af politikker, idet det samme gælder for de respektive K8s-tjenester på hver af de store skyer.
Arbejdsintensiteten i sådanne bestræbelser kunne undergrave, hvad der formodes at være en stor fordel ved cloud-native implementering: et forenklet kontrolplan, der lover mere fleksibilitet takket være de facto-standarder som K8'er, der kan gøre det til en anden natur at skalere op eller ned i cloud-native klynger. < /p>
Solo.io udviklede oprindeligt et produkt baseret på envoy -proxyen, der fungerer som en API -gateway inden for et Istio -servicenet til styring af trafik mellem klienter og Kubernetes -klynger. De er for nylig blevet udvidet med et mere omfattende virksomhedsprodukt, der kan administrere flere servicemasker på tværs af en eller flere Kubernetes -klynger. Forestillingen er, at selv om håndhævelse af politikker kan fordeles på flere proxyer, kan den administreres centralt og konsekvent uden at skulle kode hver proxy individuelt.
Gloo Mesh Enterprise tilføjer kontrolplanet for Istio ved at forbedre observerbarheden, til overvågning og fejlfinding adfærd over tid; integrere eksterne certifikatudbydere med eksisterende PKI -infrastruktur; og understøtte opdagelse af indgangsveje for hvert administreret servicenet.
Dette er en vis aktivitet i open source -verden for at tackle dette problem. Network Service Mesh er beregnet til at levere fælles API'er til adressering af forbindelse, sikkerhed og observerbarhed. Det ville give individuelle K8'er bælge til et sikkert netværk på tværs af klynger eller skyer; men dette projekt er stadig i sandkassestatus med Cloud Native Computing Foundation.
Vores antagelse af fremkomsten af K8s-baserede skyplatforme er, at de er bygget på standarder, hvilket betyder, at organisationerne ikke behøver at genopfinde hjulet, når det kommer til at bygge den dynamiske lim, der gør det muligt for klynger at skalere op og ned. Men vi mener også, at for de fleste organisationer, der mangler de sofistikerede ressourcer til at bygge deres egne private skyer, bør K8'er ikke udvikles hjemme. Den gode nyhed er, at der er startups som Solo.io, der er begyndt at løse nogle af ledelsesmanglerne.
Big Data
Hvor er IBMs hybrid cloud -startplade? Syv måder at gøre realtidsteknologi til virkelighed for din organisation Maskinlæring på kanten: TinyML bliver stor Hvad sker der for Cloudera? McDonald's ønsker at 'demokratisere' maskinlæring for alle brugere på tværs af sine aktiviteter
Relaterede emner:
Cloud Digital Transformation Robotics Internet of Things Innovation Enterprise Software 