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 bewustworing het beste kan plaatsvonden. De discussie levert een groot aantal quotes op die de moeite zijn om te herhalen, dus die zijn in het onderstaande verhaal verweven.
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 2 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”.
Voor een bedrijf dat of organisatie die zich de vraag stelt of GitOps er een plek heeft, betekent dit dat automatisering belangrijk is, maar niet allesoverheersend. GitOps is een transactioneel systeem met patronen die nog steeds door mensen worden bestuurd. Het is belangrijk die automatisering te beteugelen, waar mogelijk: via mechanismen van toestemming, die handmatig worden bediend, bijvoorbeeld. 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, want iedere afzonderlijke medewerker moet begrijpen waarom met GitOps wordt gewerkt en wat het belang daarvan is, ook voor die 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 wordt ingericht. “We are not doing it like that because it does not work” is een veelgehoord bezwaar tegen werken met GitOps.
Een goede manier om tegen deze negativiteit (en dat woord suggereert al te veel dat de andere partij het niet bij het rechte eind heeft) in te gaan, is 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 laatste werkende configuratie is in Git en daarmee is een cluster zo weer terug te zetten.
Er zijn nog wel vragen te beantwoorden, bijvoorbeeld rondom de combinatie van verschillende soorten deployments en wat te doen als er een orkestratie-fout plaatsvindt (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 krijgen is. “Educate yourself, use Google” is het antwoord. Er zijn weinig plekken om het 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.