Google PCD: Cloud-native applicatiearchitectuur en serviceselectie — Studiegids

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Onderdeel van de Google Professional Cloud Developer — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Cloud-native applicatiearchitectuur op Google Cloud richt zich op het bouwen van stateless, veerkrachtige services die horizontaal schalen, de operationele last minimaliseren en waar mogelijk gebruikmaken van beheerde (managed) services. Een effectieve servicekeuze vereist inzicht in de afwegingen tussen controle, portabiliteit, prestaties, kosten en operationele verantwoordelijkheid. Dit gedeelte presenteert principes en patronen die u helpen bij het ontwerpen, moderniseren en beheren van applicaties voor wereldwijde gebruikers met voorspelbare betrouwbaarheid.

Cloud-Native Principes en Architectuurkeuzes

Twelve-factor en stateless ontwerp
- Codebase, afhankelijkheden en build-release-run: Pin exacte afhankelijkheden, creëer onveranderlijke (immutable) artefacten en scheid de build- van de releasefase. Container-images en Cloud Build-pipelines dwingen reproduceerbare releases af.
- Config in de omgeving: Externaliseer configuratie met omgevingsvariabelen, Secret Manager, Kubernetes Secrets of instance metadata voor Compute Engine. Bak geen credentials of implementatie-specifieke instellingen in images. Gebruik voor Compute Engine managed instance groups de instance template metadata voor waarden per implementatie.
- Backing services: Behandel databases, wachtrijen en caches als gekoppelde resources. Geef de voorkeur aan beheerde services (Cloud SQL, Cloud Spanner, Firestore, Memorystore, Pub/Sub) om de operationele last te verminderen.
- Stateless processen: Schaal door instances toe te voegen; sla sessiestatus extern op (Memorystore for Redis, Firestore of Spanner). Schrijf logs naar stdout/stderr of naar logbestanden die door de Cloud Logging-agent worden verzameld.
- Vervangbaarheid (Disposability): Snel opstarten/afsluiten maakt snelle schaalvergroting en rolling updates mogelijk. Verwerk SIGTERM voor een ‘graceful shutdown’ (gecontroleerde afsluiting).
- Logs als eventstromen: Verstuur gestructureerde logs; gebruik Cloud Logging voor opname (ingestion) en Cloud Monitoring voor alarmering.
Architecturale afwegingen
- Monoliet
  - Voordelen: Vereenvoudigde ontwikkeling/testen, minder netwerkgrenzen, één enkele deployment-eenheid.
  - Nadelen: Tragere onafhankelijke levering, schaalbeperkingen, nauwe koppeling tussen domeinen.
  - Storingsmodi: Eén ‘hot path’ kan gedeelde resources verbruiken; regressies hebben impact op alle features.
- Modulaire monoliet
  - Voordelen: Duidelijke interne modulegrenzen, refactoring-pad naar services, één deployable.
  - Nadelen: Nog steeds beperkt door de monolithische implementatie en database.
  - Gebruik voor teams die domeingrenzen verfijnen voordat services worden geëxtraheerd.
- Microservices
  - Voordelen: Onafhankelijke implementeerbaarheid, gerichte schaalvergroting, teamautonomie, foutisolatie met de juiste ‘bulkheads’.
  - Nadelen: Complexiteit van gedistribueerde systemen, consistentie, observeerbaarheid en operationele overhead.
  - Storingsmodi: Cascaderende storingen via synchrone aanroepen; ‘schema drift’; ‘chatty’ netwerken.
- Event-driven
  - Voordelen: Losse koppeling, asynchrone veerkracht, natuurlijke buffering, auditeerbaarheid via logs/streams.
  - Nadelen: Complexiteit bij debuggen, ’eventual consistency’, volgorde en ’exactly-once’-semantiek zijn moeilijk.
  - Pub/Sub biedt ‘at-least-once delivery’; ontwerp idempotente consumers.
- Serverless (Cloud Run, Cloud Functions, App Engine)
  - Voordelen: Minimale operations, schalen naar nul, autoscaling per request, geïntegreerde beveiliging en telemetrie.
  - Nadelen: Uitvoeringstijd- en concurrency-limieten, ‘cold starts’, platformspecifieke beperkingen.
  - Gebruik voor ‘bursty’ workloads, mobiele/web-backends en eventverwerking.

Communicatiepatronen en Servicekeuze

Synchrone versus asynchrone aanroepen
- Synchroon
  - Gebruik voor request/response API’s die onmiddellijke resultaten vereisen.
  - Protocollen: gRPC (HTTP/2, streaming, compacte Protobuf; uitstekend voor mobiele bandbreedte en sterke contracten), HTTP/JSON (brede compatibiliteit; eenvoudiger debuggen).
  - Risico’s: Nauwe koppeling en latentieversterking; gebruik timeouts, retries met ‘jitter’ en ‘circuit breakers’.
