Support-afdelingen en helpdesks ondersteunen al jaren organisaties en gebruikers bij het dagelijkse onderhoud en beheer van een grote diversiteit aan applicaties. Met de komst van cloud-technologie is het goed om na te denken over de consequenties voor het onderhoud en beheer van applicaties uit de cloud. Eén van de voordelen van cloud-technologie is dat het organisaties de mogelijkheid biedt hun applicaties flexibel (waar of wanneer de gebruiker dit wil) aan te bieden aan de gebruikers. Flexibiliteit is ook het sleutelwoord voor de beheerorganisatie van deze applicaties omdat zij eenvoudig en snel de applicaties kunnen up- en downscalen. Deze mate van flexibiliteit zorgt wel voor nieuwe niveaus van onvoorspelbaarheid en andere verantwoordelijkheden in het beheerproces.
In dit artikel geven we een voorbeeld van een organisatie die een huidige marketingwebsite wil migreren naar het Windows Azure-platform en van de consequenties daarvan voor het onderhoud en beheer. Uitgangspositie is een wereldwijde marketingcampagne van deze organisatie die ‘mislukt' is doordat de bezoekersaantallen zo hoog waren dat binnen de kortste tijd de website niet meer goed functioneerde en zelfs offline gehaald moest worden. Behalve dat de campagne op deze manier geen succes werd, leed deze organisatie een behoorlijke imagoschade op.
Als we naar het huidige applicatiebeheer-proces voor het onderhoud en beheer van de marketingwebsite kijken dan is dit in orde. De website wordt gehost op de interne maar traditionele IT-infrastructuur. Nieuwe releases worden altijd via een OTAP (Ontwikkel-, Test-, Acceptatie- en Productieomgeving)-straat uitgerold. De verantwoordelijkheden op de diverse omgevingen zijn strikt gescheiden en de omgevingen zijn alleen toegankelijk voor geautoriseerd personeel. Het releasemanagement is ingericht om duidelijkheid te verschaffen over welke versie van de software in gebruik is en welke versie ontwikkeld wordt.
Nu is de organisatie wederom een nieuwe wereldwijde marketingcampagne aan het voorbereiden en wil een herhaling van de vorige misser voorkomen. De website moet grote aantallen bezoekers aankunnen en de organisatie wil niet flink investeren in extra servers etcetera. Inzicht in de kosten per omgeving is belangrijk evenals de kosten per server in de huidige IT-infrastructuur. Belangrijk is wel dat het testen en accepteren van de software en de manier van releases uitbrengen niet gaat veranderen ten opzichte van de huidige manier. Het Windows Azure-platform is onder de aandacht van de organisatie gebracht en klinkt als een mooie oplossing. Echter, de organisatie is benieuwd wat er gaat veranderen in de taken en verantwoordelijkheden van de applicatie-ontwikkelaars. Hoe gaat het deployment-proces eruit zien? Wat zijn de gevolgen voor releasemanagement? En zijn er nieuwe uitdagingen in het applicatiebeheerproces? De vragen worden in de volgende alinea's beantwoord.
Taken en verantwoordelijkheden van de applicatie-ontwikkelaars
Met Windows Azure kunnen ontwikkelaars tijdens het ontwikkelproces gebruik maken van de lokale ‘Compute Emulator' en de lokale ‘Storage Emulator' om de website te (door)ontwikkelen voor het Windows Azure-platform. Met deze emulators kunnen de ontwikkelaars op een traditionele manier ontwikkelen en kunnen ze tegelijk rekening houden met de eigenschappen die specifiek zijn voor Windows Azure. De eerste testen kunnen op de lokale ontwikkelomgeving plaatsvinden maar het is wel van belang dat de website ook goed getest wordt in een echte Windows Azure-omgeving voordat deze definitief naar de productieomgeving wordt uitgerold.
Het deploymentproces
Voor het deploymentproces heeft de organisatie twee verschillende Windows Azure accounts nodig. Eén account is nodig voor de testdoeleinden, het andere account is logischerwijs voor de productieomgeving. Belangrijk is om te regelen dat de verschillende omgevingen alleen toegankelijk zijn voor geautoriseerd personeel. Dus ontwikkelaars en testers hebben toegang tot het test-account en alleen personeel van het T-Infrateam heeft toegang tot het productieaccount. Hiermee is de scheiding in verantwoordelijkheden gelijk aan de huidige (traditionele) inrichting. Het grote voordeel is dat beide accounts standaard identieke omgevingen hebben, iets wat in de traditionele OTAP-omgeving vaak moeilijker te realiseren valt omdat meestal de volledige OTAP-omgeving zich niet binnen dezelfde IT-Infrastructuur bevindt. Uiteraard zijn de kosten per account (en dus per omgeving) duidelijk inzichtelijk omdat deze apart gefactureerd worden. In onderstaande afbeelding is de OTAP-omgeving voor een Windows Azure-omgeving schematisch weergegeven.
Gevolgen voor releasemanagement
Het ingerichte releasemanagementproces zal met de migratie naar Windows Azure niet wezenlijk veranderen voor de organisatie. Belangrijk bijkomend voordeel van de Windows Azure-oplossing is dat de organisatie alleen kosten krijgt doorberekend voor de testomgeving zolang deze in gebruik is. Wanneer er dus geen releases zijn en er geen noodzaak is om de testomgeving in de lucht te houden, kost de testomgeving helemaal niets.
Een nieuw beheerproces
Met de komst van cloud-technologie is er een aantal processen die de organisatie anders en deels nieuw zal moeten inrichten. Uiteraard kan Microsoft met al haar capaciteit en ervaring van online diensten de beschikbaarheid van het Windows Azure-platform veel beter garanderen dan de beschikbaarheid van een on-premise platform bij een willekeurige organisatie. Het inregelen van de werkzaamheden en afspraken over de beschikbaarheid worden geregeld in het subproces: Service Availability.
Naast beschikbaarheid is de zekerheid en de kwaliteit van de Windows Azure-omgeving van belang. Dit noemen we Service Assurance. De organisatie mag van Microsoft verwachten dat de kwaliteit gewaarborgd blijft en dat externe factoren geen invloed hebben op de dienstverlening. Het is dan ook van belang om met Microsoft goede afspraken te maken over de kwaliteit van de dienstverlening. Deze afspraken dienen te worden vastgelegd in een Service Level Agreement.
Het derde proces wordt Service Efficiency genoemd. Denk hierbij aan de mogelijkheden voor schaalbaarheid, monitoren, gemak en ondersteuning tijdens het deploymentproces.
De drie benoemde processen (Service Availability, Service Assurance en Service Efficiency) moet de organisatie bundelen in een nieuw beheerproces: "Managing Cloud Services".
Conclusie
De conclusie die we kunnen trekken is dat het bestaande releasemanagement en de deploymentprocessen niet drastisch zullen wijzigen met cloud-technologie. De processen neigen zelfs eenvoudiger te worden. Wat wel verandert zijn de taken en verantwoordelijkheden van de betrokken ontwikkelaars, system engineers en testers. Hoewel zij op de traditionele manier kunnen blijven ontwikkelen moeten zij nu ook, parallel, in een Windows Azure-omgeving ontwikkelen en/of testen.
De organisatie in zijn totaliteit geniet wel van meer voordelen als de huidige marketingwebsite naar het Windows Azure-platform wordt gemigreerd. De schaalbaarheid van de omgeving maakt het makkelijk om relatief eenvoudig de capaciteit te vergroten. Er is een gelijke test-, acceptatie- en productieomgeving. De kosten voor de omgeving zijn overzichtelijk en er wordt niet betaald voor omgevingen die niet gebruikt worden.
Tot slot zien we dat bij verschuivingen van traditionele applicaties naar cloud-oplossingen de inrichting van goede managementprocessen (of het gebrek eraan) nu sneller aan het licht komt. Het toevoegen van een cloud-oplossing aan een niet of slecht ingericht beheerproces voegt alleen maar meer complexiteit toe aan een al chaotisch geheel. Het opnieuw onder de loep nemen van het Application Lifecycle Management proces is dan ook geen overbodige luxe.
