2. Los gekoppelde microservices
In een Cloud Native Architecture zien we microservices (“loose coupled lightweight services”) die applicaties opsplitsen in kleinere, onafhankelijke en implementeerbare services.
Deze services communiceren via lichtgewicht protocollen zoals HTTP of API's (Application Program Interfaces). Omdat elke kleine service een andere functie heeft, kun je ze onafhankelijk van elkaar ontwikkelen, implementeren en schalen.
In tegenstelling tot monolithische systemen kunnen teams met microservices afzonderlijke onderdelen updaten, implementeren of repareren zonder de hele applicatie te beïnvloeden. Dit voorkomt verstoringen. Dankzij deze modulariteit kunnen we:
- Frequentere updates
- Hogere betrouwbaarheid
- Snellere time-to-market
- Veerkrachtigere systemen om fouten beter te isoleren
3. Immutable infrastructuur
In Cloud Native-architecturen zijn infrastructuurcomponenten zoals servers immutable. Met andere woorden, als ze eenmaal zijn uitgerold, worden ze niet meer gewijzigd. Als er een update nodig is, wordt er een nieuwe versie van de server of component gebouwd en uitgerold, en wordt de oude buiten gebruik gesteld.
Dit vermindert mogelijke fouten of inconsistenties als gevolg van configuratie drift tijdens de deployment en rollbacks. Bovendien verbetert het je bescherming tegen aanvallen.
4. Declaratieve APIs
API's verschuiven de complexiteit van het bouwen en configureren van API's van de gebruiker naar het systeem.
Deze API's vereenvoudigen de implementatie door het systeem de complexiteit te laten afhandelen. In plaats van elk detail handmatig te configureren, definieert de gebruiker het gewenste resultaat. Het systeem dicteert vervolgens automatisch de beste manier om dit te bereiken, waardoor zowel de deployment tijd als het risico op fouten afneemt.
Service Meshes
Sommigen zullen vinden dat service meshes ook deel uitmaken van de architectuur.
Een service mesh is een infrastructuurlaag die de microservices-architectuur bewaakt en de communicatie tussen verschillende microservices beheert om de prestaties, beveiliging en observeerbaarheid (van het verkeer) te verbeteren.
Hoewel het niet altijd nodig is, kan het nuttig zijn in complexe omgevingen met meerdere microservices die vaak met elkaar communiceren.
Een service mesh is ook nuttig om te bepalen welke services met elkaar kunnen communiceren en om verkeer te encrypten (met certificaten).
Het kan ook handig zijn als je functies nodig hebt zoals inter-service, load balancing of observeerbaarheid.
De principes van Cloud Native Architectuur
Automatisering
Het is cruciaal om te ontwerpen voor automatisering bij het creëren van een architectuur. Wat bedoelen we hiermee?
Dit betekent dat we code en infrastructuur moeten creëren om deze te automatiseren en eenvoudig te beheren met softwaretools, zodat we resources snel en consistent kunnen leveren in de infrastructuur.
Stel je voor: je bouwt een e-commerce platform met tonnen productdata. In het traditionele infrastructuurtijdperk had je handmatig een server moeten installeren, vervolgens de software moeten installeren en de database moeten configureren om de gegevens op te slaan - wat aanvoelde als een eindeloos proces waarbij fouten niet konden worden uitgesloten.
Wat automatisering betreft, betekent Cloud Native ook de hele levenscyclus van applicaties. Denk aan het creëren van continuous integration (CI), continuous development (CD) pipelines, GitOps workflows, auto-scaling en self-healing systemen.
Door te ontwerpen voor automatisering kunnen we:
- Ontwikkel- en deploymentprocessen versnellen
- De handmatige fouten verminderen - minder menselijke fouten
- Consistenter zijn
Stateless
Stateless applicaties zijn een cruciaal principe en stimuleren verandering. Ze zijn veel handiger als het gaat om schalen, herstellen, terugdraaien en balanceren.
Stateful applicaties daarentegen, die gegevens direct beheren en opslaan, kunnen behoorlijk riskant en complex zijn. Wanneer in stateful applicaties een stateful microservice faalt, verliest deze zijn status, waardoor mogelijk het hele systeem ontregeld raakt.
Maar wat betekent het voor een applicatie om stateless te zijn? Laten we beginnen met het definiëren van state: de state is hoe een app de status voor een gebruiker definieert.
In een e-commerce shop kan de status zijn:
- Producten toegevoegd aan de winkelwagen
- Het aankoopproces
- Login status (ingelogd of niet)
In een stateless architectuur wordt de state losgekoppeld van de applicatie-instantie, waardoor het systeem sterker, flexibeler en schaalbaarder wordt.
Laten we dit toelichten met een voorbeeld. Stel je voor dat je online winkelt en items toevoegt aan je verlanglijstje. In een stateful architectuur, als de server crasht terwijl je je verlanglijstje samenstelt, kunnen je toegevoegde items verloren gaan en moet je opnieuw beginnen.
In een stateless architectuur worden de wishlist-gegevens opgeslagen op een gecentraliseerde locatie, zoals een cache of een beheerde database (PaaS). Als de server crasht of de gebruiker inlogt vanaf een ander apparaat, zal zijn verlanglijstje intact en beschikbaar zijn, en de ervaring zal naadloos zijn, zelfs als de server down is.
Wanneer een stateless microservice faalt, kun je hem herstarten en zal hij verder gaan waar hij gebleven was zonder gegevens te verliezen, omdat de service sessie- of toestandsinformatie niet intern opslaat. In plaats daarvan haalt de microservice de status op uit de externe database of cache.
We kunnen het vergelijken met het kijken naar een film op Netflix.
Telkens als je begint te kijken, hoeft Netflix alleen maar te onthouden hoe ver je al bent. Als er iets misgaat, kun je het opnieuw starten en gaat het precies verder waar je gebleven was.
Defence in depth
Van oudsher was beveiliging gebaseerd op perimetergebaseerde strategieën, waarbij de nadruk lag op het beschermen van de buitenste laag van het netwerk met firewalls en vergelijkbare tools. Maar Cloud Native-applicaties zijn gedistribueerd en werken in meerdere omgevingen. Er is dus een uitgebreidere, multi-layered benadering van beveiliging nodig.
Dat is waar verdediging in de diepte om de hoek komt kijken, wat het systeem veerkrachtiger en gemakkelijker inzetbaar maakt. Defence in depth is het gebruik van meerdere beveiligingslagen om je applicaties en gegevens te beschermen.
Je kunt bijvoorbeeld defence in depth op meerdere lagen implementeren:
- Netwerklaag: Gebruik firewalls om inkomend en uitgaand verkeer te beperken tot alleen noodzakelijke poorten en protocollen.
- Applicatielaag: Implementeer invoervalidatie om ervoor te zorgen dat gebruikersinvoer correct is geformatteerd en vrij is van kwaadaardige inhoud. Implementeer ook het scannen van code tijdens het bouwen om kwetsbaarheden te detecteren en beveilig de app voordat deze wordt ingezet.
- Database laag: Gebruik encryptie om gevoelige gegevens in rust te beschermen en implementeer toegangscontroles om ervoor te zorgen dat alleen geautoriseerde gebruikers toegang hebben tot de database.
Verschillende beveiligingscontroles op verschillende punten in het systeem zorgen ervoor dat zelfs als één laag wordt gecompromitteerd, de andere lagen er nog steeds zijn om uw applicatie veilig te houden. Lees meer over Cloud Native security.
Managed services bevoordelen
Vroeger was het opzetten en onderhouden van een IT-infrastructuur erg complex en omslachtig. Je moest de servers fysiek bestellen en installeren en netwerken configureren - wat dagen of weken duurde. En dat was nog niet alles; je moest zelf al het onderhoud doen, wat zowel duur als arbeidsintensief was.
Tegenwoordig verlichten cloudproviders die pijn door managed services aan te bieden. Deze stellen bedrijven in staat om resources te gebruiken zonder de last van het beheren van licenties, provisionering en onderhoud.
En je hoeft je geen zorgen meer te maken over de onderliggende infrastructuur omdat de cloudproviders deze verantwoordelijkheid op zich nemen (gedeelde verantwoordelijkheid). Je kunt je dus richten op het bouwen en uitvoeren van je applicatie en het creëren van zakelijke waarde voor je klanten in plaats van je bezig te houden met infrastructuur.
Schaalbaar
Cloud Native applicaties zijn ontworpen om automatisch op- of af te schalen op basis van de vraag van de gebruiker. Ze zijn elastisch en kunnen efficiënt omgaan met wisselende loads, enzovoort, om het gebruik van resources en de kosten te optimaliseren.
Terwijl traditionele infrastructuur vaste hardware- of softwarebronnen vereist, kunnen Cloud Native-applicaties profiteren van de elasticiteit van de cloud door meer resources te gebruiken tijdens piekmomenten.
In een Cloud Native architectuur kun je functionele gebieden van onze applicatie ook naar behoefte schalen. Zo kun je ervoor zorgen dat je nooit overcapaciteit hebt en dat je gemakkelijk toegang hebt tot meer resources als de vraag plotseling zou stijgen.
Dit zou niet mogelijk zijn geweest als je je eigen datacenter had gerund, omdat je er dan voor moet zorgen dat je voldoende servercapaciteit hebt om veeleisende dagen aan te kunnen. En tijdens rustigere dagen zou je waarschijnlijk een hoge prijs moeten betalen.
Agile DevOps using CI/CD
Een van de kernprincipes van Cloud Native is Agile DevOps, met name CI en CD. Hierdoor kunnen ontwikkel- en operationele teams samenwerken om het softwareleveringsproces te versnellen.
Met CI/CD-pijplijnen worden codewijzigingen automatisch getest, geïntegreerd en gedeployed naar productieomgevingen zonder menselijke tussenkomst. Dit betekent snellere updates, releases van hogere kwaliteit en sneller reageren op problemen.
Het automatiseren van testen en implementaties, en infrastructuurwijzigingen door middel van CI/CD en GitOps stelt teams in staat om een snelle releasecyclus te hebben en menselijke fouten te verminderen. GitOps definieert de gewenste staat van de infrastructuur declaratief (als IaC) en zorgt voor consistentie en immutabiliteit. Dit is essentieel voor Cloud Native-omgevingen die schaalbaarheid, flexibiliteit en veerkracht vereisen.
Wat zijn de voordelen van een Cloud Native architectuur?
De voordelen van een Cloud Native architectuur zijn eindeloos. Laten we ze stuk voor stuk toelichten.
1. Security
Eerst en vooral: beveiliging. In een Cloud Native Architecture ontwerpen we onze structuur met security op de eerste plaats - direct vanaf het begin.
Hierin passen we het Zero Trust-principe toe, dat ervan uitgaat dat geen enkel onderdeel van het systeem automatisch wordt vertrouwd, zowel binnen als buiten het netwerk.
Dit verifieert continu de identiteit en integriteit van gebruikers, apparaten en systemen op elk access point.
2. Flexibiliteit
De Cloud Native-benadering geeft ons meer flexibiliteit om applicaties bij te werken en aan te passen aan veranderende eisen van klanten.
Dit is te danken aan het bouwen van deze applicaties met behulp van moderne tools en technieken die app-ontwikkeling voor cloudinfrastructuren ondersteunen.
3. Schaalbaarheid
Een belangrijk voordeel van Cloud Native-architecturen is de mogelijkheid om naadloos te schalen. Traditionele applicaties hebben vaak te maken met beperkingen wanneer ze proberen te schalen.
4. Kostenefficiënt
Cloud Native biedt pay-as-you-go en on-demand toegang tot verschillende tools en infrastructuur. Dit alles zonder kosten vooraf. In traditionele omgevingen moeten systemen altijd aan staan om klanten te bedienen.
Maar met de cloud kan je de focus verleggen naar innovatie en minder naar onderhoud. Overschakelen naar de cloud kan het risico op downtime verminderen. Het is betrouwbaarder en kan uitval aan. Dit beschermt je reputatie en verlaagt de kosten.
5. Verbeterde weerbaarheid
Cloud Native-applicaties zijn ontworpen om veerkrachtig te zijn. Met andere woorden, als er ergens in het systeem een onverwachte gebeurtenis plaatsvindt, zoals een storing of verstoring, kunnen ze nog steeds functioneren. Bovendien zijn ze ontworpen om te herstellen van storingen, waardoor een continue hoge beschikbaarheid automatisch wordt gegarandeerd.
6. Portabiliteit tussen cloudaanbieders
De portabiliteit van gecontaineriseerde microservices zorgt ervoor dat een organisatie niet te afhankelijk is van slechts één cloudprovider. Dit biedt meer flexibiliteit en vermindert lock-in bij cloudleveranciers.
7. Flexibiliteit bij het kiezen van frameworks en talen
Door gebruik te maken van los gekoppelde services in plaats van een enterprise tech stack kunnen ontwikkelteams het beste framework, de beste taal of het beste systeem kiezen voor de doelen van hun project.
8. Geoptimaliseerde gebruikerservaring
Omdat microservices onafhankelijk opereren, kunnen ontwikkelaars elke microservice optimaliseren op basis van kernfunctionaliteit. Dit leidt tot een meer verfijnde en verrijkte eindgebruikerservaring.
9. Gefaciliteerde CI & CD
Het gebruik van microservices in softwareontwikkeling vergemakkelijkt CI- en CD-inspanningen. Dit verkort de ontwikkelingslevenscyclus en minimaliseert de kans op menselijke fouten. Container orchestrators kunnen automatisch resources plannen en toewijzen op basis van de vraag om de efficiëntie te verhogen.
10. Snellere time to market
Moderne Cloud Native applicatiearchitectuur maakt ook snellere ontwikkelingscycli mogelijk door middel van continue integratie en continue levering (CI/CD). Bedrijven kunnen vaker en vol vertrouwen updates uitbrengen, innovatie stimuleren en snel reageren op feedback van klanten.
11. Onafhankelijke updates en releases van functies
Met microservices in app-architectuur kunnen ontwikkelaars een service wijzigen of toevoegen. Ze kunnen dit doen zonder de hele app of de beschikbaarheid ervan te beïnvloeden.
12. Simplified troubleshooting
Een open-source container orkestratieplatform, zoals Kubernetes, vereenvoudigt het oplossen van problemen. Het helpt de container met een bug of probleem te vinden zonder de hele app te ontmantelen.
