Voordat we meteen met de deur in huis vallen door te vertellen wat DevOps volgens S0L1D Heroes is, nemen we je mee in het ontstaan van DevOps en de naam DevOps. Zelfs de meeste DevOps Engineers of DevOps Coaches kennen het originele verhaal niet. Jij straks wel ;-)

Er was eens een Vlaming die zich met enige regelmaat frustreerde en irriteerde aan de samenwerking, lees conflicten, tussen developers en sysadmins. Deze Vlaming, Patrick Debois, was in 2008 op een congres in Toronto om daar een sessie bij te wonen, genaamd “Agile Infrastructure”, geïnitieerd door Andrew Shafer. Tot zijn verbazing was hij de enige in de ruimte. Blijkbaar was er geen interesse in het onderwerp. Zelfs Andrew Shafer was niet bij zijn eigen sessie. Patrick spoorde Andrew op om toch over het onderwerp te praten. Eenmaal gevonden en gesproken, besluiten ze de “Agile System Administration Group” op te richten.

DevOpsDays

In 2009 wordt Patrick uitgenodigd om bij een congres te zijn in Amerika, maar helaas moest hij zich hiervoor afmelden. Vanuit Amerika wordt de suggestie gedaan om zelf een congres in België te organiseren en Patrick besluit om dat te gaan doen. Hij stoeit nog wel met de naam, dus pakt hij de eerste drie letters van DEVelopers en de drie letters van OPerationS en voegt deze samen en daar voegt hij “days” aan toe. Het congres DevOpsDays is geboren.

Na een geweldig event gaat de discussie en het napraten op twitter verder. De hashtag #devopsdays is best lang, dus besluit Patrick om de naam te verkorten naar #devops: De geboorte van de naam DevOps. Een aantal jaar later werd Patrick geïnterviewd met de vraag hoe hij aan de naam kwam. Hij zei dat er geen mastermind plan achter zat. Het was een meer een simpele manier van de drie letters van development en operations te pakken en die samen te voegen. Daarbij is agile-systemadministration-days gewoonweg veel te lang om te gebruiken.

Mindset

Nu je weet hoe DevOps is ontstaan, is het ook goed om te weten dat DevOps niet een framework is, of een methode of een product. DevOps is een mindset, een beweging, een manier van werken. Bedacht en uitgevoerd door mensen van de werkvloer. DevOps staat open voor vernieuwing en verbetering. Een manier van denken. Samenwerken en samen verantwoordelijk zijn voor een product of dienst. Het is lastig om een standaard definitie te definiСren voor DevOps. Als je tien verschillende mensen vraagt wat DevOps is, krijg je ook 10 verschillende antwoorden. En een grote kans dat alle 10 de personen het juist hebben, of een groot gedeelte juist hebben. DevOps is dan ook zeker niet “one size fits all”.

From cradle to the grave

Maar wat is DevOps dan wel? Er wordt ook wel gezegd dat DevOps verder gaat, daar waar Agile stopt. Agile is voornamelijk in het leven geroepen om waarde te leveren aan de klant door iteratief en incrementeel software te bouwen en te leveren aan de klant. Zo snel mogelijk de feedback van de klant te krijgen en zo te toetsen of het team met de juiste dingen bezig is. Het beheren van de software is echter niet in die gedachte meegenomen. Dat doet DevOps dus wel. Een team, gezamenlijk verantwoordelijk voor een product, dienst of service, van begin tot eind. “From cradle to the grave” zeggen we ook wel in DevOps-land. Een andere mooie quote hierin is “you build it, you run it” Oftewel: alles wat je bouwt, moet je ook beheren.

Feedback

DevOps teamleden zijn nog steeds op zoek naar feedback, maar niet alleen feedback van de klant, juist ook de feedback vanuit de systemen rondom het product en het product zelf. Een DevOps team is dan ook veel meer feedback driven in plaats van value driven van een Agile team. Want door de feedbackloop zo kort mogelijk te maken, liefste real-time, kan er uiterst snel geschakeld worden. En door de processen ook nog eens te automatiseren, ontstaat ook daar een snelle feedbackloop.

Door het inrichten van een geautomatiseerde delivery pipeline met allerlei quality gates, en door het inrichten van goede monitoring op de gezondheid van het product en de omgeving waar het product op draait, weet een DevOps team trends te signaleren en zo incidenten die nog niet hebben plaats gevonden, te voorkomen. Op die manier kan een DevOps team nog meer waarde leveren aan de klant. Eigenlijk zijn de DevOps teams horny-for-feedback.

Nu je weet dat DevOps niet een product, methode of framework is, maar een manier van werken en denken, kun je ook concluderen dat het certificeren in DevOps complete onzin is. Een certificaat halen in ITIL is logisch, want dat is een framework. Hetzelfde geldt voor een certificaat van RedHat, want dat is weer een product. Dit geldt dus niet voor DevOps. Alle certificaten die op het gebied van DevOps worden aangeboden zijn in mijn optiek commerciële uitbuiting. Meeliften op het succes van DevOps.

High Performing

Het volgen van een DevOps awareness sessie of workshop, vind ik wel weer van toegevoegde waarde. Omdat dat juist helpt in het vergroten van de awareness (zoals de naam al zegt), maar ook omdat de teamleden die zo’n sessie of workshop bijwonen wederzijds begrip krijgen voor de standpunten van anderen. Dat helpt weer bij de teambuilding, wat uiteindelijk weer resulteert in een High Performing team.

Maar wat is dat nou weer, een High Performing team? Een High Performing team is niets anders. Een Agile team, een DevOps team, een servicedesk team, het kunnen allemaal High Performing teams zijn.

Het gaat erom dat het teams zijn die voor elkaar klaar staan. Elkaar door en door vertrouwen, opkomen voor elkaar, feedback op een constructieve manier geven en ook feedback kunnen ontvangen. Dat zijn teams die high performen. Ze weten als team de klus te klaren.

Hoe je zo’n high performing team creëert? Daar kom ik mijn volgende blog op terug. Want dat is andere koek.