Werner

Als Platform Engineer ben ik lid van een (scrum)team van 9 man (1PO, 1SM, 7 Engineers) en verantwoordelijk voor de ECK clusters en Prometheus/Grafana. Diverse ECK clusters zijn er voor teams en daar leveren wij als team support op, zorgen ervoor dat het cluster goed blijft draaien en zorgen we voor nieuwe features. Daarnaast ook verantwoordelijk voor Prometheus/Grafana op alle Kubernetes clusters binnen TenneT.

Als DevOps engineer ben ik het enige lid van het Infrastructure team. Verantwoordelijk voor alles wat met de AWS-infrastructuur (VPC, EC2, IAM, RDS, Lambda) te maken heeft, volledig middels gitops. Enkele taken waar ik verantwoordelijk voor ben: • Elke maand het besturingssysteem van alle hosts updaten met nieuwere patches; • Elke andere wijziging in de AWS-infrastructuur of op de hosts op basis van functionele vereisten; • Assisteren van ontwikkelaars waar nodig;

Bij GVRN (Groot spanning) zal ik focussen op het verbeteren van enkele zaken op het CI/CD vlak. Het opbouwen van een generieke pipeline die door meerdere teams in deze release train gebruikt kan worden. Daarnaast diverse zaken uitzoeken waar teams onderling mee worstelen en het voorstellen/bouwen van generieke mogelijkheden. Ik ben geen onderdeel van 1 specifieke team, maar werk samen met de (solution) architect en met meerder teams.

Als DevOps ben ik lid van een (scrum)team van 11 man (1 PO, 1 SM, 5 DEV en 3 DevOps) dat zich toelegt op het automatiseren/verbeteren van verschillende taken voor de Smart Meter Headend applicatie landschap. De SMHE applicatie is verantwoordelijk voor alle communicatie tussen Alliander en de slimme meters (~4.5M) in het gebied waar Alliander zit. Ik ben verantwoordelijk voor het up2date houden van diverse AWS componenten (incl. Lambda’s) en de Kubernetes infrastructuur. Het installeren en updaten van de applicaties in Kubernetes, zoals Argo CD, Ingress Controller en Prometheus. Daarnaast ook standaard operations taken uitgevoerd zoals ontwikkelaars helpen met problemen, uitzoeken en oplossen van applicatie gerelateerde problemen en het uitvoeren van applicatie deployments. Verder werk verzet voor de migratie van Jenkins naar Github Actions. Daarnaast ook het process om (container) logfiles van Kubernetes worker nodes om dit in Elasticsearch te krijgen, door het toevoegen van Kafka voor tijdelijke opslag van events te verbeteren en betrouwbaarder te maken.

Als Technisch Applicatie beheerder was ik lid van een (scrum)team van 7 mensen (excl. PO) dat zich toelegt op het automatiseren/verbeteren van verschillende taken en het uitvoeren van bewerkingen voor de RWsOS- applicaties. Binnen het team hanteren we een volledige gitops mentaliteit. Ik was verantwoordelijk voor het uitvoeren van de basistaken, zoals het patchen van servers en het opnieuw opstarten ervan, of andere zaken die allemaal geautomatiseerd zijn middels Ansible-playbooks. Of (log)analyse van de RWsOS applicaties als onderdeel van het oplossen van issues. Merendeels van de applicaties draaien in 2 Kubernetes clusters, enkele applicaties op RHEL6/8 machine’s. Het automatiseren en verbeteren van kleine taken en veranderingen om de service van het team te verbeteren. Bijv. betere of meer monitoring items in Zabbix te configureren, of het introduceren van Grafana en Prometheus en daarbij het maken van plannen om daarnaar te migreren. Het schrijven van een specifieke Prometheus (Python) Exporter voor de FEWS applicatie om deze te kunnen monitoren met Prometheus. Het schrijven van extra (Python / BASH) scripts of Ansible playbooks voor het automatiseren van diverse taken. Het maken/updaten van HELM Charts voor de deployment van applicaties naar het Kubernetes cluster. Het opnieuw uitvoeren van de Argo CD-installatie voor de huidige Kubernetes-clusters waarop alle FEWS en alle ondersteunende applicaties zijn gedeployed. Ook veel wijzigingen/verbeteringen toegevoegd aan HELM Charts of nieuwe charts gemaakt.

Ik werd gevraagd om een beoordeling te doen van de ELK-installatie die ze gebruiken, omdat ze verschillende problemen ondervonden. Een eerste onderzoek doen naar de opzet, eisen opvragen van wat ze nodig hebben en een verbeterplan opstellen om de ELK-opstelling betrouwbaar en toekomstbestendig te maken. Na goedkeuring voor activiteiten, de voorgestelde verbeteringen succesvol geïmplementeerd.

