Jan Bakker: Waar ik warm van word.
door Jan Bakker, consultant bij Het ConsultancyHuis
Hoe vaak kun je als ontwikkelaar zelf je complete stack kiezen? Het team dat een offerte maakte voor Warmtenetwerk Westland kon dat. In deze blog wil ik kort iets vertellen over de gemaakte keuzes rond de infrastructuur en ontwikkelomgeving en met name over wat goed bleek te werken.
De gevraagde oplossing was een handelsplatform (“marktplaats”) voor het verkopen en inkopen van aardwarmte door kwekers in het Westland. Dit leent zich voor een webapplicatie die verschillende microservices aanspreekt. Gebruikte gegevens staan per service in een relationele of time series database.
Het ontwerp
Zelf ontwierp ik de infrastructuur. De klant had een voorkeur voor Microsoft Azure, wat fijn was omdat ik met deze cloud de meeste (en ook gunstige) ervaring had. Na getwijfeld te hebben over het gebruik van Azure web apps en function apps koos ik voor Kubernetes omdat dat veel flexibiliteit biedt. Dus bouwen we de applicaties en services als containers. Voor de data gebruiken we een Azure SQL elastic pool om meerdere databases in een bundel te kunnen draaien.
Vanuit dezelfde ervaring kozen we als team voor Azure DevOps als ontwikkelomgeving. Met Scrum boards voor het bijhouden van user stories en defects, met Git repositories en met pipelines voor automatisering van veel voorkomende taken. De opzet en syntax van de pipelines is soms wat eigenaardig maar als geheel werkt de omgeving stabiel. Het aantal keuzes voor het inrichten van de boards en de workflow is beperkt en dat is een voordeel.
Daarmee kom je dan dicht bij de Microsoft referentiearchitectuur voor microservices op AKS. Klik hier voor het origineel.
De praktijk
Nadat de opdracht gegund was heb ik een een aantal dagen op het team vooruitgewerkt om de infrastructuur zo snel mogelijk beschikbaar te hebben. Vanaf het begin wilde ik de infrastructuur als code opleveren. Dankzij de templatetaal Bicep en de Azure Devops pipelines ging dat relatief snel. Het is leerzaam om de gewenste componenten in een Azure portal GUI aan te maken, de configuratie als ARM template te exporteren en daar dan weer Bicep code van te maken. Een advies: Kies vanaf het begin een standaard voor naamgeving van componenten. Wees niet bang om desnoods de omgeving volledig af te breken en weer op te bouwen.
De ontwikkelaars konden vanaf dag één hun applicaties in Kubernetes deployen. Wat in de praktijk goed bleek te werken was iedere ontwikkelaar een eigen omgeving te geven, een Kubernetes namespace met een eigen set van databases voor de services. Daarnaast hadden we een staging omgeving voor (acceptatie) testen en demonstraties en een productie omgeving.
De ontwikkelaars ontwikkelden één service of app op hun laptop, die vervolgens met de database en of andere services in Kubernetes communiceerde. Ze gebruikten de tool Lens om een goed beeld te hebben wat er zich in Kubernetes afspeelde. Lens maakt ook zaken als port forwarding of het even in een container inloggen makkelijk.
Verdere ondersteuning voor de ontwikkelaars was per app of service een setje Azure Devops pipelines. We gebruikten:
- een build pipeline die checkt of het component goed gebouwd is (met unit testen en Sonar Cloud code analyse);
- een release pipeline die een versie maakt van de app/service, een container image en helm chart bouwt en installeert op de omgeving van de ontwikkelaar;
- een deploy pipeline die gebruikt kan worden om deze versie ook op andere namespaces te installeren.
Het fijne van deze pipelines is dat ze hun eigen documentatie vormen en dat ze het de ontwikkelaars gemakkelijk maken. De ontwikkelaars kunnen zich focussen op code schrijven i.p.v. repetitief allerlei commando’s te moeten intikken.
De toekomst
Mijn oorspronkelijke plannen voor de pipelines waren nog ambitieuzer (één omgeving per feature branch) maar één omgeving per ontwikkelaar bleek voldoende en lekker stabiel. Ook gebruiken we nog geen time series database. De time series data staat in een relationele database waarmee de technologie wat meer uniform is gehouden. Deze basis is ook bruikbaar voor projecten voor andere klanten. Voor de toekomst voorzie ik nog een Slack kanaal per omgeving waar de pipelines melden wat er aan versies is gedeployed, of de testen slagen. En wat meer ambitieus, een op OpenTelemetry gebaseerde visualisatie van het hele systeem.
De slotsom
Gebruikte tooling kan variëren, het gaat om de abstractie: Een Kubernetes als container platform, vanwege de namespaces die verschillende omgevingen mogelijk maken, waarbij we ook de relationele databases in die omgeving betrekken.
Een persoonlijke omgeving werkt fijn, maak het verder ook zo makkelijk mogelijk voor de ontwikkelaars: Een workflow met build, release, deploy en andere pipelines die het repetitieve werk automatiseren. En een uniforme inrichting en naamgeving van gebruikte componenten.
Misschien allemaal open deuren maar om te ervaren dat iets werkt zoals ooit bedoeld, is een magisch gevoel. Ik gun het iedereen.
Wil je hier meer van weten, mail me op jan.bakker@hetconsultancyhuis.nl
Gerelateerde nieuwsberichten
Samenwerken?
Een verandertraject, een nieuw IT-systeem of een andere uitdaging? Ontdek hier hoe we jouw organisatie kunnen helpen.
Werken bij ons?
Zoek je een nieuwe uitdaging? Ontdek de voordelen van Het ConsultancyHuis voor jou als consultant.