- Asynchroon
  - Gebruik Pub/Sub of Cloud Tasks wanneer werk kan worden uitgesteld of gebundeld.
  - Voordelen: Vlakt pieken af, isoleert storingen, verbetert de door de gebruiker waargenomen latentie via uiteindelijke voltooiing.
  - Risico’s: Vereist idempotent gedrag en compenserende acties; inzicht in werk ‘in-flight’ moet worden ingebouwd.
Criteria voor servicekeuze op Google Cloud
- Controle en portabiliteit
  - Compute Engine: Volledige VM-controle en custom images; hogere operationele last.
  - GKE: Draagbare containers en service mesh-opties; robuuste autoscaling; gedeelde verantwoordelijkheid.
  - Cloud Run: Hoge portabiliteit voor containers met minimale operations; schalen-naar-nul; request-georiënteerd.
  - App Engine: Gedecideerde (opinionated) PaaS met ingebouwde routing en schaling; snelste pad voor bepaalde talen.
- Schaal en latentie
  - Global HTTP(S) Load Balancing met Cloud CDN voor ’edge acceleration’.
  - Datastores:
    - Cloud Spanner: Wereldwijde consistentie, horizontale schaal, multi-region 99,999% beschikbaarheid.
    - Cloud SQL: Beheerde relationele DB, regionaal, read replica’s inclusief cross-region.
    - Firestore: Document-DB met wereldwijde beschikbaarheid in multi-region, sterke consistentie voor afzonderlijke documenten.
    - Cloud Bigtable: Lage latentie, massale schaal voor ‘wide-column’ use cases.
    - Memorystore: Lage-latentie cache voor ‘hot paths’ en sessies.
- Operationele verantwoordelijkheid
  - Geef de voorkeur aan beheerde (managed) services voor kerntaken (beschikbaarheid, patchen, back-ups, upgrades).
  - Zelfbeheer biedt flexibiliteit maar voegt operationele last en een groter storingsvlak toe (bijv. zelf-gehoste Kafka versus Pub/Sub).
- Dataverplaatsing en -integratie
  - Gebruik VPC-native connectiviteit, Private Service Connect en internal HTTP(S) Load Balancing voor private toegang met lage latentie.
  - Service discovery: Kubernetes Service-namen binnen een cluster; Compute Engine interne DNS voor VM’s.

Kubernetes Service-voorbeeld (naamdetectie binnen het cluster):

undefined

Grenzen, Compatibiliteit en Betrouwbaarheidspatronen

Domeingrenzen en eigenaarschap
- Gebruik domain-driven design om ‘bounded contexts’ te definiëren. Elke service is eigenaar van zijn eigen data en publiceert API’s/events als contracten.
- Vermijd gedeelde databases tussen services; gebruik goed gedefinieerde interfaces en ’event propagation’.
- Eigenaarschap impliceert ‘on-call’-verantwoordelijkheid, SLO’s, een release-cadans en budgetverantwoording per service.
API-contracten en achterwaartse compatibiliteit
- Versioneer API’s expliciet (bijv. v1 in het pad of de header). Geef de voorkeur aan additieve wijzigingen; vermijd het breken van velden of gedrag.
- Gebruik ‘consumer-driven contract tests’ en ‘canary releases’. Kondig ‘deprecation’ aan met tijdlijnen en telemetrie over het gebruik.
- Voor mobiele clients, verwacht ’long tail’-versies; onderhoud meerdere API-versies tegelijkertijd.
Foutisolatie en veerkracht
- Bulkheads: Isoleer resources per service of prioriteitsklasse (aparte ’node pools’, ‘instance groups’, quota’s). Voorkom dat een ‘best-effort’-functie kritieke paden uithongert.
- Circuit breakers: Schakel uit na opeenvolgende fouten naar een afhankelijkheid; stoot belasting af (‘shed load’) en sta een herstelperiode toe. Implementeer via een ‘service mesh’ (bijv. Envoy), gateway-beleid of bibliotheken.
- Timeouts en retries: Gebruik ’truncated exponential backoff’ met ‘jitter’; zorg voor idempotente handlers.
- Graceful degradation: Laat niet-kritieke UI-componenten weg bij timeouts; serveer data uit de cache of benaderde data in plaats van fouten.
- Health checks en readiness probes: Stuur verkeer alleen naar ‘ready’ instances; gebruik ’liveness’ voor zelfherstel.

