En nu samen; de opkomst van DevOps..

Met grote interesse volg ik al enige tijd de beweging die DevOps heet in ICT land. Deze interesse komt vooral voort uit mijn ervaring met virtualisatie en de veranderende dynamiek die dit bracht binnen beheer teams.

De meeste organisaties hebben hun beheer teams netjes op geknipt in diverse teams, zeker als het wat grotere IT organisaties zijn. Dit levert voor managers en teamleiders lekker behapbare stukjes op om sturing op te geven. We treffen hier dan Windows beheer teams, Unix beheer teams, Linux teams, Netwerk teams, Storage teams, etc.. aan. Bij voorkeur kruipen de mensen uit die teams bij elkaar op de kamer. De Linux mannen met een grote Tux op de kamer, de Windows mannen met een foto van Bill, de netwerk mannen met lastige tekeningen aan de muur met veel streepjes, blokjes en Cisco logo’s. En vervolgens allemaal de deur dicht. Zodra er een probleem optreed, kijken de mensen in de teams naar hun eigen monitor schermpje; “alle lampjes op groen? Mooi! Bij mij niets aan de hand dus”. Voor de Windows beheerder betekend dit dat zijn verantwoordelijkheid ophoud bij de netwerk poort van zijn server, en voor de netwerk beheerder start hij op de netwerk switch. Lekkere duidelijke verantwoordelijkheden en afbakening zou je denken..

Ik zet bovenstaande een beetje zwart/wit neer, maar dit is wel gedrag wat je terug ziet in veel organisaties. Dit geheel gaat voorbij aan het feit dat ICT als hoofd doel heeft om de bedrijfsprocessen te ondersteunen en verbeteren. Dit doel uit zich vaak in een applicatie. Veel applicaties bestaan uit meerdere lagen en elementen. Bijvoorbeeld een Windows server (web & applicatie), een unix server (database), storage en netwerk. Dit leid tot de volgende situatie:

De applicatie van de klant werkt niet. Hij belt. De helpdesk zet op basis van hun beste analyse het probleem door naar de 2e lijn. De vraag komt bij het Windows beheerteam. Hun conclusie “mijn lampjes zijn groen, dus niet ons probleem”. Zo gaat het probleem langs alle teams en iedereen roept dat er bij hun niets aan de hand is. De storing word afgesloten, maar de klant zit nog steeds met het probleem.

Conclusie: de silo benadering werkt dus niet altijd.

Nu gooien we virtualisatie in deze mix. Wie gaat de hypervisor en omliggende tools en lagen beheren ? Introduceren we weer een ander (nieuw) team ? Borgen we dit binnen bestaande teams ? Uiteraard is dit een beetje afhankelijk van de gebruikte hypervisor, zo weten Windows beheerders van nature iets meer van HyperV en Linux beheerder iets meer van KVM. Een mooie discussie uit het verleden ging over het beheer van de virtuele netwerk switch die door VMWare geïntroduceerd is in hun omgeving. Tot de introductie van de Cisco Nexus 1000v was dit geen Cisco device, waar door bepaalde netwerk beheer teams geen beheer wilde doen op de virtuele switch.

Als er problemen optreden in een virtuele omgeving merk je ook al snel dat je de diverse disciplines bij elkaar nodig hebt. Dit zonder grote ‘hand-overs’ of het ‘over de muur gooien’ van het probleem.

Virtualisatie in generieke zin heeft daarnaast nog iets geïntroduceerd; systemen zijn op een software matige (programmeerbare) manier te configureren en beheren. We betreden een tijd perk waarbij men steeds minder fysieke systemen hoeft te ‘stekkeren’ maar dit steeds vaker via een script of programmeer interface kan doen. Zeker waar deze beweging leid tot een groei (van 10 servers nu naar 100 virtuele servers), is de beheerder er steeds meer bij gebaat om een scriptje te hebben die standaard zaken voor hem automatisch kan afhandelen. De programmeer skills van beheerders worden derhalve ook steeds belangrijker en hun werk wijzigt op dat vlak.

