

CloudBrew is altijd een hoogtepunt op onze kalender geweest, maar de editie van 2025 voelde anders. Misschien lag het aan de timing. Slechts een maand eerder, in november 2025, opende de Azure Belgium Central-regio eindelijk haar deuren. ACA opereert al altijd vanuit het hart van Europa, dus het live gaan van deze grote nationale mijlpaal net voor de conferentie zorgde voor een extra dosis enthousiasme.
We zijn blij om te zien dat photobombing nog steeds een dings is in 2025 😉.
Het was dan ook passend dat onze partners van Microsoft, Wouter Gevaert en Jan Gezels, de aftrap gaven na de eerste keynote.
Azure Belgium Central en het cloud-native pad

De openingssessie was niet zomaar een overwinningsrondje voor het nieuwe datacenter. Het was een technische roadmap. Hoewel Azure Belgium Central (ABC) open is voor gebruik, gebeurt er achter de schermen nog veel werk om continu meer Azure-diensten beschikbaar te maken.
De grootste verandering zit in hoe we naar betrouwbaarheid kijken. We stappen af van het oude model met gepaarde regio’s en zetten volop in op moderne multi-region High Availability en Disaster Recovery Planning. Met meerdere Availability Zones nu dichtbij kunnen we eindelijk echte lokale dataresidentie aanbieden aan compliance-gevoelige klanten, zonder in te boeten op fouttolerantie.
- De belangrijkste inzichten?
Beschikbaarheid correct controleren: Er is momenteel maar één betrouwbare manier om te zien welke diensten beschikbaar zijn in de ABC-regio: de Azure Pricing Calculator. Gebruik deze tool boven alle andere om beschikbaarheid te verifiëren. - Latency en interconnectiviteit: De ABC-regio heeft een van de laagste latencyverbindingen met Europe-West (Amsterdam). Resources en workloads koppelen met die regio is geen probleem op vlak van latency.
- Omgaan met ontbrekende diensten: Diensten zoals Azure Databricks en Microsoft Fabric zijn nog niet beschikbaar in ABC. Technisch is dit wel beheersbaar. Je kan je primaire workload in ABC uitrollen en op netwerkniveau koppelen met Databricks- of Fabric-instances in een andere regio.

Gezonde apps, gelukkige gebruikers: slimmere monitoring met Azure Health Models
Met de infrastructuurbasis gelegd, trokken we naar de sessie van Massimo Crippa: “Healthy apps, happy users: smarter monitoring with Azure Health Models”.
Massimo legde de toekomst van monitoring uitstekend uit. We weten allemaal hoe moeilijk het is om monitoring alerts goed te configureren. Je moet voortdurend balanceren tussen welke alerts je instelt en welke drempelwaarden je gebruikt.
- Te laag: een alert triggeren bij 70 procent CPU-gebruik veroorzaakt vaak een stortvloed aan meldingen. Dat leidt tot alert fatigue en vergroot het risico dat kritieke issues gemist worden.
- Te hoog: ligt de drempel te hoog, dan is de omgeving vaak al aangetast tegen de tijd dat je een melding krijgt.
Daarnaast heeft traditionele alerting twee grote tekortkomingen:
- De stortvloed: Als één Azure-resource faalt, wordt je ticketsysteem meestal overspoeld met meerdere alerts voor dezelfde oorzaak, zoals beschikbaarheid, latency en CPU.
- Valse criticals: Niet-kritieke alerts worden vaak als kritisch gemarkeerd. Als bijvoorbeeld één node achter een load balancer uitvalt maar de andere nodes het verkeer opvangen, is de gebruikerservaring niet aangetast, maar de alert roept toch “Critical”.
Azure Health Models is geen wondermiddel, maar wel een grote stap vooruit. Het belangrijkste inzicht is dat alerts worden gebundeld op basis van het systeem. Als een App Service een CPU-piek heeft, krijg je één geconsolideerde alert in plaats van een stroom aan symptomen.
Daarnaast kan je onderscheid maken tussen “Critical” (impact op de gebruiker) en “Degraded” (backendprobleem zonder gebruikersimpact).
Samengevat bieden Azure Health Models deze voordelen:
- Het samenbrengen van zakelijke en technische perspectieven in één health model
- Snelle detectie van de algemene gezondheidstoestand van een systeem
- Het wegwerken van alert fatigue
Vibecoding: van coder naar operator
We beloven dat we deze blogpost niet hebben “vibewritten”, maar we hebben wel enorm genoten van de sessie van Sakari Nahi: “Let’s vibecode something.”
Dit was misschien wel de meest toekomstgerichte talk van het event. Sakari belichtte een strategische verschuiving die velen van ons al voelen: AI verandert de rol van de engineer van pure code-schrijver naar “operator van AI”.
De hele sessie was een live demonstratie van hoe je jezelf via vibecoding naar een volledig werkende multiplayer game kan brengen.

