Wat DevOps voor mij betekent

DevOps gaat voor mij niet alleen over pipelines, Docker of cloud-infrastructuur. Het gaat vooral over eigenaarschap over de volledige levenscyclus van software.

Software bouwen is één onderdeel. Je moet het ook betrouwbaar kunnen testen, deployen, monitoren en onderhouden. Daarbij wil ik zoveel mogelijk herhaalbaar en geautomatiseerd maken, zodat een team minder afhankelijk wordt van handmatige handelingen.

Ik zie DevOps daarom niet als iets dat pas begint nadat de code geschreven is. Het hoort vanaf het ontwerp onderdeel te zijn van de oplossing.

Belangrijke dingen om te weten

Een goede DevOps-aanpak draait voor mij vooral om een paar principes:

  • Automatiseer herhaalbaar werk. Een deployment die iedere keer dezelfde stappen nodig heeft, hoort uiteindelijk geen handmatig proces meer te zijn.

  • Maak deployments voorspelbaar. Een release moet zo normaal mogelijk voelen, niet als een spannend moment waarvoor het hele team beschikbaar moet zijn.

  • Development en productie moeten naar elkaar toe groeien. Docker helpt mij bijvoorbeeld om verschillen tussen omgevingen zoveel mogelijk te beperken.

  • Feedback moet snel beschikbaar zijn. Tests, code quality checks en deployment-resultaten moeten onderdeel zijn van de pipeline.

  • Beheer hoort bij engineering. Als je iets bouwt, moet je ook nadenken over hoe het zich in productie gedraagt.

Voor mij zit daar ook duurzaamheid in. Niet iedere infrastructuur hoeft maximaal uitgebreid te zijn. Ik kijk liever naar wat daadwerkelijk nodig is en probeer complexiteit en operationele kosten bewust laag te houden.

Hoe ik DevOps gebruik

Ik gebruik DevOps vooral om de afstand tussen ontwikkelen en daadwerkelijk draaien van software zo klein mogelijk te maken.

Daarbij werk ik onder andere met:

  • Docker voor reproduceerbare omgevingen

  • GitHub Actions en Jenkins voor CI/CD

  • AWS voor het draaien en integreren van backend-services

  • Kubernetes wanneer container orchestration daadwerkelijk nodig is

  • SonarQube en geautomatiseerde tests voor kwaliteitscontrole

  • Infrastructure as Code en configuratiebeheer om infrastructuur reproduceerbaar te maken

Bij microservices vind ik dit extra belangrijk. Zodra je meerdere services onafhankelijk wilt ontwikkelen en deployen, moet de manier waarop je dat doet gestructureerd zijn. Anders verplaats je de complexiteit van je applicatie simpelweg naar je infrastructuur.

Recente ervaring met DevOps

Bij ANWB werk ik binnen het Car Platform aan backend-services die op AWS draaien. Naast het ontwikkelen van de services kijk ik ook naar de omgeving waarin deze software uiteindelijk moet functioneren. Zo heb ik onder andere gewerkt aan de inrichting van Kong API Gateway en aan architectuur rondom Redis Streams en asynchrone processen.

Juist bij event-driven systemen vind ik die combinatie belangrijk. Een architectuur kan technisch goed ontworpen zijn, maar als deployments, configuratie, observability of foutafhandeling niet goed zijn ingericht, krijg je alsnog een systeem dat lastig te beheren is.

Mijn ervaring met DevOps komt daarnaast uit meerdere omgevingen. Bij Sogeti integreerde ik Java- en Quarkus-prototypes in GitHub Actions pipelines met automatische tests en artifactgeneratie. Bij Marvia werkte ik jarenlang met onder andere Docker, AWS-services en microservices binnen een SaaS-platform.

Mijn kijk op DevOps

Ik vind dat een developer niet alles van infrastructuur hoeft te weten, maar wel verantwoordelijkheid moet voelen voor wat er met zijn software gebeurt nadat deze gemerged is.

Een backend-service eindigt voor mij daarom niet bij een succesvolle unit test.

Ik wil weten:

  • Hoe wordt deze service gedeployed?

  • Wat gebeurt er wanneer een dependency uitvalt?

  • Hoe zien we dat er iets fout gaat?

  • Kunnen we veilig opnieuw deployen?

  • Hoe herstellen we van fouten?

  • Hoeveel operationele complexiteit voegen we toe?

Dat soort vragen maken software uiteindelijk robuuster.

Tegelijkertijd probeer ik DevOps bewust eenvoudig te houden. Niet ieder platform heeft Kubernetes, twintig pipelines en een volledig intern developer platform nodig. De infrastructuur moet de software ondersteunen, niet andersom.

Veelgestelde vragen die ik krijg over DevOps

Ben je developer of DevOps engineer?

Mijn specialisatie ligt in Backend Engineering. DevOps zie ik als onderdeel van mijn verantwoordelijkheid als engineer. Ik wil niet alleen software schrijven, maar ook begrijpen hoe die gebouwd, gedeployed en beheerd wordt.

Wanneer gebruik je Kubernetes?

Als de schaal, hoeveelheid services en operationele eisen daar daadwerkelijk om vragen. Voor kleinere omgevingen kan Docker met een eenvoudiger deploymentmodel vaak voldoende zijn. Complexiteit toevoegen omdat het technisch interessant is, vind ik geen goede reden.

Wat vind je het belangrijkste aan een CI/CD pipeline?

Dat hij vertrouwen geeft. Een pipeline moet automatisch controleren of software getest, gebouwd en veilig gedeployed kan worden. Hoe minder bijzondere handmatige stappen nodig zijn, hoe beter.

Hoe kijk je naar DevOps binnen microservices?

Daar wordt het wat mij betreft essentieel. Meer services betekent meer deployments, configuratie, communicatie en mogelijke fouten. Goede automatisering voorkomt dat die operationele complexiteit het team uiteindelijk vertraagt.

Wanneer is DevOps goed ingericht?

Wanneer deployments normaal worden. Als een team zonder spanning meerdere keren per dag software kan testen en releasen, fouten snel zichtbaar zijn en herstel voorspelbaar is, dan doet de DevOps-aanpak wat hij hoort te doen.