Voorbeeld van ’truncated exponential backoff’ (HTTP 429): retry = 0 max_retry = 5 base = 0.5 while retry < max_retry: resp = fetch_gcs_object() if resp.status_code == 200: break if resp.status_code in (429, 500, 503): sleep = min(8, base * (2 ** retry)) + random.uniform(0, 0.25) time.sleep(sleep) retry += 1 else: raise Exception(“Non-retryable error”)

Globale en Operationele Overwegingen

Multi-region patronen voor wereldwijde gebruikers
- Globale front-end: Gebruik globale externe HTTP(S) Load Balancing met anycast-IP en Cloud CDN voor statische content. Configureer negatieve caching en validatie om de belasting op de origin te verminderen.
- Datavlak:
  - Voor een databasebeschikbaarheid van ‘five nines’ en minimale wereldwijde leeslatentie, gebruik een multi-regionale Cloud Spanner-instance (bijv. nam-asia-eur1) en provisioneer voldoende nodes voor compute en quorum (minimaal drie nodes voor productie).
  - Voor leesintensieve patronen zonder strikte wereldwijde consistentie, overweeg een regionale primary met cross-region read replica’s; accepteer een hogere schrijflatentie tussen continenten.
- Applicatievlak:
  - Implementeer stateless services in meerdere regio’s met autoscaling (GKE of Cloud Run). Gebruik backend services en network endpoint groups per regio.
  - Routeer op basis van latentie, met inachtneming van dataresidentie- en compliance-eisen.
- Caches: Plaats Memorystore of edge-caches dicht bij gebruikers om leesverkeer op te vangen en origins te beschermen.
Beheerd versus zelfbeheerd
- Gebruik Cloud Monitoring voor metrics, Cloud Logging voor logs, Cloud Trace/Profiler voor latentie en CPU/geheugen-hotspots. Maak alerting policies voor SLO burn rates en uptime checks voor externe beschikbaarheid.
- Als een bestaand observability-platform het ‘system of record’ moet blijven, neem dan eerst data op met Cloud Logging voor lage-latentie alerts en exporteer vervolgens via sinks naar het externe platform.
Modernisering en incrementele migratie
- Strangler-patroon: Plaats een gateway voor de monolit; routeer specifieke endpoints naar nieuwe services. Vervang geleidelijk de functionaliteiten.
- Branch by abstraction: Introduceer een interface rond een afhankelijkheid en wissel de implementatie erachter uit (bijv. database of opslag).
- Anti-corruption layer: Vertaal tussen verouderde datamodellen en nieuwe ‘bounded contexts’.
- Datamigratie: Gebruik ‘dual writes’ met verificatie of ’event sourcing’ om data aan te vullen; plan ‘cutovers’ met ‘backpressure’-controles.
- Gefaseerde oplevering: Vervang features in fasen om bedrijfsrisico’s te minimaliseren; meet continu de SLO’s.
Ontwerpevaluaties en afwegingen
- Security: Threat model, IAM ’least privilege’, service accounts in plaats van ingebedde sleutels (gebruik Application Default Credentials op GCE/GKE/Cloud Run), CMEK waar vereist, private connectiviteit, WAF en rate limits, scannen op kwetsbaarheden en webbeveiliging.
- Betrouwbaarheid: Definieer SLO’s en error budgets, multi-region failover-plannen, capaciteitsmarge (‘headroom’), ‘chaos drills’, afhankelijkheidskaarten (‘dependency maps’).
- Prestaties: ‘Tail latency’-analyse, load testing aan de edge en de origin, hergebruik van verbindingen (HTTP/2, gRPC), compressie, cachingstrategie.
- Kosten: Juiste dimensionering (‘right-sizing’) van resources, autoscaling-beleid, ‘committed use discounts’, ‘scale-to-zero’ voor piekbelastingen, egress en CDN-offload.
- Operations: Runbooks, rollbacks, ‘progressive delivery’ (canary, blue/green), ‘policy as code’, back-ups en DR-tests, integratie van incidentrespons.

Praktisch Probleemscenario

Nimbus Retail lanceert een wereldwijd e-commerceplatform met gepersonaliseerde afbeeldingen, strikte latentiedoelen van minder dan 200 ms op p95 wereldwijd, en een beschikbaarheidseis van 99,999% voor de orderdatabase. Ze moeten ook hun bestaande SIEM behouden en tegelijkertijd de snelheid van de alarmering verbeteren.

Een wereldwijde, hoogbeschikbare database opzetten met Cloud Spanner

Actie: Maak een multi-regionale Spanner-instance aan in nam-asia-eur1 met minstens drie nodes en splits tabellen in geschikte ‘interleaved’ schema’s voor lokaliteit.
Reden: Multi-regionale Spanner levert ‘five nines’ en lage leeslatentie via replica’s op drie continenten; drie of meer nodes zorgen voor voldoende compute- en replica-quorumcapaciteit.