Hierbij raken scripts rond virtualisatie (zeker als je self-provisioning in de mix gooit) opeens netwerk, storage en besturingssysteem.

Als management heeft men deze silo’s vaak gecreëerd door de organisatie zo in te delen. Het effect is ook duidelijk en hier mee zijn we een belangrijk doel van ICT een beetje uit het oog verloren…

Ontwikkelaars v.s. beheer

De dynamiek tussen ontwikkelaars, bouwers (Dev) en beheerders (Ops) is van een hele andere orde;  Daar waar (applicatie of infrastructuur) ontwikkelaars gedreven worden door ‘change’ zijn beheerders daar nu juist helemaal niet bij gebaat omdat zij gedreven worden door stabiliteit en het handhaven van status quo. De ontwikkelaar heeft als taak om nieuwe functionaliteit toe te voegen of bestaande te wijzigen, waar de beheerder enkel bestaande services aanpast of verbeterd.

Dit alles levert een muur op tussen ontwikkelaar en beheerder die nog veel hoger is dan de muur tussen de silo’s;

Development builds an application, the new hotness which promises customers all the whizz-bang features and will make the company millions.  It is built using cutting edge technology and a brand new platform and it has got to be delivered right now.  Development cuts code like crazy and gets the product ready for market ahead of schedule.  They throw their masterpiece over the fence to Operations to implement and dash off to the pub for the wrap party.

Operations catches the deployment and is filled with horror. The Operations team summarises their horror and says one or more of:

• The wonder application won’t run on our infrastructure because {it’s too old, it doesn’t have capacity, we don’t support that version}
• The architecture of the application doesn’t match our { storage, network, deployment, security } model
• We weren’t consulted about the { reporting, security, monitoring, backup, provisioning } and it can’t be “productionised”.

(Credit Dev2Ops)

Om dit gat te slechten hebben we o.a. vanuit ITIL en andere methodieken inmiddels complete ‘productie gelijke’ test omgevingen ingericht, acceptatie omgevingen, beheer acceptatie omgevingen en test procedures. Dit om de hand-over maar te borgen tussen de ontwikkelaars (Dev) en de beheerders (Ops). Voor de beheer silo’s kennen we tools als HP OpenView en IBM Tivoli die als een beheer paraplu over de silo’s heen kijkt en de end-to-end keten van een applicatie in de gaten houden.

Het is dus zeker niet allemaal kommer en kwel in de IT1.0 wereld want met wat tools en procedures hebben we een soort samenwerking gevonden. In de wijzigende IT wereld behoeven we niet eens heel ver te kijken om te zien dat dit alles echter niet lang houdbaar is. De invoering van virtualisatie levert al aardige voorbeelden op. Uiteraard allemaal best op te lossen met de huidige manier van denken, maar de vraag is of dat het meest effectief is…

DevOps.

DevOps draait om het voor komen van de boven genoemde problemen door slimmer samen te werken en efficiënter te zijn. Het is een framewerk van ideeën en principes die lijden tot samenwerking, coördinatie en kennis uit wisseling tussen ontwikkelaars en beheerders. In een DevOps omgeving bouwen ontwikkelaars en systeembeheerders gezamenlijk aan processen en tools die hun in staat stelt om beter samen te werken en uiteindelijk het ICT product beter en sneller de deur uit te krijgen.

DevOps gaat ook verder dan alleen de uitrol van software; het draait om een nieuwe manier van denken rond samenwerking en coördinatie tussen de mensen die de software bouwen en zij die het moeten beheren. Zaken als automation, monitoring, capacity planning & performance, backup & recovery, security, networking en provisioning hebben allemaal baat bij het DevOps model door de manier waar op ontwikkel en beheer teams samen om gaan met deze gebieden.