We leerden hoe je OpenSpec kan inzetten en waarom dit zo krachtig is. Kort samengevat is het een gespecialiseerde development toolkit voor AI-ondersteund coderen. Het focust op Spec-Driven Development, een workflow waarbij je eerst duidelijk definieert wat je wil, voordat een AI-agent zoals Claude of Cursor probeert code te schrijven.
Waarom is OpenSpec zo krachtig?
- Eén bron van waarheid: AI-agents hallucineren vaak of missen vereisten wanneer instructies verstopt zitten in een lange chatgeschiedenis. OpenSpec dwingt een “Source of Truth”-bestand af dat de AI moet volgen, wat fouten en “luie” code vermindert.
- Ideaal voor bestaande code: In tegenstelling tot sommige AI-starterkits die enkel werken voor nieuwe projecten, is OpenSpec ontworpen om wijzigingen in bestaande complexe codebases te beheren. Het volgt veranderingen in plaats van volledige bestanden opnieuw te genereren.
- Agent-agnostisch: Het is geen op zichzelf staande AI, maar een protocol. Je kan het gebruiken met Cursor, Claude Code, GitHub Copilot of eender welke LLM die bestanden kan lezen. Er zijn geen eigen API-sleutels nodig.
We weten allemaal dat AI soms onvoorspelbaar kan zijn. Hoewel de multiplayer game aan het einde van de sessie niet volledig werkte, waren we geïnspireerd.
Zo geïnspireerd zelfs dat we diezelfde avond bij ons thuis Antigravity van Google opstartten. We volgden de principes van OpenSpec en wat we overdag hadden geleerd.
Met verwondering zagen we hoe Antigravity met enkele prompts en iteraties een volledige top-down space shooter creëerde. In vijftien minuten hadden we een lokale space invaders game, met graphics, levels, highscores en alle toeters en bellen.
Dat is de kracht van OpenSpec en vibecoding.
Dag twee: de governance reality check
Als dag één over de toekomst ging, draaide dag twee om de concrete realiteit van alles beheren.
We begonnen met een prikkelende titel: “Azure Tags are Dead. Meet Their Weird Cousin: Service Groups”, door Stijn Depril en Tim Verbist.
Eerlijk is eerlijk, Azure tagging moest orde brengen in de chaos. In de praktijk zorgen inconsistente, ontbrekende of niet-afgedwongen tags er vaak voor dat FinOps een nachtmerrie wordt. Stijn en Tim introduceerden Service Groups als de ontbrekende schakel.
De live demo was een echte eyeopener en toonde hoe Service Groups kosteninzicht en verantwoordelijkheid kunnen bieden waar traditionele tagging steeds tekortschiet. Je kan dit zien als een virtuele container die Azure-resources van overal binnen de tenant kan bevatten, over verschillende subscriptions heen.
Dit laat toe dat verschillende teams binnen je organisatie een ander overzicht krijgen. Zo kan een Product Owner één Service Group hebben met alle resources voor een specifieke applicatie, ongeacht of die zich in een productie- of ontwikkelsubscription bevinden.

