Van Dev naar DevOps.

Artikel uit SDN Magazine 147

Door een collega werd ik gevraagd om een   te schrijven met DevOps als topic en daarin te reflecteren op mijn ervaringen. De afgelopen tien tot vijftien jaar heb ik aan een aantal organisaties richting gegeven en zelf ook deelgenomen in de verandering van Dev naar DevOps. Daarnaast ben ik in mijn huidige rol, waarbij Cloud migraties de kern van mijn werk vormen, ook betrokken bij het ontwikkelen en geven van trainingen over DevOps om engineers voor te bereiden op een andere werkwijze. Die achtergrond biedt een mooi bruggetje om eens terug te kijken en te zien of er een essentie van de verandering van Dev naar DevOps samen te vatten is.

 

Beperkingen

Het meest aansprekende aspect in deze verandering vind ik de wrijving die ontstaat bij de overgang van Dev naar DevOps. In mijn beleving ontstaat dat door het domein van bijna onbegrensde mogelijkheden (Dev) naar de beperkende realiteit van de operationele systemen (Ops) moet worden vertaald. Dat is een wereld waarin een andere vorm van engineering wordt gevraagd, gekoppeld aan een sterke discipline en hygiëne, welke bij softwareontwikkeling niet altijd even duidelijk zichtbaar is. Ook de kennis over platformen, netwerken en aspecten zoals observability zijn vak geheel nieuw of grote onbekenden. Dat brengt dus veel nieuwe uitdagingen met zich mee.

 

“Wrijving geeft warmte” zegt men wel eens om duidelijk te maken dat wrijving ook positief kan zijn maar het beschrijft ook zekere weerstand die overwonnen moet worden. Die spreekwoordelijke drempel die men over moet in deze verandering van Dev naar DevOps, is geen eenvoudige en verlangt dat je als ontwikkelaar goed beslagen ten ijs moet komen. Echter je hoeft als Dev ook niet bang te zijn. Immers, je capaciteit om te leren en analyseren is al onderdeel van je dagelijks werk. Dat is een ijzersterke basis. Er is nog wel een aanvullende voorwaarde en dat is doorgaande steun vanuit het management/leiderschap van je organisatie. Zonder die steun is de kans op succes bij het afleggen van deze reis nihil.

 

Kennis

Elk domein verlangt zijn specifieke kennis om daarin succesvol te kunnen opereren, het is niet anders met DevOps. Naast kennis hebben zul je ook een aantal vaardigheden moeten ontwikkelen en beheersen om operationeel aan de slag te kunnen en productief te zijn.

 

Een stuk training kan met name op het gebied van te volgen werkwijze en aan aantal praktische zaken een goede invulling zijn maar er zijn ook meer theoretische aspecten en achtergronden die helpen om de benodigde verandering te verlichten.

 

Daarin zou ik als belangrijkste richtlijn basiskennis over netwerken en computerarchitectuur willen benoemen. Zeker waar het gaat om werken met gedistribueerde systemen en Cloudomgevingen is het essentieel dat je als ontwikkelaar conceptueel begrijpt hoe zaken als performance, schaalbaarheid en veiligheid de compositie van jouw product of dienst beïnvloeden.

 

Goede voorbeelden van theoretisch inzicht van een systeem zijn bijvoorbeeld het CAP-theorema en de memory hierarchy. Als je eenmaal inziet dat data over een netwerk lezen/schrijven duidelijk andere performance levert dan wanneer je alles in-memory kan doen (en vooral waarom) dan leer je redeneren hoe je dit voor optimalisatie van jouw product of dienst kan benutten of waar er juist negatieve gevolgen ontstaan.

Bron: Quora https://www.quora.com/What-is-Memory-hierarchy image:

https://qph.cf2.quoracdn.net/main-qimg-7a90a61c09f30bc2ed08c4a806cf994a

 

Betrouwbaarheid

Des te langer ik werk met gedistribueerde systemen en Cloud omgevingen, heb ik ervaren dat niet alles altijd werkt zoals verwacht of is gespecificeerd. De Cloud is immers “iemand anders zijn computer” en daar gaat ook wel eens wat mis. Binnen de context van één machine zijn we als Devs gewend dat alles eigenlijk altijd werkt. Er is nagenoeg geen latency en bestanden van disk lezen en schrijven lijkt altijd foutloos te gaan. Die illusie is lastig om los te laten maar door bijvoorbeeld in een Cloud omgeving met commodity hardware te gaan werken leer je dat niet elke call altijd succesvol is. Dat leert je dat je zaken als reliability patterns, zoals bijvoorbeeld circuit breakers en retry policies, moet toepassen om de beschikbaarheid die je product of dienst levert te maximaliseren.

 