Er is dus geen eenduidige definitie voor DevOps, maar in de basis draait het om cultuur verandering en het afbreken van muren die kwaliteits verlies en doorlooptijd veroorzaken.

Veel gebruikte referentie frameworks binnen DevOps zijn Agile en Scrum. De invoering van dit soort methodes die uit de software hoek komen vereisen ook wel een bepaalde cultuur wijziging; het veelvuldig uit brengen van kleine releases voor software (zoals gepredikt word door deze technieken) levert automatisch spanning op bij de beheerders, die dit moeten ontvangen. Nu infrastructuur ook steeds meer te ‘programmeren’ is (o.a. dankzij virtualisatie), zijn beheerders ook programmeurs. Het schrijven van scripts om zaken te automatiseren is al lang niet vreemd meer voor deze groep ICT-ers. Denk aan perl, bash, python en de opkomst van Windows Powershell. De ontwikkeling van Cloud neemt dit nog een stap verder met zaken als Puppet en Chef die de automatisering van de te beheren omgeving naar een volgend niveau brengen. Hierbij zijn beheerders dus ook gebaat bij de inzet van Agile en Scrum.

Beheerder zullen roepen; en wat moeten we dan met ITIL? ITIL en DevOps (en overigens ook Agile, Scrum en andere LEAN adepten) lijken elkaar af en toe in de weg te zitten. Dat is echter maar gedeeltelijk waar en draait vooral om de manier waarop er met ITIL word omgegaan in de organisatie. Daar over in een later blog meer… of Google eens op DevOps & ITIL..

En dan ?

Nu is het altijd mooi om te zeggen dat we beter willen samen werken, maar hoe doe je dat nou ? Enkele voor beelden en tips:

1. Bekijk samen de non-functionals, waar beheerders vaak mee worstelen;

• Security
• High availibility
• Configuration mngt
• Monitoring
• …

2. Deel de infrastructuur; door elkaar in de keuken te laten kijken kun je werken aan een beter product. Dit betekend bijvoorbeeld ontwikkelaars (read-only?) toegang te geven tot de monitoring van de productie omgeving. Door gezamenlijk te kunnen kijken wat er gebeurd in de productie omgeving start je de communicatie en conversatie.

3. Werk met hoog frequente, kleine wijzigingen; door het uitvoeren van kleine afgebakende wijzigingen kun je probleem gebieden gemakkelijk identificeren en verlaag je de kans op uitval. Daar naast is het makkelijker communiceren en evalueren door alle betrokken partijen uit ontwikkel en beheer teams. Dit alles forceert een goede samenwerking tussen deze teams.

4. Deel verantwoordelijkheid; het afsluiten van SLA’s en OLA’s met als doel naar elkaar te kunnen wijzen als er iets fout is gegaan is contra productief voor de eind-gebruiker. Die is niet geholpen met de kloof tussen ontwikkelaar en beheer en de onderlinge beheer silo’s. Alleen als je de verantwoordelijkheid voor de programmeer code van de applicatie en het uiteindelijke beheer deelt met elkaar kom je tot een voor de klant productieve oplossing.

5. Wissel mensen uit; (zoals bij punt 2) laat een ontwikkelaar eens mee lopen met een beheerder en andersom.

Dit zijn slechts enkele handreikingen en voorbeelden. Er zijn diverse blogs die hier uitgebreid op in gaan. Daarnaast zijn er (steeds meer) bijeenkomsten waar in andere vertellen hoe ze hier handjes en voetjes aan hebben gegeven.

Zie ook:

• Old-style rules and red tape derail private cloud project
• DevOps is not a technology problem. DevOps is a business problem.
• Devops Demystified
• De aanstichter: Patrick Debois – blog
• Planet DevOps
• What DevOps means to me…
• Use cloud and get rid of your sysadmin (NOT..).

Voor een uitstekende presentatie zie: Rise of DevOps