Voorbeeld: gcloud spanner instances create nimbus-orders
–config=nam-asia-eur1 –description=“Global orders” –nodes=3

Wereldwijde implementatie van frontend en API

Actie: Gebruik globale externe HTTP(S) Load Balancing met Cloud CDN voor statische assets en dynamische routering naar regionale backends (GKE-services in us-central1, europe-west1, asia-east1).
Reden: Anycast VIP minimaliseert RTT; CDN cachet afbeeldingen dicht bij gebruikers; backend services verdelen verzoeken naar de dichtstbijzijnde gezonde regio.

Stateless services op GKE met in-cluster discovery

Actie: Implementeer image-resize en API-services op GKE met horizontal pod autoscaling en ClusterIP Services voor naamgebaseerde toegang binnen het cluster; stel publieke endpoints beschikbaar via een Ingress.
Reden: Stateless pods maken elastische schaalvergroting mogelijk; Kubernetes Service abstraheert pod-IP’s en biedt stabiele DNS, wat de koppeling met de client vermindert.

Event-driven beeldverwerking

Actie: Publiceer beeldverwerkingstaken naar Pub/Sub; voer Cloud Run-services uit die via push geabonneerd zijn om objecten te verwerken die in Cloud Storage zijn opgeslagen. Implementeer ’truncated exponential backoff’ met jitter bij GCS 429/5xx-fouten.
Reden: Pub/Sub vangt pieken op en isoleert storingen; Cloud Run schaalt per bericht; ‘backoff’ vermindert foutversterking en helpt buckets geleidelijk op te warmen.

Observability en snelle alarmering

Actie: Gebruik Cloud Logging en Cloud Monitoring om logs en metrics op te nemen, definieer uptime checks voor API’s en maak alerting policies voor foutenpercentages en latentie. Configureer een log sink om te exporteren naar het bestaande SIEM.
Reden: Native telemetrie biedt lage-latentie alerts en beheerde uptime checks; export behoudt het gecentraliseerde SIEM zonder in te boeten aan alarmeringssnelheid.

Geëxternaliseerde configuratie en secrets

Actie: Sla niet-geheime configuratie op in ConfigMaps; secrets en API-sleutels in Secret Manager met Workload Identity voor GKE. Gebruik voor alle op Compute Engine gebaseerde jobs instance metadata voor per-deployment waarden.
Reden: Geëxternaliseerde configuratie maakt ‘immutable images’ en omgevingsspecifieke instellingen mogelijk; voorkomt het inbedden van secrets; metadata ondersteunt VM-variantie zonder codewijzigingen.

Foutisolatie en ‘graceful degradation’

Actie: Pas ‘bulkheads’ toe met afzonderlijke node pools voor ‘best-effort’ personalisatieworkloads; handhaaf ‘request budgets’ en ‘circuit breakers’ voor personalisatiediensten. Laat in de UI niet-kritieke widgets weg bij time-outs van afhankelijkheden.
Reden: Het isoleren van capaciteit voorkomt dat ‘best-effort’ features de checkout-flow verstoren; ‘circuit breakers’ beperken de ‘blast radius’; ‘graceful degradation’ waarborgt de kernprocessen.

API-contracten en compatibiliteit

Actie: Definieer gRPC-contracten voor mobiele clients (v1) met HTTP/JSON-transcodering voor web; pas additieve wijzigingen toe en onderhoud ten minste twee versies tijdens de mobiele uitrol.
Reden: gRPC vermindert bandbreedte en biedt sterke typering; transcodering vergemakkelijkt browser- en partnerintegratie; versioning waarborgt achterwaartse compatibiliteit.

Beveiliging en identiteit

Actie: Gebruik per-service Google service accounts met ’least-privilege’ IAM; vertrouw op Application Default Credentials. Schakel Cloud Armor in voor edge-bescherming en dwing overal TLS af.
Reden: Workload Identity elimineert de risico’s van sleutelbeheer; WAF en rate limits beperken misbruik; encryptie ‘in transit’ is standaard en verplicht.

Continuous delivery en veilige releases

Actie: Implementeer canary releases met procentuele verkeerssplitsing op de load balancer en automatische rollback bij SLO burn alerts. Houd blue/green-omgevingen per regio aan.
Reden: ‘Progressive delivery’ beperkt het risico; regionale blue/green versnelt rollback en maakt veilige schemamigraties mogelijk die zijn afgestemd op geversioneerde API’s.

Alle domeinen · Compute →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →