Eerder heb ik vanuit een conceptueel standpunt blogs gepost over DevOps. Ik heb besproken hoe de branche nu op een kruispunt is beland over wat DevOps nu eigenlijk is en ik heb ook gepost waarom het altijd een goed idee is om de DevOps-methode te gaan volgen. Dit blog gaat over iets tastbaarders, de kosten die samenhangen met DevOps. En dan specifiek de kosten van DevOps en hoe bedrijven die kosten als een uitdaging ervaren. Ik wil naar die uitdagingen kijken en de realiteit en de financiële voordelen bespreken die het integreren van een DevOps-benadering kunnen opleveren.
Het veranderen van uw ontwikkelbenadering zal altijd enige investeringen vergen. Dat staat als een paal boven water. Uw teams stimuleren om een nieuwe benadering toe te passen, die aanpak formuleren en de implementatie daarvan stimuleren is al moeilijk genoeg. Omdat een DevOps-benadering verder gaat dan de ontwikkelfunctie van een organisatie, kan het integreren van DevOps zelfs nog uitdagender zijn. De organisatie als geheel moet veranderingen begrijpen en doorvoeren om ervoor te zorgen dat de volgende stap kan worden gezet in de DevOps-benadering. Het is in deze gevallen dan ook belangrijk dat u begrijpt wat u wilt bereiken, hoe u dat gaat bereiken en hoe u het succes gaat meten. Niemand wil ervoor verantwoordelijk zijn dat een organisatie een nieuwe weg is ingeslagen om er vervolgens achter te komen dat die niets opleverde dan hoofdbrekens. Hoe kunnen we dan het succes van DevOps meten in tastbare financiële voordelen? Een manier is om te kijken naar de tijd en kosten die het u nu kost om te programmeren.
Disclaimer: Het volgende voorbeeld is puur ter informatie en mag alleen als een goede indicatie worden gebruikt voor wat er met DevOps kan worden bereikt. Probeer nooit om de kosten van DevOps te berekenen of een DevOps-benadering door te voeren zonder begeleiding van een professional. Dit voorbeeld wil niets ten nadele beweren van andere software.
Laten we uitgaan van een eenvoudig voorbeeld: bedrijf X heeft een SaaS-applicatie en heeft meer dan een miljoen onlineklanten. Er worden regelmatig functies geïmplementeerd en problemen opgelost. Intern wordt de preproductie wekelijks geïmplementeerd en extern worden er elke maand nieuwe updates voor de productie uitgegeven. Hieruit kunnen we de volgende cijfers afleiden.
- Implementatiefrequentie
- Wekelijks voor preproductie
- Maandelijks voor productie
- Benodigde mensen voor elke implementatie
- Wekelijks (preproductie)
- 1 dag tijd van een ontwikkelaar
- 1 dag tijd van een operation engineer
- Maandelijks (productie)
- 2 dagen tijd van een ontwikkelaar
- 2 dagen tijd van een operation engineer
- Gemiddelde kosten per persoon per dag is 500 ($/€)
- Wekelijks (preproductie)
Op basis van deze analyse kunnen we uitwerken hoeveel elke implementatie bedrijf X op dit moment kost.
Nu is dit een vereenvoudigd voorbeeld, maar vanuit een DevOps-invalshoek kunnen we nu een eenvoudige oplossing doorvoeren waarin we Source Control, Continuous Integration en Continuous Deployment tools combineren. Als we vrij beschikbare, open source tools erin betrekken, kunnen we kosteneffectieve beslissingen nemen over het doorvoeren van deze toolketen zonder overheadkosten voor licenties. Hierna komen de aanvangskosten voor het opstarten en het eerste bijsturen van de implementatie, maar als het proces eenmaal staat, kunnen we dit met weinig overhead draaien.
Als we dus de kosten voor opstarten en ondersteuning/implementatie meerekenen, hebben we het volgende nodig.
- Opstarten
- 10 dagen tijd van een ontwikkelaar
- 5 dagen tijd van een operation engineer
- Doorlopende ondersteuning (per maand)
- 1 dag tijd van een ontwikkelaar
- 1 dag tijd van een operation engineer
Op basis van deze analyse kunnen we uitwerken hoeveel het opstarten van een geautomatiseerde implementatie kost.
Waar we rekening mee moeten houden is dat in de maanden/jaren na het eerste begin (zoals hierboven aangegeven) er geen opstartkosten meer zijn, dus dat zijn daadwerkelijk eenmalige kosten. Als we dit alles bij elkaar optellen en uitwerken voor twee jaar zonder echte veranderingen in het implementatieproces, hoeveel kan er dan worden bespaard?
Nu is dit een vereenvoudigd voorbeeld, maar de besparingen spreken voor zich. Als dingen gecompliceerder worden, wordt het huidige proces ook gecompliceerder en alhoewel de eerste opstartkosten hoger kunnen zijn dan in dit voorbeeld, leveren het vereenvoudigen en automatiseren van het complexe proces ook meer besparingen op. We hebben zelfs nog niet eens gekeken naar geautomatiseerde Unit Testing, UI Automation, Code Quality-controles of andere zaken waarvoor deze benadering als plug-in voor het verbeteren van de applicatie kan worden gebruikt.
Niet elke organisatie heeft een strategie die zich leent voor een DevOps-benadering, maar gezien de moderne ontwikkelprocessen zijn deze organisaties naar mijn mening in de minderheid. Het is echter wel van belang dat u kritisch naar uw strategie kijkt voordat u deze weg inslaat en een goed beeld hebt of DevOps voor u een geschikte oplossing is. Maar om terug te komen bij waar ik begon, als u denkt dat DevOps te duur is, moet u er misschien nog eens goed over nadenken. Ik zou het zelfs sterker willen stellen. Als u de ruimte hebt voor een DevOps-benadering, kunt u het zich niet veroorloven om DevOps te negeren.
Gareth Burns is strategisch development evangelist bij SQS Benelux