Kosten

Ook wordt duidelijk dat: “niets gratis is”, en zeker niet in de Cloud. Het bewust worden van de kosten van dataverkeer over een netwerk en het aantal operaties dat je uitvoert tegen een object storage zijn nog diepere voorbeelden daarvan en bieden een geheel nieuwe uitdaging. Dat is een ander perspectief op dezelfde materie, dat wat ik het DevOps perspectief zou willen noemen. Het samenspel tussen softwareontwikkeling en de operationele aspecten voor het vinden van een optimale mix.

 

Als onderdeel van de continue optimalisatie kun je ook onderzoeken in hoeverre je de kosten optimaliseert. Dat kan door meer zelf te doen, of juist te vertrouwen op volledig beheerde omgevingen door de Cloud provider. Meer zelf doen bespaart in de maandelijkse kosten maar heeft als omgekeerd effect wel een groter beslag op tijd en affiniteit met het operationeel houden van de compute capaciteit vraagt. Het vergt daarnaast begrip over bijvoorbeeld verschillende typen storage en hoe deze te configureren zonder dat je de dienst downtime bezorgt als er een keer een disk vol loopt, of hoe je systemen zonder downtime kunt patchen.

 

Eigenaarschap

Ik zie de verandering van Dev naar DevOps zie als een verbreding van mijn vak, niet als compleet iets anders. Eigenlijk is het eigenaarschap nemen van die aspecten welke voorgaande generaties platform-ontwikkelaars en leveranciers jarenlang voor ons Devs hebben geprobeerd te beheren. Misschien is het een stap in het proces van volwassen worden aangezien nu wel duidelijk is dat dat verbergen van operationele complexiteit niet altijd de optimale uitkomst heeft opgeleverd. En zeker een operationele omgeving waar alle aspecten “software defined” zijn of APIs aanbieden, biedt bij uitstek voor Devs een omgeving waarin we prima uit de voeten kunnen. Dat helpt ook de organisatie waar we voor werken om sneller applicaties bij de klant geleverd te krijgen tegen vaak lagere kosten.

 

Continue verbeteren

De reis van Dev naar DevOps vervolgt zich eigenlijk langs de lijn van continue optimalisatie. Daarbij kunnen we voor individuele teams leunen op metrics die we als onderdeel van ons werk kunnen verzamelen. De DORA metrics (laten we daar maar een andere keer specifiek op terugkomen) bieden een wetenschappelijk verantwoorde blik op de kwaliteit van het proces waarop we software leveren aan gebruikers. Het is essentieel om deze goed te begrijpen want het biedt inzicht in de karakteristieken die een team kunnen blokkeren in hun groei en ontwikkeling. Ik denk wel dat deze metrics pas interessant zijn als een team enige tijd samenwerkt en de onderlinge rolverdeling heeft gevormd. Meer daarover is te lezen in het boek Acellerate van dr. Nicole Forsgren.

 

Het kunnen optimaliseren van processen leunt in veel gevallen op het gedachtegoed vanuit de wereld van Lean, wat je mogelijk kent vanuit manufacturing. Het ontwikkelen van softwareproducten en het ontwikkelen van fysieke producten aan een productielijn is niet altijd goed vergelijkbaar, en dus is niet alles uit dat gedachtengoed van toepassing op software. Echter de beginselen waarin value chain analysis en het analyseren van proces bottlenecks wordt beschouwd is weldegelijk waardevol omdat het statistisch inzicht geeft en aanleiding voor optimalisatie experimenten kan opleveren. Lees daarover meer in DevOps for the Modern Enterprise van Mirco Hering

 

Sustainability

Een prachtig voorbeeld van een nieuw aspect waarbij DevOps essentieel is, is het optimaliseren van de voetafdruk van een systeem. Hoeveel energie wordt er verbruikt en is dat uit verantwoorde bron, etc.? Er zijn daarbij nog heel veel vraagstukken onbeantwoord over welke metrics relevant en verantwoord bruikbaar zijn maar de algemene “groene aspecten” zijn belangrijk doel van vele organisaties die streven naar verantwoord ondernemen. Het kunnen bieden van inzicht daarin en het optimaliseren is dus goed voor de hele organisatie, en uniek in scope voor DevOps.

 

Niet per definitie agile