Hoewel Service Groups nog in preview zijn, suggereerde de sessie dat ze op termijn tags zouden kunnen vervangen, en misschien zelfs Management Groups als primaire manier om policies toe te wijzen en resources te groeperen. Bij ACA zijn we nog niet overtuigd dat ze alles zullen vervangen, maar het potentieel is onmiskenbaar.
Level up security
De namiddag nam een interessante wending met de sessie van Roland Guijt: “Level Up Your Security: OpenID Connect/OAuth update”.
Met de release van OAuth 2.1 lichtte Roland drie belangrijke protocolverbeteringen toe:
- PKCE vereist voor authorization code flow
- Dit werkt als een bijpassend digitaal ticketstubje. Het zorgt ervoor dat de app die je login start ook dezelfde is die hem afrondt, waardoor het bijna onmogelijk wordt voor een hacker om het proces onderweg te onderscheppen.
- Implicit en resource owner password grant geschrapt
- Verouderde loginmethodes die apps toelieten je echte wachtwoord te zien of makkelijk te misleiden waren, worden uitgefaseerd. Hierdoor komen apps nooit rechtstreeks in aanraking met je credentials, wat je beschermt tegen datalekken en phishing.
- Refresh tokens voor public clients moeten sender-constrained zijn of eenmalig gebruikt worden
- Dit zet als het ware een zelfvernietigingsmechanisme of slot op de digitale sleutels die je ingelogd houden. Als een aanvaller zo’n sleutel zou stelen, kan die er niets mee aanvangen omdat hij ongeldig is of meteen vervalt.

Conclusie: volle vaart richting 2026
CloudBrew 2025 zit erop en liet ons achter met heel wat om over na te denken en mee aan de slag te gaan.
Met Azure Belgium Central officieel open is datasoevereiniteit geen modewoord meer, maar een basisvereiste. Security is verplicht, AI wordt geïntegreerd in alle workflows en governance krijgt eindelijk de tools die het nodig heeft.
Samen met onze klanten en partners is ACA klaar om deze inzichten om te zetten in actie. Tegen de tijd dat CloudBrew 2026 eraan komt, verwachten we dat het landschap opnieuw veranderd zal zijn, en wij zullen er klaar voor zijn.
Tot de volgende keer!

What others have also read


Een betere uptime, lagere kosten en vendor lock-in vermijden. Dat zijn drie van de redenen waarom onze klanten kiezen voor een multicloud-strategie. Onze Cloud project manager Roel Van Steenberghe legt uit wat zo’n strategie precies inhoudt en wat de troeven zijn van Google Cloud Platform (GCP).
Lees verder

