"GitOps en Cloud Native CI/CD"
Automation

"GitOps en Cloud Native CI/CD"

Niels Goossens
Niels Goossens

KubeCon 2019

In een paneldiscussie met medewerkers van Cloudbees (het bedrijf achter Enterprise Jenkins) en Weaveworks (de bedenker van de term GitOps) wordt een beeld geschetst van wat GitOps precies is. Wat het kan betekenen voor bedrijven en organisaties en hoe bewustwording het beste kan plaats vinden. De discussie levert een groot aantal quotes op die de moeite zijn om te herhalen, dus die zijn in het onderstaand verhaal verweven.

"Operation by pull request”

GitOps is “operation by pull request”, maar er zit meer achter dan dat. Een uitgangspunt bij GitOp is “YAMLs are amazing”. De mening daarover is misschien meer verdeeld dan de panelleden willen doen geloven. Vooral bij Json, maar de gedachte dat er een declaratief formaat is waarin de configuratie van alles wordt vastgelegd, is wel een belangrijk uitgangspunt van GitOps. Of dat nu met YAML of JSON gebeurt. GitOps is dus ook “configuration as code”, oftewel “all workflows around how you handle and introduce change to your production systems.”

“GitOps is all about timing” - zegt de te laat arriverende CEO van Weaveworks. Het maakt niet alleen mogelijk de configuratie van alles rondom een cluster eenduidig op te slaan, maar ook bij te houden wie wanneer wat deed rondom de configuratie van dat cluster.

GitOps is randvoorwaardelijk in een wereld waarin de overstap wordt gemaakt van twee deployments per jaar naar meerdere per week. In die wereld is geen plek voor iemand die op magische wijze een paar commando’s uitvoert en een omgeving in de lucht houdt - “GitOps prevents heroism”.

Culturele impact

Voor een bedrijf dat of organisatie die zich de vraag stelt of GitOps er een plek heeft, betekent dit dat automatisering belangrijk is. Maar dat is niet alles overheersend. GitOps is een transactioneel systeem met patronen die nog steeds door mensen bestuurd worden. Het is belangrijk die automatisering te beteugelen. Waar mogelijk via mechanismen van toestemming die handmatig worden bediend. De belangrijkste reden hiervoor is dat automatisering een enorme culturele impact op organisaties en mensen heeft. Het is beter die verandering gelijkmatig te brengen.

Alles binnen GitOps bestaat uit code en om die reden meer democratisch. Configuratiecode heeft geen mening. En werken vanuit Git bevordert samenwerking en gelijkheid in teams. Iedereen werkt vanuit dezelfde uitgangspositie. Aandacht voor de teamleden is belangrijk. Iedere afzonderlijke medewerker moet begrijpen waarom met GitOps gewerkt wordt. En wat het belang daarvan is, ook voor de betreffende medewerker zelf.

“Change is a big impediment”. “People are hard”. Hoe code is opgezet, hoeveel repositories zijn ingericht (en hoe), er is altijd wel iemand die een andere mening heeft over hoe een tool ingericht wordt. “We are not doing it like that because it does not work” is een veel gehoord bezwaar tegen werken met GitOps.

Er vindt een verandering plaats

Een goede manier om tegen deze negativiteit in te gaan, zijn de voordelen van GitOps te laten zien. “Just do it and prove it when velocity is at stake”. De introductie van GitOps betekent dan wel dat bekendheid met de verschillende rollen binnen het ontwikkel- en beheerproces voldoende moet zijn. GitOps betekent niet hetzelfde voor de ontwikkelaar, projectmanager of beheerder.

In de IT vindt langzaam een verandering plaats. Van het stabiel houden van een traditioneel systeem, naar het op de rand van stabiliteit zo vaak en veel mogelijk uitrollen van functionaliteit. Gebruikers vinden reactiesnelheid belangrijker dan stabiliteit. Als een webpagina niet laadt dan wordt de pagina zonder al te veel problemen of gemopper gewoon nog een keer geladen.

Herstel van foutsituaties wordt een stuk eenvoudiger bij het gebruik van GitOps. Eigenlijk is het uitgangspunt steeds meer dat bijna alles dat fout kan gaan, ook wel een keer fout gaat. En dat is niet erg. Want de laatst werkende configuratie is in Git en daarmee is een cluster zo weer terug te zetten.

Wat als?

Er zijn nog wel wat vragen te beantwoorden. Bijvoorbeeld rondom de combinatie van verschillende soorten deployments. En wat te doen als er een orkestratie-fout plaats vindt? Als Jenkins uitvalt bijvoorbeeld. Maar: “It is hard to argue with a working prototype”.

Een opvallende afsluiter gaat over waar kennis over GitOps het beste te verkrijgen is. “Educate yourself, use Google”, is het antwoord. Er zijn weinig plekken om echt snel een introductie te krijgen en te beginnen. Behalve de verwachte verwijzingen naar de eigen websites van de sprekers. Is er toch nog een hero-cultuur overeind gebleven.