Een bestaande misvatting in mijn opinie is dat DevOps nogal eens verward wordt met Agile. Dat is eigenlijk appels met peren vergelijken. Echter, het uitgangspunt om continue high quality software te leveren waarbij je snel op veranderingen in kunt spelen heeft wel overeenkomsten met DevOps. Dit is bijvoorbeeld waar practices zoals continuous delivery/deployment en continuous improvement om de hoek komen kijken. De essentie daarvan is dat je als ontwikkelaar zo snel mogelijk feedback wilt hebben op features die je ontwikkelt. De manier waarop dat gestalte krijgt is door middel van het snel kunnen leveren van de software aan de gebruikers door middel van een pipeline.

 

Feedback

Het ontwikkelen van die pipeline, het daarin opnemen van de benodigde quality gates en build breakers is essentieel om de feedback loop naar de gebruikers te creëren. Daarnaast moet de software inzicht bieden in het gebruik, want hoe weet je immers of de software die je uitrolt beter is als de voorgaande? Dat brengt ons wederom bij inzicht in operationele aspecten, performance, errors, latency, feature gebruik en gebruiksgemak, het zijn allemaal factoren die we automatisch kunnen verzamelen om inzicht te bieden en een nog beter product of dienst te bouwen.

 

Incrementeel bouwen

Dat vereist wel een specifieke manier van een systeem bouwen, namelijk dat een systeem incrementeel geleverd moet kunnen worden. Daarin moet je dus niet alleen nadenken over initiële deployability maar er ook rekening mee houden dat bijvoorbeeld uitbreidingen moeten kunnen worden toegevoegd en sommige dingen niet direct verwijdert kunnen worden, etc., etc. Er zijn ondertussen allerlei goed gedocumenteerde patterns en practices beschikbaar voor het incrementeel bouwen en uitrollen van software bekend. Het is vervolgens een kwestie van onderzoeken welke aspecten en eigenschappen het best overeenkomen met het ontwikkelen van jouw dienst of product en die practices waar nodig te adopteren.

 

Infrastructure as code

Het incrementeel ontwikkelen van de infrastructuur waarop je applicatie of dienst draait is zeker met het gebruik van Cloud volledig te automatiseren. Er bestaan verschillende manieren om dat te doen en de voor mij meest gebruikelijke is met het gebruik van “Infrastructure as Code”. Daarbij kun je of een declaratieve of een meer procedurele aanpak volgen. Uiteindelijk gebruik je een software defined datacenter om te definiëren hoe een mix van compute, storage en networking met elkaar verbonden zijn.

 

Ik vermoed dat de meeste Devs in de verandering naar DevOps het meeste opzien tegen het nemen van deze stap. Dit inderdaad het moment waarop je kennis en kunde over infrastructuur moet vertalen in specificaties of API-calls en moet leren te begrijpen welke gevolgen dat heeft voor de infrastructuur die je opbouwt en de applicatie die daar al bovenop draait. Dat vereist het ontwikkelen van affiniteit met die aspecten. De enige manier die ik ken om dat te leren is door er hands-on mee te werken, gewoon doen.

 

Misschien is het ook wel “angst voor het onbekende” want veel van de practices zijn helemaal niet nieuw. Traditionele operations medewerkers hadden al goede practices ontwikkeld en die kunnen we gewoon overnemen. Daarmee kunnen we er bijvoorbeeld voor zorgen dat we wijzigingen veilig kunnen testen voordat we deze op onze productieomgeving toepassen. Dat is ook het mooie van IaC, je kunt infrastructuur met het grootste gemak definiëren, configureren en ook weer weggooien na gebruik. Door dit proces ook in een pipeline te vatten beperk je tevens de kans op fouten door menselijk handelen waardoor de kwaliteit van de wijziging nog verder toeneemt.

 

Blijven leren

De weg van Dev naar DevOps is best lang, dat zal ik zeker niet ontkennen maar dat betekent niet dat de weg altijd ongemakkelijk is. Als Dev word je in eerste instantie geconfronteerd met veel zaken die buiten je comfort zone zullen liggen maar gaandeweg krijg je daar grip op. De beste om vooruit te komen in die reis, is vol vertrouwen in de nieuwe materie te duiken en te weten dat je als ontwikkelaar het lerend vermogen hebt om dit allemaal stapje-voor-stapje te kunnen leren beheersen.

 

About Me:

Carlo Kuip werkt als senior consultant voor Microsoft met specialisatie “app innovation and modernization”. Je kunt hem op twitter vinden: @CarloKuip en zijn persoonlijk blogs zijn te lezen op https://www.carlokuip.me