Een mooie definitie van de stroming DevOps is terug te vinden bij Amazon Web Services:
DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market.
Een van de kritiekpunten richting DevOps is dat de stroming te veel vanuit de ontwikkelaar geredeneerd is. En dat is daarmee meteen de kern van dit korte artikel. Wordt met DevOps de muur tussen ontwikkeling en beheer geslecht, of is het juist het uitbreiden van de gereedschapskist van de ontwikkelaar en het steeds verder terugdringen van de beheerder, naar het beheer van de alleronderste laag van de infrastructuur?
Samenstelling team
Bij het samenstellen van een DevOps team is die muur een belangrijk uitgangspunt. Het toepassen van DevOps helpt om de levenscyclus van een applicatie verregaand te versnellen en verkorten, onder andere door het automatiseren van processtappen. Daarbij wordt de gereedschapskist van de ontwikkelaar uitgebreid met vaardigheden (en tools) om bijvoorbeeld infrastructuur als code te kunnen beschouwen. Maar het is vervolgens niet zo dat de gereedschapskist van de beheerder wordt uitgebreid om grip te krijgen op ontwikkelwerkzaamheden.
Automatiseren van werk
Wie zijn eigen werk niet kan automatiseren, heeft straks geen baan meer: een interessant dilemma. Voor een ontwikkelaar speelt dit veel minder dan een beheerder: het automatiseren van programmeerwerk is – ondanks low-code platformen als OutSystems en Mendix – toch een beetje een heilige graal.
Snelheid
DevOps en Agile komen als termen vaak terug bij organisaties die van plan zijn meer, sneller en vaker functionaliteit naar hun productieomgeving te brengen. Die snelheid is gebaseerd op een afgeleide wens van business en eindgebruikers. Afgeleid inderdaad, want is echt iedere organisatie gebaat bij het om de paar minuten naar productie brengen van nieuwe functionaliteit? Dat vraagt om een modelletje.
Waarom eigenlijk?
Er zijn kortweg vier redenen om sneller naar productie (of een volgende omgeving) te willen gaan:
– Er is echt behoefte aan
Gefeliciteerd, u bent de nieuwe Netflix! Uw organisatie en haar omgeving zijn zo dynamisch dat u alle baat heeft bij grootschalige door- voort- en uitbouw. Maar heeft u wel grip op de functionaliteitswens van uw business?
– Gewoon, omdat het kan
Uw bedrijf besteedt veel aandacht aan technologische innovatie. Dat is mooi, want dat geeft u voordelen ten opzichte van uw concurrenten en zorgt dat er over u wordt gepraat, zeker door de technologen bij die concurrenten. Denkt u wel aan het opruimen van (niet-) geslaagde experimenten?
– We denken dat het moet
Dat in uw omgeving iedereen het over DevOps en Agile heeft, moet u zeker tot denken aansporen. Uit de 12e editie van het State of Agile rapport (https://explore.versionone.com/state-of-agile/top-agile-devops-trends-from-the-12th-annual-state-of-agile-report-2) blijkt dat veel respondenten nadenken over DevOps – maar vaak ook op het gebied van Agile nog niet voldoende volwassen zijn. Denkt u wel goed na?
– Niemand zit er eigenlijk op te wachten
U klinkt als iemand die door de trough of disillusionment gaat. Dan bent u er wel vroeg bij, want DevOps zit nog hoog in de hype cycle.
Ops en DevOps
Terwijl de DevOpsers naar hartelust configureren, autom(atis)eren en deployen, kwijnt de Opser weg achter zijn toetsenbordje midden tussen de oorverdovende herrie van het datacenter. De DevOpser die hem net koffie bracht trekt de deur achter zich dicht en het licht gaat uit.
Maar dan gaat er iets fout in de wereld van roll forwards, fail early, fail fast en fail oftens. Er is geen samenhang meer, er zijn te veel verschillende initiatieven die tegelijk iets willen, er zijn verschillende toolchains in gebruik bij afdelingen (het project wordt de nieuwe afdeling!) die niet met elkaar overweg kunnen. De projecten niet en de toolchains niet.
De Opser monitort en bewaakt vanachter zijn scherm het resultaat en de samenhang, ziet waar het fout gaat en grijpt adequaat in om de boel draaiende te houden (ik schets hier een heel idealistisch beeld, daar ben ik me van bewust). De Opser heeft daar eigenlijk niet de tools voor (want wat hip is, is DevOps), dus dan maar weer met bierviltjes, ducttape en pizzapunten.
Naar boven
En wat de Opser constateert, dat kan hij mooi weer naar boven sturen: naar de architect. Kan die niet eindelijk eens wat aan samenhang en integratie doen, vanuit hokje 13 van SAFe? En dan geen visie, maar echt.