In de complexe wereld van moderne softwareontwikkeling worden bedrijven geconfronteerd met de uitdaging om verschillende applicaties die door verschillende teams worden ontwikkeld en beheerd, naadloos te integreren. De Service Mesh is van onschatbare waarde bij het overwinnen van deze uitdaging. In dit blogartikel verdiepen we ons in Istio Service Mesh en onderzoeken we waarom investeren in een Service Mesh zoals Istio een slimme zet is." Wat is Service Mesh? Een Service Mesh is een softwarelaag die verantwoordelijk is voor alle communicatie tussen applicaties, in deze context services genoemd. Het introduceert nieuwe functionaliteiten om de interactie tussen services te beheren, zoals monitoring, logging, tracing en verkeerscontrole. Een service mesh werkt onafhankelijk van de code van elke individuele service, waardoor het over netwerkgrenzen heen kan werken en kan samenwerken met verschillende beheersystemen. Dankzij een service mesh kunnen ontwikkelaars zich richten op het bouwen van toepassingsfuncties zonder zich zorgen te maken over de complexiteit van de onderliggende communicatie-infrastructuur. Istio Service Mesh in de praktijk Denk aan het beheren van een groot cluster waarop meerdere applicaties draaien die ontwikkeld en onderhouden worden door verschillende teams, elk met verschillende afhankelijkheden zoals ElasticSearch of Kafka. Na verloop van tijd resulteert dit in een complex ecosysteem van applicaties en containers, overzien door verschillende teams. De omgeving wordt zo ingewikkeld dat het voor beheerders steeds moeilijker wordt om het overzicht te bewaren. Dit leidt tot een reeks pertinente vragen: Hoe ziet de architectuur eruit? Welke applicaties interageren met elkaar? Hoe wordt het verkeer beheerd? Bovendien zijn er specifieke uitdagingen die voor elke afzonderlijke applicatie moeten worden aangepakt: Het afhandelen van aanmeldingsprocessen Implementeren van robuuste beveiligingsmaatregelen Netwerkverkeer beheren dat naar de applicatie wordt geleid ... Een Service Mesh, zoals Istio, biedt een oplossing voor deze uitdagingen. Istio fungeert als een proxy tussen de verschillende applicaties (services) in het cluster, waarbij elk verzoek door een component van Istio gaat. Hoe werkt Istio Service Mesh? Istio introduceert een sidecar proxy voor elke service in het microservices ecosysteem. Deze sidecar proxy beheert al het inkomende en uitgaande verkeer voor de dienst. Daarnaast voegt Istio componenten toe die het inkomende en uitgaande verkeer van het cluster afhandelen. Istio's control plane maakt het mogelijk om beleidsregels te definiëren voor verkeersbeheer, beveiliging en monitoring, die vervolgens worden toegepast op de toegevoegde componenten. Voor een beter begrip van de functionaliteit van Istio Service Mesh, zie ons blogartikel "Istio Service Mesh installeren: A Comprehensive Step-by-Step Guide" , een gedetailleerde, stapsgewijze uitleg over de installatie en het gebruik van Istio. Waarom Istio Service Mesh? Verkeersbeheer: Istio maakt gedetailleerd verkeersbeheer mogelijk, waardoor ontwikkelaars eenvoudig verkeer tussen verschillende versies van hun services kunnen routeren, verdelen en controleren. Beveiliging: Istio biedt een robuuste beveiligingslaag met functies zoals verkeersversleuteling met behulp van eigen certificaten, Role-Based Access Control (RBAC) en mogelijkheden voor het implementeren van authenticatie- en autorisatiebeleid. Waarneembaarheid: Door middel van ingebouwde instrumentatie biedt Istio diepgaande observeerbaarheid met tools voor monitoring, logging en gedistribueerde tracering. Hierdoor kunnen IT-teams de prestaties van services analyseren en snel problemen opsporen. Vereenvoudigde communicatie: Istio neemt de complexiteit van servicecommunicatie weg van applicatieontwikkelaars, zodat zij zich kunnen richten op het bouwen van applicatiefuncties. Is Istio geschikt voor uw opstelling? Hoewel de voordelen duidelijk zijn, is het essentieel om te overwegen of de extra complexiteit van Istio past bij jouw specifieke opstelling. Ten eerste is er een sidecar container nodig voor elke ingezette service, wat kan leiden tot ongewenste geheugen- en CPU overhead. Daarnaast kan het zijn dat je team niet beschikt over de specialistische kennis die nodig is voor Istio. Als je overweegt om Istio Service Mesh te gaan gebruiken, vraag dan begeleiding aan specialisten met expertise. Vraag onze experts gerust om hulp. Meer informatie over Istio Istio Service Mesh is een technologische game-changer voor IT-professionals die streven naar geavanceerde controle, beveiliging en observeerbaarheid in hun microservices-architectuur. Istio vereenvoudigt en beveiligt de communicatie tussen services, waardoor IT-teams zich kunnen richten op het bouwen van betrouwbare en schaalbare applicaties. Snel antwoord nodig op al uw vragen over Istio Service Mesh? Neem contact op met onze experts
Lees verder

