Dev + Ops
Vroeger bestonden Dev en Ops (Development en Operations). Dev schreef applicaties, gaf deze aan Ops om uit te rollen op de bedrijfsservers, vaak beheerd door dezelfde Ops. Soms werkten Dev en Ops samen op dezelfde server*, omdat de uitrol niet goed gedocumenteerd was én omdat tijd begon te dringen.
Managers dwongen Ops in deze samenlevingsvorm. Ops gaf developers met tegenzin toegang. Admin toegang natuurlijk, want met minder ging het allemaal niet vliegen. Niet alle ontwikkelaars vonden dit even leuk om te doen. Uiteindelijk moest een applicatie toch van ‘werkt op mijn machine’ terechtkomen in het domein van de eindgebruikers.
Ik heb mooie herinneringen aan die tijden. Het bracht Dev en Ops dichter bij elkaar en meestal was dit het begin van wederzijds begrip. Ops leerde de applicatie zien als meer dan ‘weer een stuk software’. Tegelijkertijd kreeg Dev inzicht in de uitdagingen van het beheren van applicaties in diverse omgevingen.
Het heeft mij geleerd dat een applicatie niet ‘klaar’ is totdat deze geïnstalleerd kan worden middels een geautomatiseerd en herhaalbaar proces. Het moet worden beveiligd, gemonitored en alle andere activiteiten die nodig zijn om een applicatie te beheren die in gebruik genomen is.
*Afhankelijk van de volwassenheid van de (IT) organisatie als geheel en van het specifieke team en/of de teamleden in het bijzonder.
Cloud-native applicaties
Snel doorspoelen naar het heden: vandaag de dag maken ontwikkelaars veel applicaties ‘cloud-native’.
Cloud-native architecture and technologies are an approach to designing, constructing, and operating workloads that are built in the cloud and take full advantage of the cloud computing model.
Wat is Cloud Native? | Microsoft Docs
Er zijn zeker andere opties dan cloud-native voor onze applicaties (meer daarover in een latere blog), maar laten we er voor nu vanuit gaan dat we er een gaan ontwikkelen. Misschien een mooi front-end ondersteund door een slimme backend of een database? Zoals bij elke applicatie, heeft deze een infrastructuur nodig om op te draaien; IaaS of PaaS. Dit is waar Dev en Ops elkaar weer tegenkomen.
Democratisering van infrastructuur
DevOps, Cloud... Hiermee wordt vaak cloud infrastructuur en CI/CD bedoeld, maar het is zoveel meer dan dat. DevOps is een gedachtegoed, geen functie. Moderne teams houden hieraan vast en laten mensen dingen doen die ze leuk vinden en waar ze goed in zijn. Coderen, pipelines, infrastructuur, applicaties, de grenzen vervagen. Met cloud en cloud-native applicaties moeten Dev en Ops samenwerken als nooit tevoren.
Moderne cloudomgevingen zijn meestal opgezet als ‘landing zone’ met ‘workloads’ die erin draaien.
“Een Azure landing zone is de uitvoer van een Azure-omgeving met meerdere abonnementen die is bedoeld voor schaalaanpassing, beveiligingsbeheer, netwerken en identiteit"
Wat is een Azure-landingszone? - Cloud Adoption Framework | Microsoft Docs
In een typische set-up zorgt het Ops team voor de landing zone met de infrastructuur erin, maar voor workloads (applicaties) raad ik ontwikkelaars aan om voor hun eigen infrastructuur te zorgen. Een andere component dan ‘traditionele’ cloud infrastructuur aanvragen bij Ops is niet logisch. Zeker wanneer PaaS-diensten toegepast worden in applicaties, zijn ontwikkelaars nu ook echt ‘cloud aan het doen’.
Dus, nadat Ops een landing zone heeft opgezet (gebruikmakend van iets als Terraform), zetten ze vaak de ook de infrastructuur als Code pipelines op voor de workloads. Ze voegen netwerken toe en andere belangrijke ‘gedeelde’ infrastructuur als Key Vaults, Log Analytics en opslag. Hierna krijgen de ontwikkelaars ‘Contributor’ permissies in de Dev-omgeving. Of eerder al, wanneer de landingszone nog niet helemaal klaar is ?.
Aan de slag!
Gebruik gewoon de Azure portal tijdens het experimenteren.
Wanneer je in deze omgeving bent (waarschijnlijk gewoon een of meer Resourcegroepen in Azure):
- Maak alle resources aan die je nodig hebt. Tip: voeg je de resources handmatig toevoegt, gebruik hier niet de naamgevingsconventie die je hebt afgesproken. Zo voorkom je conflicten als de er in dezelfde namen zijn gebruikt voor de infrastructuur.
- Ontwikkel de applicatie met deze resources. Maak, omdat het een cloud-native applicatie is, maximaal gebruik van het ‘cloud computing model’.
- Configureer je resources op de manier zoals je ze wilt gebruiken.
- Bekijk of je nog andere resources nodig hebt. Bijvoorbeeld een Service Bus in plaats van een Storage Queue, of andersom.
- Maak deze andere resources aan en pas de applicatie aan waar nodig. Tip: Verwijder alle resources die niet meer nodig zijn. Zo houd je omgeving netjes en voorkom onnodige kosten.
- Herhaal stap 2 t/m 5 indien nodig.
Pro-Tip: Als je als ontwikkelaar echt meters wilt maken raad ik je absoluut aan om Terraform (of Pulumi) te leren. Zelfs als je het vanaf je ontwikkelmachine rechtstreeks tegen de cloud aan gebruikt, helpt het echt om de relaties tussen resources en de juiste set-up te begrijpen. Het maakt je leven een stuk makkelijker als het verwijderen en opnieuw uitrollen van resources onderdeel van het werk is. Vergeet nooit hoe je telkens exact dezelfde resources neerzet met een gelijke configuratie, en dan nog snel ook!
En dan komt het moment dat je tevreden bent met de set-up. Nu is het tijd om vriendelijk aan je cloud infra collega te vragen om de resources in de IaC pipeline op te nemen. Ze kunnen de, door jou aangemaakte, resources bekijken of reverse engineering toepassen (of ze gebruiken de infrastructuur code die je voor jezelf had gemaakt) en de juiste naamgevingen toepassen. Ook zorg je ervoor dat meteen overal de juiste permissies en beveiliging wordt toegepast. Maak de resources veilig en conform alle richtlijnen.
Hierna kan de pipeline ook naar volgende omgevingen uitrollen, kan je experimentele resources in de Dev-omgeving laten vervangen door uitgerolde versies.
Het is een DevOps wereld
Deze manier van werken combineert maximale flexibiliteit met de voorspelbaarheid van Infrastructuur als Code. De impact van (kleine) aanpassingen tijdens het ontwikkelproces, waarvoor je anders terug zou moeten gaan naar cloud infra collega, wordt kleiner. In de afgelopen jaren ben ik zowel ontwikkelaar als cloud infra engineer geweest. Ik kan bevestigen dat het in beide rollen best prettig is om op deze manier te werken. Dev en Ops, samen gelukkig ?
Dev en Ops, best friends forever – Foto van Nadia Vasil’eva op Pexels.com
ps. Als bonus, probeer elke Virtuele Machine die nodig is als onderdeel van de oplossing als een container te beschouwen. Maak deze ‘stateless’ en integreer de virtual machines met bijvoorbeeld Key Vault en Application Insights. Met Packer kun je images maken die voor je servers kunnen worden gebruikt. Vraag Ops om een goed voorbereid ‘base’ image en begin vanaf daar.
DevOps of Cloud iets voor jou?
Bij Sogeti zoeken we enthousiastelingen die graag aan de slag gaan met DevOps of Cloud. Benieuwd? Lees direct meer verhalen van collega's of bekijk direct de vacatures.