Stel: je bent verantwoordelijk voor de operatie bij een SaaS-provider of grotere ict-gedreven organisatie. Dan is het aannemelijk dat je te maken hebt met applicaties die in huis ontwikkeld worden. De teams die verantwoordelijk zijn voor de ontwikkeling van deze applicaties zijn waarschijnlijk allang ‘Agile’ en ontwikkelen in een hoog tempo nieuwe versies van de software. Dat moet ook, want de markt verandert snel.
Nieuwe functionaliteit moet snel beschikbaar zijn voor de gebruikers. Als operationeel verantwoordelijke heb je een behoorlijke uitdaging om ervoor te zorgen dat al die softwarereleases op tijd doorgevoerd worden. De kans is groot dat je naast de productieomgeving diverse omgevingen hebt draaien voor ontwikkeling, test en acceptatie. Deze omgevingen moeten allemaal onderhouden worden en uiteraard identiek zijn om het uitrolproces te borgen. Je weet dat alleen de software die daadwerkelijk in productie is jouw organisatie geld oplevert. De druk om sneller te kunnen ontwikkelen wordt alleen maar groter. De concurrentie speelt steeds sneller in op nieuwe ontwikkelingen, sommige van je concurrenten nemen meerdere nieuwe versies van de software per dag in productie. Als je geen idee hebt hoe ze dat doen lees dan vooral verder.
Behaalde resultaten
Organisaties die aan de slag gaan met deployment automation in de cloud behalen nogal aansprekende resultaten blijkt uit onderzoek van Xebia onder gebruikers van DeployIT:
- Drie tot vijf keer snellere ontwikkeling van applicaties;
- Tot wel 80 procent of meer besparing op kosten it-operations;
- Uitrol van applicaties in minuten in plaats van weken en zonder fouten.
Deployment Automation in combinatie met cloud diensten vormt simpel gezegd de integratie tussen het release proces van de ontwikkelaars en het hosting platform van operations. Door de uitrol van applicaties op het platform volledig te automatiseren en daarbij ook de uitrol van de benodigde servers geautomatiseerd te laten verlopen worden handmatige stappen in het proces voorkomen. Doordat de uitrol van de software volledig geautomatiseerd verloopt behoren fouten in de productie omgeving tot het verleden. De uitrol vindt plaats op ontwikkeling, test en acceptatie met de zelfde parameters voor iedere omgeving.
Vijf hele goede redenen om na te denken over het invoeren van software deployment automation in de cloud:
1): Het minimaliseren van menselijke fouten bij software uitrol. Ook al is het script wat de ontwikkelaars meegeven met een nieuwe versie nog zo goed, het blijft een handmatige stap. Iemand moet inloggen op een productieserver om daarop software klaar te zetten. Bij het maken en uitvoeren van de scripts worden vaak nog veel fouten gemaakt, het uitzoeken hiervan kost veel tijd, en leidt soms tot applicatie-onbeschikbaarheid of dataverlies.
2): Verhoging van proces controle op de uitrol. Een goede rapportage over het softwarerelease-proces ontbreekt vaak. Hoeveel nieuwe versies worden er uitgerold op de verschillende omgevingen? Hoeveel fouten worden daarbij gemaakt? Welke versie van de software was op welk moment actief? Daarnaast ontbreekt vaak de controle over wie, op welk moment, op welke omgeving nieuwe versies van de software mag uitrollen.
3): Kosten besparen door pay-per-use te gebruiken. Als het enkele weken duurt voordat een ontwikkelaar toegang heeft gekregen tot een aangevraagde server dan laat hij het wel uit zijn hoofd om deze weer vrij te geven na afloop van de werkzaamheden. Die server blijft gewoon draaien en kost dus geld. Door de uitrol van nieuwe omgevingen te automatiseren en daarbij ook geautomatiseerd de servers te laten klaar zetten, kunnen ze ook weer opgeruimd worden na gebruik. Als de infrastructuur wordt afgenomen op basis van een pay-per-use model, zoals bijvoorbeeld bij een IaaS cloud provider, wordt er afgerekend voor het werkelijk gebruik over de periode van de uitrol.
4): Software ontwikkeling kan echt veel sneller en de kwaliteit beter. Doordat ontwikkelaars nu moeten samenwerken met de operationele afdeling voor het kunnen uitrollen van nieuwe versies loopt dit proces vertraging op. De ontwikkelteams werken vaak al volledig Agile en kunnen zo makkelijk voor iedere nieuwe functie in de software een kleine release doen, in plaats van alles te bundelen tot een periodieke release. Hiermee wordt niet alleen de nieuwe functionaliteit veel eerder beschikbaar gesteld, maar worden fouten veel sneller opgespoord en opgelost.
5): Nooit meer ruzie tussen development en operations. Door deployment automation toe te passen krijgt de development afdeling een portal ter beschikking waarmee ze zelfstandig software kunnen uitrollen op de verschillende omgevingen. Ze kunnen zelfs volledig geautomatiseerd omgevingen klaarzetten op het cloud platform van de IaaS-provider. De tussenkomst van operations is hier niet meer nodig. Operations blijft echter wel volledig in controle als het gaat om de configuratiesettings en beveiligingsparameters van het platform. Operations bepaalt namelijk welke versies van de OS-templates door haar goedgekeurd zijn en welke versies van de applicatie middleware daarop geautoriseerd zijn. In de portal wordt afgeschermd wie permissies heeft voor welke omgeving.
Ben je na het lezen van dit artikel benieuwd wat deployment automation in combinatie met cloud voor jou kan beteken? Ik sta open voor discussie of overleg.
Bart,
Nadenken over deployment moet zich niet alleen beperken tot technische levering van software maar ook de gebruikerskant in overweging nemen. Dat gezegd hebbende moet ik denken aan een oude getrouwe die nog steeds bruikbaar is, Kixtart heeft ondertussen leuke toevoegingen gekregen. Het uitrollen van software zelf is namelijk niet de grootste uitdaging maar het personaliseren ervan meestal wel.
Zeker bij business applicaties die autorisaties aan de achterkant vragen is dit nog een belemmerende factor in veel ‘self-service’ concepten. Uitdaging waar ik 2 jaar geleden tegen aan liep was een pull-based deployment waarbij recht gedaan moest worden aan de compliance eisen die niet aan de apparaten maar afdelingen en landen gebonden waren. Oplossingen zoals Xebia- of PuppetLabs lijken hier nog wat tekortkomingen te hebben omdat ze zich vooral richten op het apparaat in plaats van de gebruiker of de afdeling.
Ander punt waar ik 2 jaar geleden tegen aan liep is de administratie wat je volledig los van de infrastructuur kunt regelen door incident registratie maar dat geeft vaak een verkeerd beeld. Betreffende het opruimen van servers en applicaties ben ik benieuwd of dat ook de data betreft. Snelheid kan namelijk ook tegen je werken en vaak wil de business zelf het moment van uitrollen en updaten bepalen omdat verstoringen vooral geld kosten, zeker in ERP systemen.
Ik mis even het stukje dat je nu eenmaal niet zonder het functioneel en inhoudelijke testen van de professionals (owners) van die applicaties kunt.
Ik zie weinig terug van dat zeer belangrijke aspect.
Sneller
ja het zal best wel sneller kunnen maar dan zal de betreffende organisatie daartoe ook klaar moeten worden gemaakt en dan kom je pas werkelijk de bottlenecks tegen.