Veel redenen kunnen leiden tot het bouwen van maatwerk op het Windows Azure-cloudplatform van Microsoft. In veel gevallen zal het hierbij gaan om specifieke oplossingen die niet beschikbaar zijn als software as a service (SaaS). 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 ‘cloudredenen’ 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 premises) 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 cloudtoepassing. 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 cloudimplementatie 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 cloudplatform. 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 premises
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 premises 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 cloudoplossing. Er zijn ook gevallen waarin de kracht van het cloudplatform 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 premises-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 premises 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 organisatie
Nieuwe ontwikkelingen brengen soms weerstand met zich mee binnen organisaties. Deze veranderingen liggen bij cloudapplicaties op verschillende gebieden. Allereerst zijn er de al eerder genoemde veranderingen op het gebied van architectuur en het deployment-model van een cloudoplossing. 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 (PaaS) helemaal focussen op de functionaliteit van hun applicatie, omdat veel onderliggende platformaangelegenheden door de cloudprovider 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 cloudplatform 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 nodig is. Het eerste benut niet ten volle de cloudvoordelen en je blijft eigen verantwoordelijkheid over besturingssysteem 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.
G.E.W.E.L.D.I.G. artikel Arie! Mooi onderbouwd, duidelijk opgesteld met de juiste informatie en inhoud. Veel mensen die zich een cloudconsultant noemen moeten naar mijn mening hier een voorbeeld aan nemen.
Vraagje: Als het hebben van een gedegen kennis een eis is om van Azure gebruik te kunenn maken (wat zeer terecht is) dan zou ik zeggen dat het gebruiken van deze dienst niet voor elke organisatie vanzelfsprekend kan zijn! Ben ik als organisatie afhankelijk van die externe consultant die me gaat advies geven? Laten we hopen dat hij met een juist advies komt waar ik achteraf geen spijt van krijg!
@redactie: ik denk dat jullie eindelijk iemand voor Tooling&Storage Expo hebben gevonden die kaas heeft gegeten van cloud en niet bezig is met domme marketing. Pin hem maar vast voor Storage/Tooling Event dit jaar, zou ik zeggen!
Inderdaad gedegen artikel.
Windows Azure is deels voor de automatiseringafdeling als het gaat om het virtualiseren van servers, maar de nadruk ligt op de software ontwikkelaar, die kan software bouwen en het laten landen op een elastisch, schaalbaar platform waarbij je betaald naar gebruik.
Wat nadelen kunnen zijn dat er nogal wat veranderd, cache is drie keer in twee jaar tijd veranderd en ook de identiteits- en toegangsbeheer mogelijkheden heen een hele reeks van aanvullingen en veranderingen gehad (acs, acs 2.0, ad fs, aad waad) evenals de middelen om on-premises en Windows Azure aan elkaar te verbinden. Het mooie en on-microsoft in deze is dat de veranderingen in een enorme stroomversnelling zitten. Dit geheel naar het voorbeeld van Amazon Webservices die elke week iets nieuws te melden heeft.
Het mooie is, is dat alles gericht is op zelfservice, zelfs de site zelf WindowsAzure.com staat boordenvol informatie OOK zelfs best practices als het gaat voor het opzetten van een robuuste veerkrachtige architectuur.
identiteit en toegangsbeheer vind ik overigens nog wel de zwakke plek. Er zitten nog allemaal haken en ogen aan en heeft veel ruwe kantjes. Voor dit onderdeel alleen heb je een specialist nodig en is een vak op zich. Dingen die een maand geleden nog werkten, zijn een ineens weer op de schop genomen. Goed, want door snelle verbeteringen wordt het snel beter, maar frustrerend als je ziet wat een tijd erin gaat zitten.
@Henri
Zou je de zin: “…want door snelle verbeteringen wordt het snel beter, maar frustrerend als je ziet wat een tijd erin gaat zitten.” uit kunnen leggen. Op mij komt deze een beetje over als dat het allemaal nog niet zo goed overdacht is, beetje als trail-and-error.
Nu schrijft Arie dat beheer meer op functioneel niveau zal komen te liggen, de self-service van de business welke vaak als argument gebruikt wordt voor SaaS. Maar wat je niet weet kun je niet beheren en dus zie je dat dit soort omgevingen onderhouden worden door de programmeurs die dus weing affiniteit hebben met beheer.
Of zoals Arie schrijft: “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.”
Maar dat blijft meestal achterwege want beheerders communiceren niet omdat ze het te druk hebben met herstellen van gebruikersfouten. In reactie op het stuk van Gijs gaf ik een link naar een rapport van de AberdeenGroup over niet genoemd nadeel van SaaS, verlies van data.
P.S.
Ook ik vind dit een goed stuk omdat het beide kanten van medaille laat zien, glanzende kant van nieuw en de roestige van ouderwets. Want beheer is misschien conservatief maar je kunt het alleen verschuiven, niet negeren.
Ewout,
‘Vroeger’ duurde het een tijd voordat functionaliteit werd aangepast, maar vroeger gingen ontwikkelingen niet zo snel. Microsoft wil in mijn ogen spot-on blijven en aangezien Amazon ook zeer snel ontwikkelt (of kijk naar de diensten van Google), wordt Microsoft wel een beetje gedwongen om hierin mee te gaan, maar de gevolgen zijn wel dat er nogal eens dingen ineens niet of anders meer functioneren, functionaliteit ineens verplaats of anders wordt of dat je de laatste maand maand aan research voor niets hebt gedaan omdat er al weer afscheid van genomen wordt. Dus ja, sommige dingen gaan wat trial-and-error. Wel moet ik zeggen dat de verbeteringen steeds beter worden. Azure twee jaar geleden was in mijn ogen niet goed genoeg en zat onlogisch in elkaar. Ook kon je niet even spelen, want al snel moest de credit card getrokken worden en kon je een dienst niet eens op pauze zetten.
Overigens zijn er zeer veel mogelijkheden voor (.NET) software ontwikkelaars om gratis of goedkoop vlieguren te maken met Windows Azure. Vooral het BizSpark programma is echt een aanrader! Maar ook bij MAP Design en Development (350 euro per jaar) voorziet naast veel software ook veel kortingen op Windows Azure.
Het beheren van PaaS, ofwel het Cloud Services onderdeel van Windows Azure (en in mijn ogen het hart van de dienst) zit erg goed in elkaar en vergt weinig systeem beheer. Databases vallen daar echter buiten en dus heb je wel degelijk met beheer te maken, maar is dit wel iets waarbij ontwikkelaars en beheerders samen moeten werken. Zonder inzicht in hoe de applicatie architectuur is opgezet zal de beheerder weinig kunnen doen. Dat is denk ik waar Arie op doelt.
Daarnaast blijft er nog genoeg te beheren en te monitoren over. zeker op het gebied van On-premises en cloud en identiteitsbeheer zijn er nog genoeg uitdagingen 🙂
Ook het op en neer schalen is iets wat je deels kunt automatiseren, deels is dit echt iets wat bij beheer thuis hoort.
Wat ik Microsoft na moet geven is dat ze veel meer open staan voor niet Microsoft dingen. Linux kun je virtualiseren, maar ook het hosten van PHP sites en MySQL databases zit erin en die openheid is volgens mij wel een troef. Ook op het gebied van identiteit en toegang zie je dat WAAD (http://www.windowsazure.com/en-us/services/identity/) bijvoorbeeld OAUTH 2.0 toegang toestaat en kun je tegenwoordig in veel talen zoals Ruby en Java dingen doen op Windows Azure. Dit is echt een shift van Microsoft. Aan de ene kant moeten ze, maar ze doen het ook nog eens op een zeer goede manier.
Veel mensen denken nog steeds dat Windows Azure een MS Only feestje is.
Zowel een ontwikkelaar als een beheerder kan zich dagen vermaken op de site die er clean uitziet en echt bijzonder veel hoogwaardige informatie verschaft. Er is veel aandacht gegeven in het erg toegankelijk maken van de materie. Niettemin blijft er nog genoeg te klagen over 🙂
De database dienst die SQL Server aanbiedt is nog niet gecertificeerd (naar mijn weten) en bevat nog genoeg ruwe kantjes. 1 daarvan is bijvoorbeeld dat je last kan hebben van slechte buren en dat de performance wisselend is. Ook voor het backuppen van deze databases moet je zelf dingen bouwen.
Een laatste punt van aandacht is de marktplaats (App services of Add-ons). Veel belovend, maar nog echt in de kinderschoenen.
@Henri
Buiten dit platform om hebben we al eens discussie gevoerd over MySQL, PHP en Azure waarbij de uitkomst als ik het me goed herinner niet in het voordeel van Microsoft was. En dat Microsoft mee gaat met de markt omdat er meer kleuren zijn dan zwart lijkt me logisch, vraag hier is natuurlijk wel welke migratie trajecten er nu precies ondersteunt worden want ik vermoed dat het uiteindelijk wel een ‘one-way’ trip is.
Maar je hebt zelf al meermaals gezegd dat vandaag de legacy van morgen gemaakt wordt en dat is voor de cloud niet anders. Vaak kost het migreren naar de cloud dan ook inderdaad bijna niets maar betaal je wel de ‘hoofdprijs’ als je er weer uit wilt. Het zou goed zijn als je ook eens rapport: ‘Cloud for Business Managers: the Good, the Bad and the Ugly’ leest.
Er zijn namelijk ook nog weleens non-functionele redenen om niet, gedeeltelijk of voor iets anders dan Azure te kiezen. Dat de cloud soms als een oplossing gezien wordt voor organisatorische problemen is namelijk nog weleens een dure fout. Maar ik val in herhaling als ik zeg dat de cloud mogelijkheden biedt maar geen wonderen en vergeet ook niet de presentatie:
http://www.slideshare.net/edekkinga/get-your-house-on-order