Veel redenen kunnen leiden tot het bouwen van maatwerk op het Windows Azure cloud-platform van Microsoft. In veel gevallen zal het hierbij gaan om specifieke oplossingen die niet beschikbaar als Software as a Service. Maar het bouwen van een dergelijke oplossing vergt gedegen kennis. Bijvoorbeeld om te weten welke kant en klare services er standaard binnen het platform waarvan gebruik kan worden gemaakt en hoe deze toe te passen om een maximaal rendement te behalen van de cloud oplossing.
De eerste vraag die je jezelf zou moeten stellen is of het wel zinvol is een applicatie (deels) naar de cloud te brengen. De cloud moet geen doel op zichzelf zijn. De gebruikelijke ‘cloud-redenen’ spelen hier een rol: gewenste flexibiliteit, gegarandeerde beschikbaarheid, lagere TCO van een applicatie. Het doel moet allereerst worden vastgesteld. Vervolgens is het nodig bij elke beslissing en stap van het ontwerp en de bouw na te gaan of die bijdraagt aan het gestelde doel of de gestelde doelen.
Hier speelt eveneens mee wat de langetermijnvisie op de bewuste applicatie is. Gaat het om optimalisatie van bestaande performance en/of beschikbaarheid? Leeft de wens om gebruik te maken van extra services voor toekomstig gebruik? Of ligt het bijvoorbeeld ook in de bedoeling om data of functionaliteit te ontsluiten voor mobiele of andere toepassingen.
Architectuur
De verschillen tussen een applicatie die in het eigen datacenter of serverpark draait (on premise) en de cloud liggen vooral in de te hanteren architectuur. Vanwege de beweeglijkheid van de cloud, en de specifieke eigenschappen en mogelijkheden van het platform, gelden andere regels bij de bouw van een cloud-toepassing. Eén van de meest voorkomende fouten is dat men de architectuur van bestaande applicaties één op één overzet naar het Azure-platform. De architecturen verschillen dermate van elkaar dat de hoge verwachtingen van de cloud-implementatie misschien niet worden gehaald en er onvoldoende gebruik wordt gemaakt van de voordelen van het platform.
Dit houdt impliciet in dat er gedegen en specifieke kennis nodig is van het gebruikte cloud-platform. Niet alleen van de gewenste architectuur, maar ook van de services die standaard beschikbaar zijn op het Azure platform. Denk hierbij aan de services op het gebied van authenticatie en federatie, integratie, dataopslag en toegang voor mobiele applicaties. Met deze kennis kun je nagaan welke services passen om de vastgestelde doelstelling van de cloud te behalen. Waarvoor en wanneer ga je die services inzetten voor de te bouwen maatwerkapplicatie?
Integratie met on premise
Een extra complicatie kan zijn dat het soms wettelijk of technisch niet mogelijk of anderszins niet wenselijk is om een applicatie in zijn geheel in de cloud te plaatsen. Denk aan bedrijven die hun data niet in het buitenland mogen opslaan. Of er is sprake van privacygevoelige gegevens die niet buiten het eigen datacentrum mogen worden opgeslagen, of ook intensief worden gebruikt door on premise oplossingen. Maar toch wil je bijvoorbeeld de front-end van de applicatie die gebruik maakt van deze data in de cloud brengen vanwege de schaalbaarheid en beschikbaarheid van een cloud-oplossing. Er zijn ook gevallen waarin de kracht van het cloud-platform juist meer ligt op het vlak van dataverwerking in een back-end waarbij tijdelijk veel verwerkingscapaciteit nodig is.
In zo’n geval kies je voor een hybride oplossing en zal er zorgvuldig moeten onderzocht worden waar de scheiding tussen het cloud- en on premise-gedeelte van het systeem zal worden gelegd en hoe deze met elkaar zullen communiceren. Het Windows Azure-platform biedt veel mogelijkheden om applicaties in een hybride oplossing op netwerk-, service- of data-niveau te integreren. De juiste keuze, afhankelijk van het type interactie, beveiliging en de hoeveelheid en aard van de data, is cruciaal voor het slagen een hybride oplossing. Een verkeerde keuze kan leiden tot problemen op het gebied van performance, beveiliging, kosten of een beperkte functionaliteit.
Soms is het trouwens, gezien de technische staat van een applicatie, onmogelijk om deze in het geheel over te brengen naar de cloud. Dan dient eerst de vraag te worden beantwoord of het wenselijk is de applicatie geheel of gedeeltelijk on premise te laten draaien en aan te vullen met een gedeelte dat op Azure draait; of dat het simpelweg beter is een geheel nieuwe applicatie te ontwerpen en te bouwen.
Invloed cloud op de organisatie
Nieuwe ontwikkelingen brengen soms weerstand met zich mee binnen organisaties. Deze veranderingen liggen bij cloud-applicaties op verschillende gebieden. Allereerst zijn er de al eerder genoemde veranderingen op het gebied van architectuur en het deployment-model van een cloud oplossing. Voor de ontwikkelaars, die nog steeds gebruik blijven maken van hun bestaande ontwikkeltools en -talen, lijkt er relatief weinig te veranderen. Zij zullen vooral te maken krijgen met het gebruik van externe services die soms ook niet beschikbaar zullen zijn. Goede afhandeling en logging van dit soort en andere problemen is noodzakelijk voor de beheersbaarheid van de applicatie. Belangrijk voordeel van de cloud voor ontwikkelaars is dat er heel veel nieuwe services tot hun beschikking komen. Daarnaast kunnen ze zich in een Platform as a Service helemaal focussen op de functionaliteit van hun applicatie, omdat veel onderliggende platform-aangelegenheden door de cloud provider zijn geregeld.
Voor de applicatiebeheerders verandert er misschien nog wel het meeste. De systemen waarvoor ze verantwoordelijk waren worden nu immers vervangen door virtuele machines die ergens in een datacenter draaien en door anderen worden beheerd wat gevoelsmatig misschien zal worden ervaren als verlies aan controle. Beheer blijft evenwel nog steeds nodig, zij het dat dit op een hoger abstractieniveau gebeurt. Eigenlijk gaat het vooral om functioneel beheer: voldoet de applicatie nog steeds aan de business-wensen. Daarnaast zal het beheer van een steeds complexer wordende omgeving weer andere uitdagingen met zich mee brengen.
Hierin zie ik overeenkomsten die ontwikkelaars hebben meegemaakt door alle ontwikkelingen op het gebied van ontwikkeltools en frameworks. Daardoor zijn hun werkzaamheden al steeds abstracter geworden, maar daarnaast nam ook steeds de complexiteit en de functionaliteit van de systemen die ze bouwden in snel tempo toe.
Door de abstractie van het platform en het self service karakter van het cloud platform zal ook de grens tussen de activiteiten van ontwikkelaars en beheerders steeds meer vervagen. Ontwikkelaars dienen ervoor te zorgen dat de juiste informatie voor beheer beschikbaar komt; het gaat niet zozeer om de hoeveelheid gegevens, maar vooral om data die nodig zijn voor het beheer. Hiervoor is overleg met de beheerder nodig.
Aanpak
Tot slot nog iets over de aanpak van een dergelijk project. Na het bepalen van de doelstellingen begin je met het identificeren van de voor de bedrijfsvoering meest kritische onderdelen van de te bouwen applicatie. Vaak komen er uit verschillende onderdelen van de organisatie redenen om niet van Windows Azure gebruik te maken. In dat geval is het noodzakelijk om kortdurende Proofs of Concept in te richten om de twijfels over de migratie naar cloud weg te nemen.
Dan moet er een antwoord komen op de vraag of IaaS (Infrastrure as a Service) voldoet of dat PAAS (Platform as a Service) nodig is. Het eerste benut niet ten volle de cloud-voordelen en je blijft eigen verantwoordelijkheid over OS en middleware houden. Je zou IaaS toch kunnen overwegen als bepaalde, gewenste services niet in de cloud beschikbaar zijn. Overigens is op Azure een combinatie van beide mogelijk.
PaaS is het meest geschikt voor nieuwe applicaties of recente webapplicaties. Windows Azure PaaS beschikt over verschillende mogelijkheden voor websites, services en andere toepassingen, maar daarover later meer.