Bent u dit jaar niet op KubeCon geweest? Lees dan mee voor onze hoogtepunten van de KubeCon / CloudNativeCon-conferentie van dit jaar door het Cloud Native-team van ACA Group! Wat is KubeCon / CloudNativeCon? KubeCon (Kubernetes Conference) / CloudNativeCon , jaarlijks georganiseerd op EMAE door de Cloud Native Computing Foundation (CNCF), is een vlaggenschipconferentie die adopters en technologen van toonaangevende open source en cloud native gemeenschappen op één locatie samenbrengt. Dit jaar kwamen ongeveer 5.000 fysieke en 10.000 virtuele deelnemers opdagen voor de conferentie. CNCF is de open source, leverancier-neutrale hub van cloud native computing, die projecten zoals Kubernetes en Prometheus host om cloud native universeel en duurzaam te maken. Er waren meer dan 300 sessies van partners, industrieleiders, gebruikers en leveranciers over onderwerpen als CI/CD, GitOps, Kubernetes, machine learning, observeerbaarheid, netwerken, prestaties, service mesh en beveiliging. Het is duidelijk dat er altijd iets interessants te horen is op KubeCon, ongeacht je interessegebied of expertiseniveau! Het is duidelijk dat het Cloud Native ecosysteem is uitgegroeid tot een volwassen, trendsettende en revolutionaire game-changer in de industrie. Alles staat in het teken van de Kubernetes-trend en een enorme hoeveelheid organisaties die cloud native producten ondersteunen, gebruiken en hun bedrijf hebben laten groeien door ze te bouwen of te gebruiken in bedrijfskritische oplossingen. De belangrijkste thema's van 2022 Wat ons opviel tijdens KubeCon dit jaar waren de volgende hoofdthema's: De eerste was toenemende volwassenheid en stabilisatie van Kubernetes en bijbehorende producten voor monitoring, CI/CD, GitOps, operators, costing en service meshes, plus bug fixing en kleine verbeteringen. De tweede is een meer uitgebreide focus op beveiliging . Het veiliger maken van pods, het voorkomen van pod trampoline breakouts, end-to-end encryptie en het maken van volledige analyses van bedreigingen voor een complete k8s bedrijfsinfrastructuur. De derde is duurzaamheid en een groeiend bewustzijn dat systemen waarop k8s en de apps erop draaien veel energie verbruiken terwijl 60 tot 80% van de CPU ongebruikt blijft. Zelfs talen kunnen energie(on)efficiënt zijn. Java is een van de meest energie-efficiënte talen, terwijl Python dat blijkbaar veel minder is door de aard van de interpreter/compiler. Bedrijven moeten allemaal plannen maken en werken aan het verminderen van de energievoetafdruk in zowel applicaties als infrastructuur. Autoscaling zal hierbij een belangrijke rol spelen. Hoogtepunten van de sessies Duurzaamheid Datacenters verbruiken wereldwijd 8% van alle opgewekte elektriciteit. We moeten dus nadenken over het effectieve gebruik van onze infrastructuur en inactieve tijd vermijden (gemiddeld is het CPU-gebruik slechts tussen 20 en 40%) als servers draaien, laat ze dan werken met zoveel mogelijk werklasten resources afsluiten wanneer ze niet nodig zijn door het toepassen van autoscaling benaderingen de coderingstechnologie die gebruikt wordt in je software, sommige programmeertalen gebruiken minder CPU. CICD / GitOps GitOps automatiseert infrastructuur updates met behulp van een Git workflow met continue integratie (CI) en continue levering (CI/CD). Wanneer nieuwe code wordt samengevoegd, voert de CI/CD pijplijn de verandering door in de omgeving. Flux is hier een goed voorbeeld van. Flux biedt GitOps voor zowel apps als infrastructuur. Het ondersteunt GitRepository, HelmRepository en Bucket CRD als de enige bron van waarheid. Met A/B- of Canary-implementaties is het eenvoudig om nieuwe functies te implementeren zonder dat dit gevolgen heeft voor alle gebruikers. Als de implementatie mislukt, kan deze eenvoudig worden teruggedraaid. Bekijk het schema van KubeCon voor meer informatie! Kubernetes Hoewel Kubernetes 1.24 een paar weken voor de start van het evenement werd uitgebracht, waren er niet veel gesprekken gericht op de kern van Kubernetes. De meeste gesprekken waren gericht op het uitbreiden van Kubernetes (met behulp van API's, controllers, operators, ...) of best practices rond beveiliging, CI/CD, monitoring ... voor wat er ook draait binnen het Kubernetes-cluster. Als je geïnteresseerd bent in de nieuwe functies die Kubernetes 1.24 te bieden heeft, kun je de officiële website bekijken . Waarneembaarheid Inzicht krijgen in hoe je applicatie draait in je cluster is cruciaal, maar niet altijd even praktisch. Dit is waar eBPF om de hoek komt kijken, dat wordt gebruikt door tools zoals Pixie om gegevens te verzamelen zonder codewijzigingen. Bekijk het schema van KubeCon voor meer informatie! FinOps Nu steeds meer mensen Kubernetes gebruiken, zijn er veel workloads gemigreerd. Al deze containers hebben een voetafdruk. Geheugen, CPU, opslag, ... moeten worden toegewezen, en ze hebben allemaal een kostprijs. Kostenbeheer was een terugkerend onderwerp tijdens de gesprekken. Het gebruik van autoscaling (capaciteit toevoegen maar ook verwijderen) om de benodigde resources aan te passen en het identificeren van ongebruikte resources maken deel uit van deze nieuwe beweging. Nieuwe diensten zoals 'kubecost' worden steeds populairder. Prestaties Een van de meest voorkomende problemen in een cluster is niet genoeg ruimte of resources hebben. Met behulp van een Vertical Pod Autoscaler (VPA) kan dit tot het verleden behoren. Een VPA analyseert en slaat geheugen- en CPU-metriek/gegevens op om zich automatisch aan te passen aan de juiste CPU- en geheugenlimieten. De voordelen van deze aanpak laten je geld besparen, verspilling voorkomen, de onderliggende hardware optimaal dimensioneren, resources op worker nodes afstemmen en de plaatsing van pods in een Kubernetes cluster optimaliseren. Bekijk het schema van KubeCon voor meer informatie! Servicemesh We weten allemaal dat het heel belangrijk is om te weten welke applicatie data deelt met andere applicaties in je cluster. Service mesh biedt verkeerscontrole binnen uw cluster(s). Je kunt elk verzoek dat wordt verzonden of ontvangen van een applicatie naar andere applicaties blokkeren of toestaan. Het biedt ook Metrics, Specs, Split, ... informatie om de gegevensstroom te begrijpen. In de lezing Service Mesh op schaal: Hoe Xbox Cloud Gaming 22k Pods beveiligt met Linkerd , legt Chris uit waarom ze voor Linkerd hebben gekozen en wat de voordelen zijn van een service mesh. Bekijk het schema van KubeCon voor meer informatie! Beveiliging Trampoline pods, klinkt leuk, toch? Tijdens een lezing van twee beveiligingsonderzoekers van Palo Alto Networks leerden we dat ze niet zo leuk zijn. Kort gezegd zijn dit pods die gebruikt kunnen worden om cluster admin privileges te krijgen. Om meer te leren over het concept en hoe ermee om te gaan, raden we je aan om de slides op de KubeCon schedule pagina te bekijken! Lachlan Evenson van Microsoft gaf een duidelijke uitleg over Pod Security in zijn The Hitchhiker's Guide to Pod Security talk. Pod Security is een ingebouwde toelatingscontroleur die Pod-specificaties evalueert aan de hand van een vooraf gedefinieerde set Pod Security-standaarden en bepaalt of de pod moet worden toegelaten of geweigerd. - Lachlan Evenson , Programmamanager bij Microsoft . Pod Security vervangt PodSecurityPolicy vanaf Kubernetes 1.23. Dus als je PodSecurityPolicy gebruikt, is dit misschien een goed moment om Pod Security en het migratiepad verder te onderzoeken. In versie 1.25 wordt de ondersteuning voor PodSecurityPolicy verwijderd. Als je PodSecurityPolicy of Pod Security niet gebruikt, is het zeker tijd om het verder te onderzoeken! Een ander terugkerend thema van deze KubeCon 2022 waren operators. Operators maken het mogelijk om de Kubernetes API uit te breiden met operationele kennis. Dit wordt bereikt door Kubernetes-controllers te combineren met bekeken objecten die de gewenste toestand beschrijven. Ze introduceren Custom Resource Definitions, custom controllers, Kubernetes of cloud resources en logging en metrics, wat het leven makkelijker maakt voor zowel Dev als Ops. Tijdens een lezing van Kevin Ward van ControlPlane leerden we echter dat er ook risico's aan verbonden zijn. Bovendien, en dat is nog belangrijker, vertelde hij ook hoe we die risico's kunnen identificeren met tools zoals BadRobot en een operator thread matrix . Bekijk de KubeCon roosterpagina voor meer informatie! Planning Telemetry Aware Scheduling helpt u om uw workloads te plannen op basis van de statistieken van uw worker nodes. U kunt bijvoorbeeld een regel instellen om geen nieuwe werklasten te plannen op worker nodes met meer dan 90% gebruikt geheugen. Het cluster zal hier rekening mee houden bij het plannen van een pod. Een andere leuke functie van deze tool is dat het ook pods opnieuw kan inplannen om ervoor te zorgen dat uw regels in lijn blijven. Bekijk de KubeCon planningspagina voor meer informatie! Cluster autoscaling Een geweldige manier voor stateless workloads om kosteneffectief te schalen is het gebruik van AWS EC2 Spot, wat reserve VM-capaciteit is die met korting beschikbaar is. Om Spot-instanties effectief te gebruiken in een K8S cluster, moet je aws-node-termination-handler gebruiken. Op deze manier kun je je werklasten van een worker node verplaatsen wanneer Spot besluit deze terug te vorderen. Een ander goed hulpmiddel is Karpenter , een hulpmiddel om Spot-instanties precies op tijd te leveren voor je cluster. Met deze twee tools kun je je stateless workloads kosteneffectief hosten! Bekijk de KubeCon schedule pagina voor meer informatie! Event-gedreven autoscaling Het gebruik van de Horizontal Pod Autoscaler (HPA) is een geweldige manier om pods te schalen op basis van statistieken zoals CPU-gebruik, geheugengebruik en meer. In plaats van te schalen op basis van statistieken, kan Kubernetes Event Driven Autoscaling (KEDA) schalen op basis van gebeurtenissen (Apache Kafka, RabbitMQ, AWS SQS, ...) en het kan zelfs schalen tot 0 in tegenstelling tot HPA. Bekijk het schema van KubeCon voor meer informatie! Wrap-up We hebben dit jaar genoten van de conferentie. We vertrokken met een geïnspireerd gevoel dat we ongetwijfeld zullen vertalen naar interne projecten, nieuwe klantprojecten zullen aanvragen en waar van toepassing zullen bespreken met bestaande klanten. Niet alleen dat, maar we zullen ook onze collega's informeren en een afterglow sessie organiseren voor de geïnteresseerden thuis in België. Als je ons blogartikel leuk vond, stuur ons dan gerust een berichtje. We zijn altijd blij als de inhoud die we publiceren ook voor jou waardevol of interessant is. Als je denkt dat we jou of je bedrijf kunnen helpen bij de adoptie van Cloud Native, stuur me dan een berichtje op peter.jans@aca-it.be. Als laatste willen we Mona bedanken voor de logistiek, Stijn en Ronny voor deze kans en de rest van het team dat achterbleef om de systemen van onze gewaardeerde klanten in de gaten te houden.
Lees verderBenieuwd hoe we je kunnen helpen meer uit je cloudoplossingen te halen?

Benieuwd hoe we je kunnen helpen meer uit je cloudoplossingen te halen?

Benieuwd hoe we je kunnen helpen meer uit je cloudoplossingen te halen?

Benieuwd hoe we je kunnen helpen meer uit je cloudoplossingen te halen?