Als DevOps engineer was ik de enige van het Infrastructure team. Verantwoordelijk voor alles wat met de AWS-infrastructuur (VPC, EKS, IAM, S3, Lambda) te maken heeft, volledig middels gitops. Enkele taken waar ik verantwoordelijk voor ben: • Het updaten van de Kubernetes-omgevingen; • Het updaten van andere AWS-gerelateerde componenten, zoals bijv. enkele Linux hosts; • Enkele kleine verbeteringen doorvoeren waar nodig, bijv. Monitoring, CI/CD pipeline of HELM Charts; Dit was voor een paar uur in een maand.

Als DevOps-engineer maakte ik deel uit van een klein (scrum)team (1 senior, 2 juniors) dat zich toelegde op het automatiseren van verschillende taken met behulp van Terraform en Ansible in AWS. Mijn rol bestond uit het bieden van ondersteuning aan ontwikkelaars en naar de 2 junior engineers. Ik was verantwoordelijk voor het ontwerpen, bouwen en onderhouden van monitoringomgevingen op dedicated "klant" VPC's. Deze omgevingen omvatten de ELK-stack (Opensearch, Logstash en Dashboard) voor de verzameling van de applicatie log (events), maar ook Prometheus en Grafana voor infra/applicatie metrics. Middels deze specifieke monitoring omgevingen konden we de klant omgeving monitoren en inzicht krijgen hoe deze functioneerde. Daarnaast heb ik een gecentraliseerd monitoring setup gemaakt met behulp van Zabbix voor beschikbaarheidsmonitoring, om te controleren dat alle klant omgevingen netjes draaien en Wazuh voor beveiligingsmonitoring voor o.a. audit events en andere systeem kritieke tooling. Verder nam ik de leiding over het ontwerpen en bouwen van een nieuwe Landing Zone-opstelling, gebruikmakend van VPC- , IAM- , EC2- , RDS- , Lambda en Route53 resources. De hele installatie was volledig geautomatiseerd met behulp van Terraform, Ansible en Jenkins. Deze implementatie was bedoeld om de beveiligingsmaatregelen te verbeteren en de levering van omgevingen in 2 – 3 uur te versnellen, in plaats van meerdere dagen. Verder verantwoordelijk voor wijzigingen/updates op de hosts of infrastructuur. Elke klant omgeving bestond uit o.a. MongoDB, Kafka, Vault. Daarnaast ook werk gezet (ook met Terraform/Ansible) om enkele klant omgevingen op Azure (i.p.v. AWS) te kunnen draaien. Daarnaast ook de (infrastructuur) architect voor verschillende projecten zoals de monitoring cluster(s) en het maken van de eerste set van ontwerpen voor Kubernetes Clusters in verschillende delen van de organisatie. Diverse demo’s gegeven voor o.a. Kubernetes en Argo CD om bedrijf/developers inzicht te geven wat mogelijkheden zijn voor toekomst. Het uitvoeren van wijzigingen aan machine’s middels Ansible. Het maken en verbeteren van Python scripts voor bijv. monitoring. Het primaire doel was om elk aspect van het proces/taak te automatiseren en alle code in GIT te hebben (gitops).

In het begin van het project resources in Azure aangemaakt middels Terraform vanuit Azure Devops. Daarbij ook voor aantal aanwezig applicaties de CI ingeregeld met Azure Devops. Daarna heb ik gewerkt aan een migratie en bouw van een AWS Landing Zone setup voor hun nieuwe cloud infrastructuur. Dit omvatte het ontwerpen en bouwen van de AWS Landing Zone, inclusief VPC- , IAM- , EKS- , Lambda en RDS-resources, met behulp van Infrastructure as Code-principes met zowel Terraform als HELM. Ook faciliteerde ik de deployment van (micro)services naar Kubernetes met behulp van Bitbucket Pipelines en Ansible. Het primaire doel was om elk aspect van het proces te automatiseren en alle code in GIT te hebben (gitops).

Ik ontwierp en bouwde een basis AWS Landing Zone-opstelling voor hun webapplicatie met behulp van Terraform. De opzet omvatte het draaien van de applicatie op EKS (Elastic Kubernetes Service) en RDS (Relational Database Service). Het primaire doel was om elk aspect van het proces te automatiseren en alle code in GIT te hebben (gitops). Daarnaast bood ik ondersteuning op hun CI/CD-platform, waardoor applicaties met behulp van HELM op de respectievelijke omgevingen konden worden geïmplementeerd. Daarnaast deelde ik mijn kennis van applicatie- en infrastructuurarchitectuur met de ontwikkelaars, wat waardevolle inzichten op dit gebied bood.