Vandaag besloot ik toch nog eens te kijken naar de lijst van praatjes op T-DOSE. Omdat toch een aantal praatjes de term "Devops" noemen en ik daar nog nooit van gehoord had besloot ik dat het tijd was om daar toch eens wat over te gaan lezen.

In het blogbericht "What Is This Devops Thing, Anyway?" wordt uitgelegd dat een van de grote problemen in de IT het "schuttingdenken" is. Programmeurs die geconfronteerd worden met een probleem hebben snel de neiging het over de schutting te gooien richting systeembeheerders: "dit is een installatieprobleem, geen codeprobleem", en vice versa; systeembeheerders die zeggen "deze applicatie is perfect uitgerold, het is een bug in de code".

Het idee van DevOps is dat je programmeurs (deels) verantwoordelijk maakt voor het uitrollen op de serverinfrastructuur, en zorgt dat systeembeheerders hun weg weten te vinden in de code. Bij Solide doen we dit (uit de noodzaak van het hebben van een klein team) al sinds onze oprichting.  Het lijkt me dan ook dat DevOps een oplossing is voor een probleem wat voornamelijk bij grotere bedrijven speelt, waar er echt verschillende "afdelingen" zijn voor systeembeheer en ontwikkelwerk die niet met elkaar praten en misschien zelfs op fysiek verschillende locaties zitten.

Zelf zijn we eerder op zoek naar een manier om juist de systeembeheertaken wat meer uit handen te geven omdat het te zeer afleidt van de kerntaak van software en website-ontwikkeling. Crashende servers, mysql rompslomp, ontwikkelen van een goede backupstrategie en systeemmonitoring, mailservers onderhouden enzovoorts zijn niet altijd even prettig en brengen al helemaal geen brood op de plank.

Het basisidee achter Devops vind ik zeker niet verkeerd; iedere programmeur zou genoeg kennis van zaken moeten hebben om te weten tegen welke problemen men zou kunnen oplopen bij het uitrollen van een project op een server; documenteren welke (versies van) software nodig is en voldoende generiek programmeren dat de verschillen tussen productie en de lokale ontwikkelmachine geen probleem vormen voor de succesvolle uitrol (een vaak voorkomend probleem bij de wat minder ervaren ontwikkelaars) is voor ons niet meer dan vanzelfsprekend.

Uiteraard mag je ook van systeembeheerders verwachten dat ze genoeg weten van programmeren om bijvoorbeeld in grote lijnen de betekenis van een stack trace te begrijpen zodat ze zelfstandig een configuratieprobleem kunnen oplossen. Zo kun je een gezonde samenwerking creeren tussen de twee beroepsgroepen en bijvoorbeeld gezamenlijk een aanpak bedenken voor het diagnosticeren van een performanceprobleem of het traceren van een hardnekkige bug die zich alleen voordoet op de live-omgeving.

Zeker voor de echt grote bedrijven is een open cultuur waar de systeembeheerders en programmeurs een open dialoog houden en niet in eigen hokken gestopt worden erg belangrijk. Maar kosten besparen door je programmeurs alles te laten doen is op de lange termijn niet verstandig.