Cloudcomputing uitgelegd: de 11 architectuurconcepten die je moet kennen (4K Masterclass).

Wat deze video behandelt

• - De Architectuurmuur & Master Blueprint
• - 01. Verticale vs. Horizontale Schaalvergroting
• - 02. Load Balancing Architectuur (L4 vs. L7 & Health Checks)
• - 03. Autoscaling & Elasticiteit
• - 04. Serverloos (FaaS & Firecracker MicroVM's)

Vertaald transcript

Vertaald vanuit de originele Engelse gesproken tekst. Beschikbare audio en ondertiteling worden beheerd door YouTube.

- De Architectuurmuur & Master Blueprint

0:00 Elke software-engineer komt uiteindelijk de cloudarchitectuurmuur tegen. Je bouwt een applicatie op je laptop, zet deze in productie, en op het moment dat echte gebruikers arriveren, crashen servers, databaseverbindingen raken op en je AWS-factuur ziet eruit als een telefoonnummer. De meeste ontwikkelaars proberen cloud-engineering op te lossen door driehonderd verschillende AWS-productacroniemen te memoriseren. Maar echte cloudcomputing gaat niet over het memoriseren van leverancierscatalogi: het is gebouwd op elf fundamentele architecturale primitieven.

0:34 In deze masterclass doorlopen we de complete enterprise-blauwdruk: van schalen en load balancing tot serverloos, event-gedreven ontkoppeling, opslaghiërarchieën en cloudnetwerken. Beheers deze elf concepten en je kunt elke backend ontwerpen op AWS, GCP of Azure. Dit is The Daily Diff, onder de motorkap.

- 01. Verticale vs. Horizontale Schaalvergroting

0:57 Concept nummer één: Schaalvergroting. Wanneer uw applicatie verkeersgroei ervaart, heeft u twee fundamenteel verschillende manieren om de belasting af te handelen: verticale schaalvergroting, of horizontale schaalvergroting. Verticale schaalvergroting, of opschalen, betekent uw bestaande machine nemen en meer resources toevoegen: upgraden van vier CPU-kernen naar tweeëndertig, of tweeëndertig gigabyte RAM inruilen voor honderd achtentwintig. Verticale schaalvergroting vereist geen architecturale wijzigingen: uw code

1:28 en database blijven exact hetzelfde. Maar het stuit op een brutale hardwareplafond. Geen enkele machine ter wereld heeft tienduizend CPU-kernen, en topklasse-instances brengen een exponentiële prijspremie met zich mee. Horizontale schaalvergroting, of uitschalen, betekent uw servers klein en tegen handelsgoederenprijs houden, maar meerdere instances parallel draaien achter een router. Als één instance crasht, absorberen de resterende knooppunten het verkeer zonder enige downtime. De gouden regel van horizontale schaalvergroting is

2:01 staatloosheid: uw applicatieservers kunnen geen gebruikerssessies, geüploade bestanden of status op hun lokale schijven opslaan. De status moet zich in een externe database of cache bevinden, waardoor elk knooppunt elke gebruikersaanvraag kan afhandelen.

- 02. Load Balancing Architectuur (L4 vs. L7 & Health Checks)

2:17 Concept nummer twee: Load Balancing. Horizontale schaalvergroting klinkt op papier geweldig, maar introduceert een direct probleem: wanneer tienduizend gebruikers uw domeinnaam bezoeken, welke specifieke server ontvangt hun verkeer dan? Een load balancer fungeert als een reverse proxy die zich bevindt tussen het openbare internet en uw privé backend-cluster. Het accepteert inkomende TCP- of HTTP-verbindingen en verdeelt verzoeken over uw gezonde instances.

2:47 Load balancers werken op twee primaire netwerklagen. Layer 4 Network Load Balancers werken op de transportlaag, het routeren van ruwe TCP- en UDP-pakketten op basis van IP-adres en poort met microseconde latentie en miljoenen verzoeken per seconde. Layer 7 Application Load Balancers inspecteren het HTTP-protocol zelf: het lezen van URL-paden, aanvraagheaders, cookies en HTTP-methoden. Dit maakt path-based routing mogelijk: het versturen van slash-api verzoeken naar uw backend-cluster en slash-statische verzoeken naar een

3:25 objectopslag. Cruciaal is dat load balancers actieve gezondheidscontroles uitvoeren. Elke paar seconden pingt de balancer een gezondheidseindpunt op elke instantie. Als een instantie drie opeenvolgende vijfhonderd fouten genereert of niet reageert, wordt deze automatisch uit de pool verwijderd met nul gemiste verzoeken.

- 03. Autoscaling & Elasticiteit

3:45 Concept nummer drie: Autoscaling. Als uw web-app om drie uur 's nachts twee servers nodig heeft, maar twintig servers tijdens een lancering 's middags, is handmatig klikken op knoppen in de cloudconsole een gegarandeerd pad naar downtime en faillissement. Autoscaling brengt dynamische elasticiteit naar horizontale serverpools. Een Auto Scaling Groep bewaakt prestatiegegevens zoals gemiddeld CPU-gebruik, netwerk I-O of wachtrijachterstand diepte. Wanneer het gemiddelde CPU een gedefinieerde drempel overschrijdt – zeg,

4:19 zeventig procent gedurende drie opeenvolgende minuten – lanceert de autoscaler automatisch nieuwe virtuele machines, registreert deze bij uw load balancer, en begint met het routeren van verkeer. Even belangrijk is het inkrimpen: wanneer de verkeersgolf afneemt, beëindigt de autoscaler overtollige instances zodat u niet meer betaalt voor inactieve rekenkracht. Om "flapping" te voorkomen – waarbij servers snel worden gecreëerd en vernietigd in een eindeloze thrashing-loop – configureren cloudarchitecten afkoelingsperiodes. Concept nummer vier: Serverloos.

- 04. Serverloos (FaaS & Firecracker MicroVM's)

4:53 Jarenlang pitchten marketingteams serverloos als magische code die in de lucht draait. In werkelijkheid gebruikt serverloos nog steeds servers — maar u bezit ze niet, patcht ze niet en betaalt er niet voor wanneer er geen code draait. Met Function-as-a-Service zoals AWS Lambda of Google Cloud Functions, schrijf je een zelfstandige handler-functie. Wanneer een HTTP-verzoek, S3-bestandsupload of databasewijziging optreedt, start de cloud-runtime een vluchtige

5:23 micro-virtuele-machine zoals Firecracker in minder dan vijf milliseconden. Uw code wordt uitgevoerd, retourneert een antwoord en wordt afgesloten. Als niemand uw website drie maanden bezoekt, is uw rekenrekening precies nul dollar en nul cent. Als een miljoen gebruikers het tegelijkertijd raken, spint de provider een miljoen gelijktijdige microVM's op. De technische afwegingen zijn reëel: koude start latentie bij het opstarten van nieuwe runtimes, een harde uitvoeringslimiet van vijftien minuten op Lambda, en strikte staatloosheid.

5:55 Serverloos is onverslaanbaar voor eventpijplijnen en sporadische API's, maar slecht voor persistente WebSockets of meerurige trainingsruns.

- 05. Event-Driven Architectuur (EDA & Ontkoppeling)

6:05 Concept nummer vijf: Event-Driven Architectuur, of EDA. In traditionele architecturen communiceren services synchroon. Uw checkout-service roept betaling aan, betaling roept inventaris aan, inventaris roept fraude aan en fraude roept e-mail aan. Dit creëert de synchrone cascade van onheil. Als de e-mailprovider van derden een netwerkhapering ondervindt en er tien seconden over doet om te reageren, time-out het volledige afrekenverzoek van uw klant met een fout. In een event-gestuurde architectuur zijn services volledig ontkoppeld.

6:37 Wanneer een klant op kopen klikt, roept de afrekeningsservice geen downstream services aan. Het publiceert eenvoudigweg een gebeurtenis genaamd OrderPlaced naar een centrale Event Bus zoals Amazon EventBridge of een SNS-onderwerp. De afrekening voltooid in vijftig milliseconden. Downstream-medewerkers voor betaling, inventarisatie en e-mailontvangsten halen berichten onafhankelijk op uit hun eigen dedicated SQS-wachtrijen. Als de e-mailservice een uur uitvalt, wachten berichten veilig gebufferd in de wachtrij zonder één enkele gemiste bestelling.

- 06. Container Orchestratie (Docker & Kubernetes)

7:13 Concept nummer zes: Container Orchestration. Docker loste het verpakken op: het verpakt uw applicatiecode, systeembibliotheken, configuratie en runtime in een onveranderlijke image die identiek draait op uw MacBook en in de cloud. Maar het verpakken van een container is eenvoudig. Vijfhonderd containers draaien op vijftig fysieke virtuele machines is waar engineering faalt. Daarom bestaan container orchestrators zoals Kubernetes en AWS ECS.

7:41 Een orchestrator biedt een control plane: een API-server, een etcd state store en een intelligente scheduler. U declareert uw gewenste staat: ik wil tien replica's van mijn auth-service met elk twee gigabyte RAM. De scheduler inspecteert het cluster, plaatst pods op knooppunten met vrij geheugen, configureert interne netwerken en verzoent voortdurend de realiteit. Als een knooppunt een hardwarefout ondervindt, detecteert Kubernetes het verlies en herplandt direct alle verplaatste pods naar

- 07. De 4 Cloud Opslagpilaren (S3, EBS, DB's & Redis)

8:16 gezonde knooppunten. Concept nummer zeven: De Cloud Opslaghiërarchie. Beginners behandelen cloudopslag vaak als een enkele bucket waar je bestanden dumpt. In productie-architectuur is opslag verdeeld in vier afzonderlijke pilaren op basis van toegangspatronen en latentie. Eerst is Object Storage, zoals Amazon S3 of Google Cloud Storage. U opent bestanden via HTTP REST API's met behulp van eenvoudige PUT- en GET-aanroepen. Het biedt oneindige horizontale capaciteit tegen twee cent per gigabyte per maand,

8:49 waardoor het ideaal is voor video, gebruikersuploads, logs en back-ups. Ten tweede is Block Storage, zoals Amazon EBS. Dit zijn virtuele harde schijven die rechtstreeks op een specifieke virtuele machine zijn aangesloten via snelle interconnecties. Ze formatteren naar standaard bestandssystemen zoals ext4, ter ondersteuning van snelle willekeurige lees- en schrijftoegang die vereist is door database-engines. Ten derde zijn er Beheerde Databases: relationele engines zoals PostgreSQL op RDS die ACID-transacties en complexe joins bieden,

9:21 en NoSQL-engines zoals DynamoDB die een vertraging van enkele cijfers in milliseconden leveren op massale schaal. En ten vierde zijn er In-Memory Caches zoals Redis. Het lezen van gegevens uit RAM duurt microseconden in plaats van milliseconden. Caches zitten voor uw database, beschermen deze tegen herhaald leesverkeer en beheren vluchtige gebruikerssessietokens.

- 08. Hoge Beschikbaarheid & De Negens (Multi-AZ Failover)

9:44 Concept nummer acht: Hoge Beschikbaarheid, of HA. Beschikbaarheid beantwoordt één vraag: hoeveel procent van de tijd is uw applicatie operationeel en bereikbaar voor gebruikers? In zakelijke contracten wordt beschikbaarheid gemeten in negens. Twee negens, of negenennegentig procent beschikbaarheid, staat meer dan drie en een halve dag downtime per jaar toe. Vier negens verlaagt de toegestane downtime naar tweeënvijftig minuten, en vijf negens staat amper vijf minuten totale downtime per

10:15 jaar toe. Om hoge beschikbaarheid te bereiken, moet u single points of failure elimineren over foutdomeinen. In de cloud betekent dat implementeren over meerdere Beschikbaarheidszones. Een Beschikbaarheidszone is geen enkel rek: het is een of meer afzonderlijke fysieke datacenters kilometers uit elkaar met onafhankelijke stroom en koeling. Door actieve instances te draaien in Zone A en Zone B met synchrone databasereplicatie, resulteert een blikseminslag of glasvezelbreuk die een complete fysieke faciliteit uitschakelt in een geautomatiseerde failover.

10:50 in dertig seconden zonder menselijke tussenkomst.

- 09. Duurzaamheid vs. Beschikbaarheid (Waarom 11 Negens Geen Uptime Is)

10:53 Concept nummer negen: Duurzaamheid versus Beschikbaarheid. Dit is de meest voorkomende conceptuele valstrik in cloudarchitectuur interviews. Ingenieurs gebruiken de woorden vaak door elkaar, maar ze meten compleet verschillende eigenschappen. Beschikbaarheid meet uptime: kan ik nu een API-aanroep doen om mijn gegevens te lezen of te schrijven? Duurzaamheid meet conservering: blijven mijn gegevens behouden zonder permanente bitrot, corruptie of vernietiging over tien jaar?

11:24 Kijk naar Amazon S3 Standard. De Service Level Agreement biedt negenennegentig komma negen procent beschikbaarheid, wat ongeveer drieënveertig minuten downtime per maand toestaat waarbij een API-verzoek een vijfhonderd-fout kan retourneren. Maar S3 belooft elf negens duurzaamheid: negenennegentig komma negen negen negen negen negen negen negen negen negen procent. Als u tien miljoen bestanden opslaat in S3, kunt u statistisch gezien verwachten dat u gemiddeld één bestand verliest elke tienduizend jaar.

11:56 gemiddeld één bestand elke tienduizend jaar. S3 bereikt dit door objecten te coderen met erasure-coding en brokken te repliceren over ten minste minste drie geografisch gescheiden datacenters. Tijdens een grote regionale netwerkstoring kan S3 tijdelijk onbeschikbaar zijn, maar uw gegevens worden nooit vernietigd.

- 10. Infrastructuur als Code (Terraform vs. Console Drift)

12:14 Concept nummer tien: Infrastructuur als Code, of IaC. In de begintijd van cloudcomputing logden ingenieurs in op de AWS webbeheerconsole en klikten handmatig rond om virtuele machines te maken, machines te maken, subnets te configureren en beveiligingsgroepen te koppelen. De industrie noemt dit ClickOps, en in productie is het een absolute ramp. Handmatige consolewijzigingen hebben geen audittrail, geen rollback- mechanisme, en veroorzaken onvermijdelijk configuratieafwijkingen tussen staging- en productieomgevingen. Met Infrastructuur

12:48 als Code-tools zoals Terraform, OpenTofu, Pulumi of AWS CDK, definieert u uw volledige cloudarchitectuur in declaratieve configuratiebestanden opgeslagen in Git. Elke wijziging aan een open poort of databasereplica gaat via een pull request en peer review. Het uitvoeren van terraform plan toont een preview van de exacte API-diff voordat er iets wordt aangeraakt, en het opzetten van een identieke replica van uw productiestack stack duurt vier minuten in plaats van vier weken.

- 11. Cloud Netwerken (VPC, Subnets, NAT & Beveiligingsgroepen)

13:20 Concept nummer elf: Cloudnetwerken en Virtuele Private Clouds. Wanneer u servers in de cloud implementeert, staan deze niet blootgesteld aan het ruwe openbare internet. Ze leven binnen een software-gedefinieerde geïsoleerde grens genaamd een VPC. Binnen uw VPC wijst u een privé IP-adresbereik toe, zoals tien-punt-nul-punt-nul-punt-nul slash zestien, en verdeelt u het in openbare en privé subnets. Een openbaar subnet heeft een directe route naar een Internet Gateway.

13:51 Het bevat openbaar toegankelijke activa zoals uw Application Load Balancers en NAT Gateways. Het is het enige deel van uw netwerk dat openbare IP- adressen bezit. Uw applicatieservers en productiedatabases leven strikt in privé subnets zonder openbare IP's en nul inkomende routes vanaf het internet. Wanneer uw backend-servers beveiligingsupdates moeten downloaden, loopt hun uitgaande verkeer via de NAT Gateway in het openbare subnet. Rondom elke instantie bevinden zich Security Groups: stateful virtuele firewalls die het principe van minste bevoegdheid afdwingen.

- 12. De Complete Enterprise Blauwdruk & Oordeel

14:28 Uw databasebeveiligingsgroep accepteert alleen verbindingen op poort 5432 strikt van de beveiligingsgroep van uw applicatieservers, waardoor penetratie van buitenaf mathematisch onmogelijk is. Wanneer je uitzoomt, verbinden deze elf primitieven zich tot één samenhangend systeem. Uw DNS routeert naar een Load Balancer in een openbaar subnet, autoscaling groups verwerken verkeerspieken over meerdere Beschikbaarheidszones, event buses ontkoppelen backend-werkers, en uw hele stack wordt ingeïmplementeerd vanuit Git met behulp van Infrastructure as Code.

15:02 Het oordeel van de masterclass van vandaag: SHIP IT. Stop met het memoriseren van honderden cloudmarketingafkortingen. Beheers deze elf architectuurpatronen, ontkoppel uw staat, en bouw systemen die niet kunnen falen. Vertel me welk cloudconcept u de grootste hoofdpijn bezorgde toen u begon met bouwen in de reacties. En om het complete architectuurspiekbriefje te bemachtigen, abonneer u op de nieuwsbrief op the daily diff dot dev,

15:28 link hieronder. En dat is de diff voor vandaag. Ik ben Niko van Axrisi. Verantwoord samenvoegen.

Bronnen

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io