Dansen op de DevOps vulkaan

donderdag 3 december 2015

Een nieuwe herfst, en alweer een nieuwe Brunel-klus: senior middleware engineer bij een grote webwinkel in Zwolle. Hoewel mijn net deze zomer weer opgepoetste architectuur-skills zowel development als beheer raken kom ik toch het meeste aan de beheer-zijde terecht, maar ook daarin vind je nog volop uitdagingen. Sterker nog, bij deze webwinkel kom ik dezelfde verhitte debatten rondom DevOps tegen als bij de eerdere klanten. Zoals de meeste lezers zullen weten is DevOps een poging om de Development- (werkend via pakweg Scrum) en Operations- (altijd min of meer ITIL volgende) disciplines nader tot elkaar te brengen. En daarin vliegen meningen rond zoals:

$name

  • “Operations is te duur en bureaucratisch traag.”
  • “Operations garandeert kwaliteit en halen van de SLA, elk stuk vrijheid op produktiesystemen dat aan developers gegeven wordt zal wederom misbruikt worden.”
  • “Het kan allemaal veel goedkoper en sneller door de Ops experts in DevOps teams onder te brengen, pure projektonafhankelijke Ops voor pakweg het platform moet minimaal zijn.”
  • “Nee, dan brengen die enge bureaucraten gewoon hun oude denken mee. Schaf gewoon de hele Ops als aparte taak voor scrumteams af, dat kan een developer er best bij doen mits ie maar duidelijke richtlijnen krijgt voor inbeheername en incidentafhandeling.”
  • “Niet alleen Ops is onnodig, eigenlijk architectuur binnen Java ook. Dat vertraagt alleen maar. Laat developers zélf volledig verantwoordelijk zijn voor de stack onder hun applicatie en dit in VM’s of Containers tot aan produktie brengen, met steeds als ze dat nodig hebben de allernieuwste versies van pakweg JBoss of Jetty.”

Het boeiende zeker voor ons externen is dat al dit soort generieke uitspraken soms wel en soms niet een kern van waarheid hebben – soms is het alleen opgeklopte rook en soms échte vulkanische lava. De kunst is dus om terug te gaan naar het WAT van Operations, de minimumeisen waar professioneel ITIL-beheer aan voldoet en die (met enige speelruimte qua detail) toch écht in elke situatie toepasbaar zijn. Dan praat je met name over de ‘Service Transition’ en ‘Service Operation’ delen van ITIL; bij Transition leidt het noeste developer-resultaat tot een concrete Change-invoering en in Operation houden we zowel het platform als de applicaties goed in de lucht. Die WAT-vragen omhelzen o.a.

  1. Elke change moet getest zijn op functionaliteit en zonodig performance, inclusief regressie op overige componenten, door personen onafhankelijk van de bouwers.
  2. Uitzonderingen op standaardplatformcomponenten zijn alleen toegestaan als de hogere gremia het nut bevestigen en de meerkosten voor de hele levensduur accepteren. Aannemen dat de developer zélf altijd beschikbaar is voor support en onderhoud kan eigenlijk niet.
  3. Elk deel van de stack is bepalend voor de SLA, dus naast platformbeheer is er ook applicatiebeheer en dat zonodig 24 uur. Ops taken neergelegd bij DevOps personeel vormen daarop geen uitzondering. Zaken als problemen/incidenten maar ook simpelweg bijhouden van alle ons-systeem-mogelijk-rakende-changes moeten altijd voorgaan op om het even welke scrum-deadline die in hun Developmentmethode beloofd was.

En nadat je die vragen als organisatie vastgelegd hebt is het vervolgens zaak om elke voorgestelde HOE oplossing ertegenaan te houden. Als een oplossing niet aan alle eisen voldoet, en bijvoorbeeld bij “Een developer kan Ops er best bij doen” wordt vaak vergeten hoeveel storypoints er dan wel gereserveerd moeten zijn voor de Ops-taken, dan moet hij worden aangepast. En als een oplossing wél aan alle eisen voldoet maar te duur lijkt wordt het heronderzoeken. Op DTAP test-omgevingen bijvoorbeeld kan best te besparen zijn pakweg door eenzelfde omgeving parttime voor Test (technisch) en Acceptatietest (functioneel en performance) te gebruiken, of door de omgevingen dynamisch te provisionen met VM’s/App-V/Docker en weer vrij te geven.

En dat maakt je rol als Brunel-engineer alleen maar boeiender: gewoon uitgaan van de correcte WAT vraag en dan vervolgens samen met je hele afdeling de best mogelijke HOE oplossing bepalen. Die zelfs per domein zou kunnen verschillen: als de situatie bijvoorbeeld een Windows/Dotnet-stack heeft naast een Java/Linux bouwstack en wat standaardpakketten dan zouden er zomaar drie slechts deels gelijke modellen voor DevOps kunnen gelden. Het klinkt simpel, en mensen die dat ook simpel kunnen blijven uitleggen zijn altijd welkom!

Happy computing,

<Erik>