15/1/2010 Versie: 1.0 Opdrachtgever: Rody Middelkoop MINOR EAD CLOUD COMPUTING Cloud Computing en Enterprise Application Development Studenten: Thijs Smeenk Joris Peters Matthijs Bloemendal Student nr.: 425900 427043 426549
REVISIEHISTORIE Versie Datum Wijziging 0.1 17-11-2009 Structuur en inhoudsopgave opgezet. Al uitgewerkte stukken ingevoegd. Scenario s uiteengezet en omschrijving uitwerken. 0.2 15-12-2009 Uitwerkingen hoofdstuk 4 ingevoegd. 0.3 18-12-2009 Gedeelte scenario s aangepast. Hier moet nog veel bijgevoegd worden. 0.4 09-01-2010 Scenario multicloud, Security met ACS en Cloud platforms aangepast. Tevens Enterprise Applicaties hoofdstuk uitgebreid met eisen. Schaalbaarheid aangevuld. 0.5 14-01-2010 Bronnen ingevoegd en begrippen geïdentificeerd. Scenario public back-end samengevoegd met public data en ingevoegd. Inleiding toegevoegd. 1.0 15-01-2010 Scenario s public cloud & batch verbeterd/ingevoegd. Revisie over public storage gedaan. Bijlage ingevoegd. Voorwoord, managementsamenvatting en conclusie ingevoegd. Begrippenlijst ingevoegd. Pagina 2
VOORWOORD In september van het jaar 2009 zijn wij als projectgroep een onderzoek gestart naar de invloeden van Cloud Computing in het kader van de minor Enterprise Application Development. Uit een selectie onderwerpen zijn wij uiteindelijk tot Cloud Computing gekomen, omdat het een term is die steeds meer naar voren kwam in de IT sector. Het leek ons dan ook interessant hier meer over te weten te komen en om zo te onderzoeken of de hype terecht is. Vanuit de opdrachtgever kwam de behoefte naar informatie over dit onderwerp ook naar voren, met als doel het informeren van andere studenten. Vanuit dit startpunt zijn wij het onderzoek gestart. De projectgroep bestaat uit de studenten Thijs Smeenk, Matthijs Bloemendal en Joris Peters van de Hogeschool Arnhem en Nijmegen. Begeleiding werd hierbij verzorgd door dhr. Rody Middelkoop, tevens was hij de opdrachtgever. Inmiddels, halverwege de eerste maand van 2010, is het onderzoek ten einde gelopen en is het onderzoeksrapport voltooid. Graag presenteren wij u dit rapport! Onze dank gaat uit naar de Hogeschool Arnhem en Nijmegen, en in het bijzonder Rody Middelkoop, voor de faciliteiten, adviezen en ondersteuning die het project naar onze mening in goede banen hebben geleid. Ook het bezoek aan het SOA Symposium was een leerzame onderneming. Tot slot hopen wij met dit onderzoek een nuttige bijdrage te hebben geleverd aan de informatievoorziening voor studenten, voornamelijk van de minor EAD. Wij hopen dan ook dat dit rapport in de toekomst van pas zal komen. Pagina 3
MANAGEMENTSAMENVATTING Dit rapport beschrijft het onderzoek naar de invloeden van Cloud Computing op Enterprise Applications. Het is uitgevoerd door een onderzoeksgroep van de minor Enterprise Application Development onderdeel van de opleiding Informatica van de Hogeschool van Arnhem en Nijmegen De hoofdvraag die dit rapport beantwoord is: Welke invloed heeft Cloud Computing op de ontwikkeling van Enterprise Applicaties? Om deze vraag te kunnen beantwoorden zijn meerdere deelvragen opgesteld, die verdeelt zijn in verschillende categorieën. Deze staan niet expliciet vermeldt in het rapport, maar vormden wel de leidraad waarop dit rapport is gebouwd. Dit was tevens het startpunt van dit onderzoek. Aan de hand van deze deelvragen en de onderzoeksstrategie is een hoofdstukindeling gemaakt. Allereerst is duidelijk gemaakt wat Cloud Computing is en waarvoor, waarom en hoe het gebruikt kan worden. Er is begonnen om bronnen over dit onderwerp te zoeken, dit zorgde voor een goede beeldvorming om de rest van het onderzoek aan op te hangen. Om te weten te komen wat belangrijk is bij de ontwikkeling van Enterprise Applicaties (hierna EA) is vervolgens onderzocht wat een EA eigenlijk is en wat belangrijke eisen zijn die aan een EA worden gesteld. Hierna is er dieper gekeken op de combinatie van Cloud Computing en het ontwikkelen van Cloud gerichte applicaties. Hiermee is behalve uit bronnen, ook informatie uit de praktijk gehaald. Om de hoofdvraag goed te kunnen beantwoorden zijn vervolgens verschillende scenario s opgesteld. Deze scenario s zijn praktische voorbeelden waarin Cloud Computing toegepast is. Deze zijn ook gedeeltelijk praktisch uitgewerkt. Aan de hand hiervan is uitgezocht van welke invloeden er op de ontwikkeling van Enterprise Applicaties er sprake is. De geïdentificeerde invloeden zijn: De vorm waarin Cloud Computing toegepast wordt (Public Cloud, Hybride vorm of Private). De Cloud aanbieders. Met name de mogelijkheden en beperkingen verschillen sterk per aanbieder. Om een applicatie geschikt te maken voor Cloud Computing en om van de voordelen gebruik te kunnen maken moet de applicatie wel aan specifieke eisen voldoen. Met name op het gebied van schaalbaarheid en beheersbaarheid moet er rekening gehouden worden bij de ontwikkeling. De conclusie kan als volgt samengevat worden: Het ontwikkelen van een Cloud (Enterprise) applicatie (of het omzetten naar een Cloud) moet toegespitst worden op de vorm van toepassing en de Cloud aanbieder. Lang niet iedere applicatie is geschikt om de voordelen van Cloud Computing te ervaren. Specifieke eisen of beperkingen, van Cloud Computing of Cloud aanbieders, aan de inrichting van een Enterprise Applicatie voorkomen dit. Wordt aan deze eisen voldaan, dan biedt Cloud Computing een elastische (schaalbare), beheersbare omgeving die geschikt is voor Enterprise Applicaties. Pagina 4
INHOUDSOPGAVE Revisiehistorie... 2 Voorwoord... 3 Managementsamenvatting... 4 1. Inleiding... 6 2. Cloud Computing... 7 2.1. Wat is het?... 7 2.2. Toepassingsvormen Cloud Computing... 8 2.3. Hoe werkt het?... 9 2.4. Voordelen en gevaren... 11 2.5. Huidige toepassingen... 14 3. Enterprise Applicaties... 15 3.1. Wat is het?... 15 3.2. Eisen... 16 4. Cloud Ontwikkeling... 17 4.1. Cloud platformen... 17 4.2. Data storage... 21 4.3. Security... 23 4.4. Testen... 26 4.5. Lifecycle... 27 5. Enterprise Applicaties & Cloud Computing... 29 5.1. Public Cloud... 29 5.2. Public Batch... 32 5.3. Cloud Storage... 34 5.4. Multicloud... 37 6. Conclusie... 39 7. Begrippen... 40 8. Bibliografie... 45 I. Bijlage The NIST Definition of Cloud Computing... 47 Pagina 5
1. INLEIDING Cloud Computing is geen onbekende term meer in het IT landschap. Er wordt veel over gesproken en met grote interesse naar gekeken. Er verschijnen steeds meer aanbieders van Cloud diensten en ook grote analysebedrijven als Gartner publiceren dat Cloud Computing iets is om in de gaten te houden. Toch bestaan er veel misverstanden over wat Cloud Computing precies inhoud. Vanuit de opleiding Informatica en de minor Enterprise Application Development (EAD) werd dan ook gevraagd om HBO informatica studenten te informeren over de mogelijke toepassingen van Cloud Computing binnen Enterprise Applicaties. In dit rapport zal dit aan de hand van de volgende hoofdvraag gebeuren: Welke invloed heeft Cloud Computing op de ontwikkeling van Enterprise Applicaties? Om deze vraag te kunnen beantwoorden zijn meerdere deelvragen opgesteld, die verdeelt zijn in verschillende categorieën. Deze staan niet expliciet vermeldt in het rapport, maar vormden wel de leidraad waarop dit rapport is gebouwd. Dit was tevens het startpunt van dit onderzoek. De hoofdstukindeling vertoont overeenkomsten met de onderzoeksstrategie die gehanteerd is. Allereerst wordt duidelijk gemaakt wat Cloud Computing is en waarvoor, waarom en hoe het gebruikt kan worden. Om te weten te komen wat belangrijk is bij de ontwikkeling van Enterprise Applicaties (hierna EA) wordt in het volgende hoofdstuk uiteengezet wat een EA eigenlijk is en wat belangrijke eisen zijn die aan een EA worden gesteld. Deze twee hoofdstukken zijn voortgekomen uit het vinden van informatiebronnen in de eerste periode van het onderzoekstraject. In het vierde hoofdstuk wordt gekeken naar de ontwikkeling van Cloud Applicaties. Hierbij wordt informatie uit de praktijk gecombineerd met die van informatiebronnen. Er was op dit gebied niet veel concrete informatie te vinden, bleek ook uit het bezoek aan het SOA Symposium van 2009 te Rotterdam. Daarom is er in dit hoofdstuk eigen ervaring, opgedaan tijdens het onderzoekstraject, verwerkt. In het laatste hoofdstuk wordt toegespitst op de combinatie van Cloud Computing met de ontwikkeling EA. Aan de hand van diverse scenario s waarin Cloud Computing toegepast kan worden, wordt een analyse gemaakt van de toepasbaarheid en verschillende aspecten die bij de ontwikkeling komen kijken. Dit is ook gedeeltelijk voortgekomen uit het zelf nabootsen van het scenario in een practicum. Dit heeft geleid tot een conclusie waarin de hoofdvraag beantwoord wordt en daarbij dus een inzicht wordt gegeven in de ontwikkeling van Cloud Applicaties. Met de hierbij komende voor- en nadelen in de vorm van mogelijkheden of juist beperkingen. Pagina 6
2. CLOUD COMPUTING Dit hoofdstuk is de eerste kennismaking met Cloud Computing. Hierin wordt het concept uitgelegd en toepassing ervan gegeven. Kortom: wat is het, hoe werkt het en waarvoor kan het gebruikt worden. 2.1. WAT IS HET? Cloud Computing is een model dat gebruikers in de gelegenheid stelt om gebruik te maken van een verzameling van resources (netwerken, servers, opslag etc.) die verwerkingskracht aanbieden. Deze verwerkingskracht is dynamisch schaalbaar op een zo veel mogelijke autonome wijze. Volgens de definitie van het National Institute of Standards and Technology (Bijlage I, p47) heeft een Cloud vijf essentiële kenmerken: On-demand self service: Het oproepen van verwerkingskracht zonder dat hierbij menselijke interactie vereist is met elke individuele service provider. Broad network access: Toepassingen zijn toegankelijk via een netwerk d.m.v. al bestaande methoden. Dit houdt de toegankelijkheid voor heterogene thin en thick platformen hoog. (laptops, mobiele telefoons, etc.) Resource Pooling: De verwerkingskracht van de Cloud provider wordt samengebracht tot één poule en aangeboden aan de gebruiker. Deze resources zijn niet gebonden aan één locatie en over het algemeen zal het niet bekend zijn welke resource er gebruikt wordt. Rapid elasticity: Verwerkingskracht kan snel en elastische aangeboden worden. Voor de gebruiker zal dit proces niet te merken zijn en wordt de indruk gewekt dat het systeem eindeloos kan schalen. Aan het schalen worden door Cloud aanbieders doorgaans kosten verbonden. Measured service: Resource gebruik wordt bewaakt en gecontroleerd door de Cloud aanbieder. Het gebruik van de Cloud wordt hierdoor transparant voor zowel de aanbieder als de gebruiker. De term Cloud vindt zijn oorsprong in het bekende wolk symbool wat vaak als representatie voor het internet wordt gebruikt. Het is, zoals bij het internet, een abstractie voor de onderliggende infrastructuur. Het is op voorhand niet te bepalen welke resources er gebruikt gaan worden door de Cloud en wat de locatie hiervan is. Dit brengt wel politieke complicaties met zich mee aangezien de Cloud grenzen overschrijdt en op deze manier verzeilt raakt in complexe nationale belangen. Het paradigma zelf is al in ontwikkelingen sinds de jaren zestig. Toen der tijd sprak John McArthy al over verwerkingskracht aangeboden als publieke service (Wikipedia.c). De ontwikkeling splitste zich vervolgens op in meerdere takken wat enigszins de verdeeldheid verklaard die er heerst over wat nu daadwerkelijke een Cloud is. Rond de jaren negentig als de ontwikkeling van computersystemen in een stroomversnelling raakt wordt Cloud Computing voor het eerst commercieel gebruikt. Door de toegenomen bandbreedte en de verdere ontwikkelingen op het gebied van internet worden de toepassingen steeds interessanter voor commercieel gebruik. In 1999 start het bedrijf SalesForce (Wikipedia.d)dat een pionier gaat worden op het gebied van Cloud Computing. Het bedrijf maakt het mogelijk voor bedrijven om gebruik te maken van applicaties via het internet waarbij installatie en eigen rekenkracht niet meer nodig is. De volgende stap wordt genomen door Amazon (Wikipedia.c) die de overcapaciteit van haar eigen datacenters gaat verkopen en daarmee een van de eerste aanbieders wordt. Rond 2007 raakt Cloud Computing in een stroomversnelling als meerdere grote partijen gaan meedingen om de eer, zoals Google (Google Docs, Google AppEngine), Microsoft (Azure en Live services) en Sun. Ten tijde van dit onderzoek is Cloud Computing dan ook een paradigma wat nog volop in ontwikkeling is. Pagina 7
2.2. TOEPASSINGSVORMEN CLOUD COMPUTING Cloud Computing heeft geen gestandaardiseerde vormen waarin een Cloud gedefinieerd kan worden. Er zijn meerdere pogingen gedaan om hier aan te voldoen waarbij vaak verschillende gekeken wordt naar of welke dienst de Cloud aanbiedt of hoe deze aangeboden wordt. Als we deze indeling aanhouden zien we desondanks een zevental vormen naar voren komen waarin praktische elke Cloud gedefinieerd kan worden. Door combinaties te maken tussen twee types uit de subcategorieën wordt het mogelijke om Clouds te typeren. HOE EEN CLOUD AANGEBODEN KAN WORDEN In Bijlage I staan op pagina 44 verschillende mogelijkheden uiteengezet. Private De Cloud dienst is uitsluitend bestemd voor een organisatie of gesloten gebruikers groep. Beheer kan in handen zijn van de organisatie zelf of een derde partij. De locatie is niet per se gebonden aan de organisatie. Denk aan Microsofts privé Cloud. Public De Cloud is beschikbaar aan een grote groep gebruikers die eventueel vrij toegang hebben tot de Cloud. Beheer is in handen van een partij die de Cloud diensten aanbiedt. Bijvoorbeeld Google s GMail of de AppEngine. Community Verglijkbaar met de private Cloud alleen wordt hier de toegang gedeeld tussen verschillende groepen die een eenduidig belang hebben. Dat kan tussen verschillende organisaties gaan of andere vormen van georganiseerde gebruikersgroepen. Locatie en beheer van de Cloud zijn niet specifiek gebonden aan de gebruikers. Hybrid Een combinatie van de hierboven genoemde typen van Clouds in welke vorm dan ook. Voorwaarde is dat de Clouds hun eigen identiteit behouden. Er vindt dus communicatie plaats tussen de onderling verschillende Clouds. Op deze wijze kan bijvoorbeeld loadbalancing plaats vinden. WAT KAN EEN CLOUD AANBIEDEN? De volgende drie punten worden topdown besproken. Om SaaS aan te bieden is het namelijk nodig om daarnaast PaaS en IaaS aan te bieden. Daarnaast is het voor PaaS nodig om op een infrastructuur te functioneren en moet er dus IaaS aangeboden worden. SaaS Het welbekende Software as Service principe. Hierbij bied de Cloud een applicatie(s) aan waarvan via bijvoorbeeld een web browser gebruik gemaakt kan worden. Eén van de grote voorbeelden op dit vlak is SalesForce die zich als doel gesteld heeft om kantoor applicaties via de Cloud aan te bieden. Daarnaast is ook Google een bekende aanbieder van SaaS met bijvoorbeeld GMail en GoogleDocs. PaaS Bij Platform as Service wordt een specifiek platform aangeboden via de Cloud. Bekende voorbeelden op dit vlak zijn Microsofts Azure en Googles AppEngine. Beiden bieden een platform aan waarop applicaties ontwikkeld en daarnaast ook in de Cloud kunnen geplaatst kunnen worden. Pagina 8
IaaS Infrastructure as Service biedt de verwerkingskracht van een infrastructuur aan via de cloud. Een van de bekende aanbieders op dit vlak is Amazon. Amazon biedt de overcapaciteit van haar datacenters aan als extra verwerkingskracht die aanspreekbaar is via hun Cloud voor bepaalde tarieven. FIGUUR 1: CLOUD VORMEN 2.3. HOE WERKT HET? Nu er duidelijk bestaat over wat Cloud Computing eigenlijk is, wordt hier besproken hoe het werkt. Wat gaat er schuil achter Cloud Computing? En welke technieken maken Cloud Computing mogelijk? COMBINEREN VAN COMPUTERKRACHT Cloud Computing biedt gebruikers 'oneindige' on-demand resources. Dit betekent dat als een applicatie in de Cloud meer processorkracht nodig heeft, dit gegeven kan worden en indien dit niet (meer) nodig is, dan kan dit weer verlaagd worden. Om deze processorkracht (of computing ) beschikbaar te stellen wordt eigenlijk voortgeborduurd op het principe van Grid Computing. Grid Computing houdt in dat computerprocessen gedeeld kunnen worden over meerdere servers of computers. Dit wordt vooral toegepast door erg ingewikkelde en grootschalige berekeningen te verdelen over meerdere computers die op het moment niets doen ( idle zijn). Door die processorkracht te gebruiken en combineren werd de performance vergroot. Deze groep van samenwerkende computers/servers wordt een 'Grid' genoemd. Voor Cloud Computing wordt dit Grid principe gebruikt om een enorme hoeveelheid data aan te kunnen. Alle computers en datacenters vol met servers die aangesloten zijn op de Cloud delen alle processorkracht en dataopslag. Dit maakt on-demand performance en een zeer grote hoeveelheid opslagruimte mogelijk. Een begrip dat tevens van toepassing is bij Cloud Computing is Utility computing. Op Wikipedia (Utility Computing Wikipedia) staat de volgende definitie: Utility Computing is the packaging of computing resources, such as computation and storage, as a metered service. Grid maakt het mogelijk om computerkracht te combineren en Utility is het systeem om dit aan te bieden aan gebruikers/klanten. Dit vormt de backbone van Cloud Computing, namelijk Infrastructure as a Service (IaaS). ELASTICITEIT Een term die vaak in één mond genoemd wordt met Cloud Computing is elasticiteit. Zoals eerder vermeld, biedt de Cloud on-demand computing. Zo is het mogelijk om elastisch om te gaan met de server kracht die nodig is. Deze elasticiteit wordt mogelijk gemaakt door het hiervoor genoemde Grid Computing en hieronder ligt ook een andere techniek schuil, namelijk virtualisatie. Pagina 9
Virtualisatie wordt al veel gebruikt in IT systemen (Gartner.a, 2008). Het biedt de mogelijkheid om meerdere fysieke servers te laten lijken alsof het één server is, onafhankelijk van hun locatie of configuratie (Turban, 2008). Dit kan ook omgekeerd worden toegepast, het onderverdelen van één fysieke server in meerdere individuele stukken. Er is dus niet bekend wat er zich precies achter deze servers bevindt, deze worden verborgen. Deze techniek ondersteunt ook het dynamisch aanpassen van deze servers en helpt daarom mee in het realiseren van de elasticiteit en schaalbaarheid die Cloud Computing kan bieden. INFRASTRUCTUUR CLOUD Een Cloud is, zoals eerder genoemd, een metafoor voor het Internet. Cloud Computing gaat ook zeker verder waar het Internet ophoudt. Het is meer dan een verzameling servers die met elkaar kunnen communiceren, het gaat verder dan webpagina s. De onderste laag van Cloud Computing zijn uiteraard de servers. In dit hoofdstuk is Grid en Utility Computing benoemd als belangrijke factoren in de infrastructuur van Cloud Computing. Ook zijn de termen SaaS, PaaS en IaaS al bekent. In Figuur 2: Cloud computing structuur die hiernaast is weergegeven, staat hoe deze een gelaagdheid vormen die samen de toepassingen van Cloud Computing mogelijk maken. Ook zijn er enkele voorbeelden van de toepassingen gegeven. FIGUUR 2: CLOUD COMPUTING STRUCTUUR TOEPASSEN CLOUD Binnen Cloud Computing spelen services dus een uitermate grote rol. Een samenwerking van services over de hele laag is in principe mogelijk en bij het beschikbaar stellen van een applicatie is er de beschikking over een grote hoeveelheid opslag, processorkracht en schaalbaarheid. Een applicatie kan 'deployed' worden in de Cloud en zo beschikbaar gemaakt worden, zonder gebruik te hoeven maken van een aparte applicatie of webserver en iedereen kan dit gebruiken. Hierbij spelen nog enkele factoren een rol. Één daarvan is locatie. De Cloud is een samensmelting van servers, waar blijft de applicatie of data fysiek dan? Dat is dus onduidelijk, omdat je nooit de fysieke locatie van de bepaalde server (of virtualisatie) weet. Dit maakt voor veel dingen niet uit, maar bij gevoelige data kan dit parten spelen. Wil de Belastingdienst gevoelige data wel in (bijvoorbeeld) Afghanistan of Kenia hebben staan? Dingen als security, privacy en natuurlijk garantie van bereikbaarheid gaan dan een grote rol spelen. Een andere factor is de prijs. Over het algemeen wordt het principe 'pay-as-you-go gehanteerd. Verbruikt de applicatie veel resources of wordt deze enorm veel gebruikt, dan wordt meer betaald dan wanneer de applicatie minder doet. Dit kan financieel zeer voordelig zijn tegenover het alternatief, namelijk het moeten kopen van servers (met een limiet) aan de hand van het aantal gebruikers. Deze servers zullen een groot gedeelte van de tijd niet volledig benut worden, dus zijn er servers gekocht voor een maximale load die waarschijnlijk nooit gehaald wordt. Pagina 10
SAMENGEVAT De Cloud bestaat uit een internet van vele servers en computers waarin gedeelde processen en data opslag plaatsvinden. De principes van Grid Computing maken het mogelijk om processen te verdelen tussen alle servers in de Cloud. Dit maakt een hoge schaalbaarheid mogelijk door de grote hoeveelheid processorkracht en opslag die beschikbaar is. Aan de hand van gebruik van een applicatie kan dit verbruik van resources aangepast worden, wat on-demand performance mogelijk maakt. In de Cloud bevinden zich services, bijvoorbeeld van een bepaalde aanbieder. Als gebruiker kun je verbinding naar de Cloud maken en deze gebruiken. Deze services onderscheiden zich in de types SaaS, PaaS en IaaS. 2.4. VOORDELEN EN GEVAREN Niet iedereen gebruikt nog Cloud Computing, al wordt het in toenemende mate populairder en meer geaccepteerd (Gartner.b, 2009). In deze paragraaf worden enkele voordelen uiteengezet en ook gevaren uitgelicht waar rekening mee gehouden moet worden bij het toepassen van Cloud Computing. HOSTING, ONTWIKKELING EN BEHEER Als bedrijf een applicatie hosten, of deze nou groot of kleine is, vraagt om infrastructurele eisen en ook hardwarematige eisen. Ook bij de ontwikkeling en het beheer van applicaties komt veel werk en (dus) geld bij kijken. Cloud Computing kan dingen uit handen nemen van het bedrijf. Welke voor- en nadelen zitten hieraan? Iedere ontwikkelaar die een Enterprise applicatie heeft ontwikkeld of onderhouden weet dat er vaak een aardige stack software voor nodig is. Van een Operating System,.Net framework, Java Development Kit tot database software en nog veel meer middleware. Dit moet allemaal aangeschaft of gedownload worden en vervolgens ook beheerd worden. Wat als we naar een ander OS willen, een nieuwe.net/java versie of welke andere software dan ook willen upgraden, wie zorgt ervoor dat het hele systeem niet in elkaar valt? Vele ontwerpbeslissingen en investeringen later kan de applicatie ontwikkeld worden. Met Cloud Computing is het mogelijk om gelijk te beginnen met de ontwikkeling en niet stil te staan bij het aankopen van een software stack of beslissen waar de stack uit gaat bestaan. Je hebt een set middelen en die is bij de Cloud aanbieder in beheer. Ontwikkelen wordt makkelijker doordat er geen rekening meer gehouden hoeft te worden met randzaken, maar puur het ontwikkelen zelf. Geen compatibiliteitsproblemen of een dure softwarestack, maar een cloud platform waar veel software al in zit en de cloud aanbieder (provider) regelt de updates van je stack. Servers en serverruimtes zijn erg duur. Er wordt betaald voor een serverpark dat waarschijnlijk niet eens volledig benut wordt. Ook dit wordt sterk door Cloud Computing verbeterd. In 2.2 is te lezen in welke vormen Cloud Computing toegepast kan worden. Een belangrijk onderdeel van Cloud Computing is IAAS. Dit heeft als voordeel dat een bedrijf zelf niet over servers hoeft na te denken of te beheren, maar dat alles in handen is van de Cloud (aanbieder). Een bedrijf betaalt alleen voor wat er gebruikt wordt (pay-as-you-go). Geen dure serverparken meer die maar weinig benut worden, maar aanpassen aan de behoefte van het moment. Een erg groot voordeel, zeker voor grote bedrijven met veel servers. Cloud Computing maakt het dus mogelijk om dit allemaal uit handen te geven. Er hoeft dus geen zorgen gemaakt te worden over software upgraden of over het beheer van de gehele software stack. Ook het gebruik van hardware, load of server ruimte is volgens het Cloud Computing model geen enkel probleem meer. In dit opzicht is Cloud Computing een erg goede uitkomst, maar er zitten natuurlijk niet enkel voordelen aan op dit gebied. Alles uit handen geven en het niet in eigen beheer hebben is niet altijd een goede ontwikkeling. Er treedt een sterke afhankelijkheid op met de cloud provider. De software die gebruikt wordt, de hosting, mogelijk ook de data, is allemaal in handen van een derde partij. Het is belangrijk dat de provider een garantie kan geven over de bereikbaarheid en stabiliteit van de applicatie of service die het aanbiedt. Deze afhankelijkheid kan ook leiden tot een vendor lock-in. Is migreren naar een andere provider nog wel mogelijk? Of communiceren met andere applicaties, legacy systemen of een andere Cloud? Deze vragen komen nog aan Pagina 11
bod in dit rapport, maar het blijven zaken waar een bedrijf rekening moet houden als het overweegt om te migreren naar de Cloud. DATA De waarde van het bedrijf zit in de data die het heeft. De belangrijkste bezitting uit handen geven en in een publieke Cloud laten hosten is best een stap. In bepaalde gevallen (van bijvoorbeeld gevoelige informatie) wil een bedrijf dat misschien liever niet. Bovendien weet niemand waar de server (of meerdere) zich bevindt. Hierbij komt ook wetgeving om de hoek kijken, want in bepaalde landen kan het heel goed zijn dat er mindere op privacy wordt gelet. En als de data toevallig in een dergelijk land op een server staat kan dit een risico opleveren. Tevens is er ook hier sprake van database afhankelijkheden. Iedere Cloud provider zal een ander type database gebruiken waar de data in zit. Migreren wordt wederom een probleem, zowel van een bestaande applicatie naar de cloud, als een nieuwe applicatie naar een andere provider. SCHAALBAARHEID In de vorige paragraaf is schaalbaarheid al even naar voren gekomen. Voornamelijk elasticiteit van computing is een sterk voordeel van de Cloud. Zo ook schaalbaarheid van het systeem. Door on-demand meer of minder resources te kunnen gebruiken kan een applicatie schalen als dit nodig is. Dit houdt vaak in dat er dynamisch meerdere instanties gemaakt worden van een applicatie. In bijna ieder artikel over Cloud Computing en diens voordelen zal deze genoemd staan. Alleen is er wel een gevaar: een applicatie die buiten de Cloud niet kan schalen, schaalt in de Cloud ook niet! Bij de ontwikkeling van de applicatie zal er dus al rekening gehouden moeten worden met schalen of de applicatie moet herzien worden voor deze klaar is voor alle voordelen van Cloud Computing. Behalve de capaciteit moet de applicatie zelf dus ook schaalbaar zijn. Er kan nog een zodanig grote capaciteit zijn, maar als de applicatie niet ontworpen is om mee te kunnen schalen dan is dit erg inefficiënt. Er kan onderscheid gemaakt worden tussen opschalen (verticaal) en uitschalen (horizontaal) (Wikipedia.b, 2009). Als er uitgeschaald wordt, dan betekend dat het inzetten van meer machines of instanties van een applicatie. Dit stelt bepaalde eisen aan het applicatieontwerp om dit te bewerkstelligen. Verticaal opschalen is het beter benutten van resources of het upgraden van resources, bijvoorbeeld respectievelijk door Virtualisatie of hardware upgrade. Cloud Computing combineert beiden door het dynamisch instantiebeheer (uitbreiden instanties van een applicatie), on-demand resources en het toepassen van Virtualisatie. KOSTEN Pay-as-you-go is een systeem dat zich richt op variabele kosten. Wordt een applicatie veel gebruikt en kost deze veel computing dan zal de rekening hoger zijn. Een voordeel ten opzichte van de traditionele datacenters is het gebrek aan vaste kosten. Een datacenter kost geld en deze worden, zoals eerder dit hoofdstuk al aangekaart, zelden helmaal benut. Bij Cloud Computing wordt alleen betaald over wat je ook echt gebruikt. Dit levert over het algemeen (zeker als een bedrijf nog geen beschikking heeft over een groot datacenter) een significant kostenvoordeel met zich mee, zie Figuur 3: Kosten. FIGUUR 3: KOSTEN (JOHNSTON) Pagina 12
Servers beheren kost natuurlijk ook geld, zoals al even genoemd in dit hoofdstuk onder Hosting, ontwikkeling en beheer. Door het onderbrengen van dit beheer bij een Cloud Provider is er ook een kostenpost minder. Er zal nog steeds personeel de applicatie moeten monitoren, maar dit zal een stuk efficiënter en minder intensief zijn dan een eigen datacenter beheren. VOLWASSENHEID Services, Grid Computing, Internet en SaaS zijn niet nieuw. Cloud Computing is dit relatief gezien wel. Er is nog veel onbekend gebied, maar de ontwikkeling van Cloud Computing gaat razendsnel. Grote partijen als Google (AppEngine) en Microsoft (Azure) zijn pas ongeveer sinds een jaar in de Cloud Computing boot gestapt met het aanbieden van een eigen platform. De techniek is dus nog relatief nieuw, maar wint steeds meer aandacht van grote IT partijen. Wat zegt dit over de volwassenheid van Cloud Computing? Is het wel verstandig om nu al over te stappen op een dergelijke nieuwe techniek of is het al volwassen genoeg om toe te passen? Gartner (een gerenommeerd IT analyse bedrijf) heeft enkele artikelen over deze vraagstukken gepubliceerd. Begin 2009 heeft Gartner een prognose gedaan naar de tijdschaal van de toepassing van Cloud Computing. De conclusie was dat Cloud Computing nog ongeveer 5-7 jaar nodig heeft (en 2-5 tot adoptie) om volledig volwassen te worden, zie (IT PRO, 2009) en ook (Gartner.b, 2009). Dit komt onder andere door de volgende factoren: Behoefte aan standaardisatie (Washington Technology, 2009). Het gevaar van vendor lock-in bestaat nu alle platforms een eigen weg inslaan bijvoorbeeld bij het ondersteunen van programmeertalen of het implementeren van verschillende typen (eigen) databases. Beperkingen bij het ontwikkelen op deze platforms, voor meer informatie zie de paragraaf Cloud platformen. Snelle ontwikkeling op Cloud Computing gebied, doordat Cloud Computing een erg hippe term is (misschien is er zelfs sprake van een hype, (Gartner.b, 2009)). Iets dat op dit moment standaard is, kan erg snel veranderen of een nieuwe techniek kan snel verouderen. Er zijn veel partijen op gedoken en bezig met het ontwikkelen van manier om Cloud Computing toe te passen. Het is nog niet echt te zeggen welke dingen echt nuttig zullen zijn of welke een standaard zullen gaan vormen. Doordat het erg nieuw is bevinden veel Cloud platformen zich in bèta fase, hierdoor staat er nog weinig vast. Tevens zijn er nog weinig ervaringen m.b.t. mogelijke downtime en performance. Binnen enkele jaren zal er (volgens Gartners hypecycle) meer overzicht ontstaan en de grote partijen duidelijk naar voren komen. Dit zal de standaardisatie bevorderen en meer vertrouwen opwekken. Dan is het een kwestie van tijd tot er meer toepassingen van Cloud Computing komen, ook voor Enterprise applicaties. Pagina 13
2.5. HUIDIGE TOEPASSINGEN Cloud Computing is bijzonder veelzijdig op het gebied van toepassingen. Hieronder staan enkele toepassingen die hedendaags gebruikt worden. HOSTING Wellicht de bekendste toepassing van Cloud Computing is de hosting van websites en services. Dit betreft het aanbod van software als een service ofwel SaaS. Een groot voordeel van hosting in een Cloud omgeving is de flexibele schaalbaarheid. De Cloud kan on-demand groeien of krimpen afhankelijk van de mate van het gebruik van de website of service. DATA STORAGE Opnieuw is schaalbaarheid een belangrijk aspect waar Cloud Computing bijzonder sterk in is. Opslagruimte kan on-demand vergroot of gereduceerd worden waarbij de afnemer slechts betaald voor wat hij daadwerkelijk gebruikt. PROCESSING POWER Vergelijkbaar met Grid Computing biedt Cloud Computing oplossingen voor rekenkracht op afstand. Het klassieke succes verhaal is die van de New York Times die haar complete artikel archief wilde converteren naar PDF formaat. De aanschaf van computer systemen die deze conversie uit kan voeren zou een gigantische investering zijn. Dankzij de EC2 service van Amazon konden 11 miljoen artikelen, ongeveer 4 Terrabyte aan data, binnen 24 uur verwerkt worden. VIRTUALISATIE Dit betreft de virtualisatie van servers of werkstations waarbij een Operating System op een computer in de cloud geïnstalleerd is. Servers die in een Cloud omgeving geïnstalleerd zijn hebben het grote voordeel dat de aanschaf en het lokaal installeren van een server systeem niet langer nodig is. Het is een soort van outsourcing waarmee mogelijk bespaard kan worden omdat aanschaf- en onderhoudskosten van systemen hierbij wegvallen. Een mogelijk nadeel is een verhoogde latency doordat de server zich niet in het lokale netwerk bevindt. Pagina 14
3. ENTERPRISE APPLICATIES In dit hoofdstuk wordt een definitie van Enterprise Applicaties gegeven en worden enkele aspecten uitgelicht. Dit heeft als doel een beeld te krijgen van wat een Enterprise Applicatie anders maakt dan een ander soort applicatie, zodat in een later hoofdstuk dit binnen het Cloud Computing onderwerp gepast kan worden. 3.1. WAT IS HET? Enterprise Applicaties zijn, zoals de naam al suggereert, applicaties voor Enterprises. In het Nederlands heten zij simpelweg bedrijfsapplicaties. Het doel van Enterprise Applicaties is om aan business requirements te voldoen en als IT oplossing voor een gehele Enterprise te dienen. Doorgaans zijn dit bijzonder grote en complexe applicaties. Enterprise Applicaties zijn gericht op flexibiliteit, efficiëntie, robuustheid en schaalbaarheid. Het aanbod van Enterprise applicaties is veelal in de vorm van maatwerk. In andere gevallen worden vaak toolkits meegeleverd waarmee de applicatie precies naar de wensen van de klant aangepast kunnen worden. Twee grote spelers in het aanbod van Enterprise Applicaties zijn Oracle en SAP. De definitie van Enterprise Applicaties die in dit rapport wordt aangehouden luidt als volgt: een multi-user applicatie die een oplossing biedt voor een bedrijfsprobleem, tegenover een afdelingsprobleem. ENTERPRISE APPLICATION INTEGRATION Een term die vaak bij Enterprise Applicaties wordt genoemd is Enterprise Applicatie Integratie (EAI). Het gaat hierbij om het koppelen van meerdere Enterprise Applicaties, zodat deze samenwerken en tot een efficiënter geheel leiden. Een mogelijke uitwerkingen kan aan de hand van Service Orientated Architecture (SOA) principes. Hierin worden verschillende losse componenten aan elkaar gekoppeld met een service architectuur. FIGUUR 4: EAI (WIKIPEDIA.E) Pagina 15
3.2. EISEN Worden er aan een Enterprise Applicatie andere eisen gesteld dan aan andere applicaties? Op bepaalde vlakken kan dat wel gesteld worden. Vooral data en security zijn twee factoren die vanzelfsprekend belangrijk zijn voor een bedrijf. Tevens wordt schaalbaarheid besproken. DATA Het spreekt voor zich dat de data het belangrijkste bezit van een bedrijf is. In de gegevens die bedrijven hebben zit al het geld en zonder diens gegevens zou het bedrijf geruïneerd zijn. In een Enterprise Applicatie is dit dus een ontzettend belangrijk onderdeel. Als er een nieuwe Enterprise Applicatie ontwikkeld wordt dan staat de data ook centraal en moet dus snel en gemakkelijk te gebruiken en bij te werken zijn. Behalve als het een nieuw bedrijf is, zal er al een vorm van dataopslag aanwezig zijn. Hier moet met de ontwikkeling van de applicatie dan ook rekening mee gehouden worden. De vorm waarin deze gegevens opgeslagen zijn kunnen uiteenlopen van relationele databases, oude mainframes tot zelfs papier in archieven. Dit kan effect hebben op de architectuur van de Enterprise Applicatie, evenals de opslagvorm van de nieuwe applicatie. Hierbij moet rekening gehouden worden met onderhoudbaarheid. De data zal waarschijnlijk lang bewaard moeten worden en in de tussentijd zal de Enterprise Applicatie zeer waarschijnlijk ook veranderingen ondergaan. De data moet dus gemakkelijk bereikbaar, goed onderhoudbaar en tevens schaalbaar zijn. Op schaalbaarheid wordt later in gegaan. SECURITY Geen bedrijf wil graag diens gegevens op straat gooien. Security is dan natuurlijk ook van groot belang. Bij een Enterprise Applicatie kan zich over meerdere afdelingen verspreiden, maar het zal in ieder geval meerdere personen met een andere rol in het bedrijf moeten dienen. Hierbij komen dingen kijken als authenticatie (wie is het) en autorisatie (wat mag je). Het is dus belangrijk dat een werknemer geïdentificeerd kan worden en vervolgens geen dingen mag doen die niet bij zijn/haar rol in het bedrijf hoort. Een Enterprise Applicatie moet in diens inrichting hier rekening mee houden. De data moet afgeschermd zijn, want buitenstaanders moeten er geen inzage in kunnen krijgen. Hetzelfde geldt voor de applicatie zelf natuurlijk. Om dit te realiseren zijn vele oplossingen mogelijk en hier zal het één en ander over aan bod komen in de paragraaf Security. SCHAALBAARHEID Wederom komt het woord schaalbaarheid aan bod. Het wordt gezien als een groot voordeel van Cloud Computing voor Enterprises (zie paragraaf Schaalbaarheid). Het kan dus ook niet anders dan dat schaalbaarheid belangrijk is. Dit komt natuurlijk doordat een bedrijf zich snel aan moet kunnen passen aan bijvoorbeeld economische factoren, zoals groei of juist recessies. Als je bedrijf hard groeit, moet de applicatie meegroeien. Tevens wil een bedrijf natuurlijk niet enorm veel geld uitgeven aan een serverpark om een capaciteit te bewerkstelligen die slecht enkele dagen in het jaar gehaald gaat worden. Maar een bedrijf natuurlijk wil niet beperkt worden in diens groei door een slechte applicatie architectuur of een beperkt serverpark. Dit hangt ook sterk samen met performance. Een applicatie moet snel en gemakkelijk werken, anders leidt het tot een te lage efficiëntie. Behalve schaalbaarheid moet een Enterprise Applicatie ook geoptimaliseerd worden om goed te performen. Pagina 16
4. CLOUD ONTWIKKELING Nu duidelijk is wat Cloud Computing is en welke eisen er aan Enterprise applicaties gesteld worden, wordt in dit hoofdstuk dieper in de ontwikkeling van Cloud Computing applicaties gekeken. Hierbij komen enkele Cloud platformen aan bod die gebruikt kunnen worden om deze applicaties voor te ontwikkelen en op te laten draaien. Ook wordt gekeken naar data storage in de Cloud, security, testing en lifecycle management. Hierdoor wordt een beeld geschept over de mogelijkheden en specifieke eigenschappen van het ontwikkelen van Cloud applicaties. 4.1. CLOUD PLATFORMEN Er is een groeiend aantal aanbieders voor Cloud Computing platformen met vaak unieke eigenschappen. In de volgende subparagrafen wordt er gekeken naar een aantal van deze waarbij het mogelijke is om applicaties te ontwikkelen voor het platform. De aanbieders zijn Microsoft met Azure, Google s AppEngine en SalesForce. In het kort worden de individuele eigenschappen uitgelicht en wordt er gekeken naar welke hulpmiddelen en frameworks er beschikbaar zijn voor de platformen. GLOBAAL OVERZICHT Platform Programmeertaal Opmerkingen Azure Meer talen zullen worden toegevoegd naar verloop van tijd (20-11- 2009). C# en.net Native programmeertalen voor Azure. Ondersteuning sinds de eerste versie en veel voorbeelden beschikbaar. C++ Via de Visual Studio IDE PHP Via SDK beschikbaar via de developer portal van Azure. Java Via SDK beschikbaar via de developer portal van Azure. Ruby Via SDK beschikbaar via de developer portal van Azure. Python Via SDK beschikbaar via de developer portal van Azure. GoogleApps Meer talen zullen toegevoegd worden naar verloop van tijd (20-11- 2009). Python Native beschikbaar. Pure Python applicaties kunnen geüpload worden. Bepaalde c functies zijn uitgeschakeld, net als functies die naar de schijf schrijven (20-11-2009). Java Native Beschikbaar. Frameworks moeten ondersteund worden zie hier voor de GoogleApps developer portal. SalesForce Salesforce biedt opslagruimte en applicaties aan door middel van de APEX taal. Deze draait boven op de opslagmedia en bied logica hierop aan. Via messaging kan er vervolgens via andere talen gebruik gemaakt worden van de Salesforce API s. Java Via packages.net Via API s Perl Zie devportal Salesforce voor voorbeelden PHP Zie devportal Salesforce voor voorbeelden Python Zie devportal Salesforce voor voorbeelden Pagina 17
GOOGLE APPENGINE De eerste bèta van Google s AppEngine is beschikbaar sinds april 2008. Het bood destijds alleen ondersteuning voor Python applicaties. Een latere versie voegde hier Java aan toe. Applicaties die draaien in de AppEngine hebben wel enkele beperkingen. Zo is het niet toegestaan om gebruik te maken van het lokale opslag medium van een client en mag een Java applicatie geen nieuwe thread starten. Betalingsmodel Gebruik van de AppEngine is gratis tot bepaalde limieten bereikt worden. Als deze limieten bereikt zijn kan er bij Google een betaalregeling opgezet worden voor bijvoorbeeld extra CPU (processor) tijd. Resource Unit Unit cost Outgoing Bandwidth gigabytes $0.12 Incoming Bandwidth gigabytes $0.10 CPU Time CPU hours $0.10 Stored Data gigabytes per month $0.15 Recipients Emailed recipients $0.0001 (Zoals op 08-1-2010 (Google.a, 2009). Deze tabel is uitsluitend bedoeld als indicatie hoe de kosten opgedeeld worden, prijzen veranderen vanzelfsprekend.) IDE s Java Voor Java kan er gebruik gemaakt worden van de Eclipse IDE. Hier is een speciale plug-in voor te verkrijgen. Deze voegt een nieuw projecttype toe en maakt het mogelijke om projecten te deployen in de AppEngine of in een testomgeving. Daarnaast is een vergelijkbare plug-in beschikbaar voor Sun s Netbeans. Phython Voor ontwikkeling van python applicaties kan gebruik gemaakt worden van elke gewenste IDE. Uploaden van de applicaties en testen gebeurd aan de hand van console commando s die met de Google AppEngine Python SDK mee geïnstalleerd worden. Frameworks & Tooling Java Google heeft een beperking aangebracht in het gebruik van frameworks en libaries om, naar eigen zeggen, de beveiliging te garanderen. Er is dan ook flink gesneden in de frameworks die doorgaans ondergebracht worden bij de Java EE. Als men deze probeert te gebruiken zal er tijdens de compileertijd een fout optreden. Google heeft voor de GAE een eigen Java virtual-machine geïmplementeerd die deze condities afdwingt. Voor een compleet en actueel overzicht van framework comptabiliteit bezoek de Google AppEngine will-itplay-in-app-engine pagina (Google.c, 2009). Python Naast een aantal web frameworks geschreven voor de Google AppEngine is er ook ondersteuning voor bijvoorbeeld Django, CherryPy, Pylons, en web2py (Google.b). In principe kan een framework dat WSGI ondersteunt aan de hand van de CGI adapter met de applicatie mee geüpload worden naar de Appspot. Mits deze geschreven zijn in pure Python en niet een van de andere beveiligingscriteria overschrijden. Pagina 18
AZURE Azure is de omvattende naam voor de Cloud producten van Microsoft. Het bestaat uit een aantal verschillende onderdelen: Windows Azure is het platform dat aangeboden wordt als service. SQL Azure is een relationele database die zijn werk doet in de Cloud. AppFabric geeft ontwikkelaars de mogelijkheid om verschillende applicaties (in de Cloud of onpremises) met elkaar te laten communiceren aan de hand van een service bus. Deze bus ondersteund bekende communicatie methodes zoals SOAP en REST. Tevens bevat het de.net Access Control service om Federated identies mogelijk te maken. FIGUUR 5: MICROSOFT AZURE OVERVIEW (MICROSOFT.C) Betalingsmodel Microsoft heeft Azure onderverdeeld in vier verschillende abonnementen. Deze variëren van een gratis abonnement, een aantal betaalde abonnement tot een pay-as-you-go model. In elke model zijn de individuele onderdelen van het Azure platform opgenomen. Het onderstaande overzicht probeert geen vergelijking te maken tussen de kosten verschillen tussen Azure en de Google AppEngine, maar geeft uitsluitend weer hoe deze verdeelt zijn. Resource Unit Unit cost Outgoing Bandwidth gigabytes $0.15 Incoming Bandwidth gigabytes $0.10 CPU Time CPU hours $0.12 Stored Data gigabytes per month $0.15 AppFabric Access Control 100.000 transactions $1.99 (Microsoft.d) IDE.Net Voor de.net talen is natuurlijk de Visual Studio IDE van Microsoft zelf beschikbaar. Aan de hand van een set van tools die beschikbaar is via de MSDN portal kan de Visual Studio IDE klaar gemaakt worden voor het ontwikkelen van Azure applicaties. Voor de AppFabric en SQL Azure moeten aparte SDK s geïnstalleerd worden naast de Azure SDK zelf. Java Voor Java is het mogelijke om aan de hand van SDK s Java applicaties te ontwikkelen voor Azure. Er wordt een extra plug-in aangeboden voor de Eclipse IDE Voor de overige talen worden geen extra IDE uitbreidingen aangeboden. Pagina 19
Frameworks & Tooling De werking van Frameworks of Libaries hangt voornamelijk af van in hoeverre de Azure implementatie verschilt van de ontwikkelomgeving waar de deze voor ontworpen zijn. Zo werkt Nhibernate (ORM oplossing) op SQL Azure zonder problemen. Het is tevens mogelijke om worker roles in full trust (non admin) te laten werken waardoor het mogelijke wordt om een aanroep te doen naar de Native code van het Azure OS. Hierbij moet wel rekening gehouden worden met de omgevingsvariabelen van het Azure OS, zoals welk.net Framework er op dat moment op draait. FORCE PLATFORM (SALESFORCE) Het Force Platform is een product van SalesForce. Zij zijn voornamelijk bekend door hun CRM producten aangeboden via SAAS in Cloud omgevingen. Gebruikers kunnen hier uitbreiden opschrijven doormiddel van de Apex en Visualforce taal, zoals de naam al aangeeft producten van SalesForce. Apex is taal zoals Java voor het uitprogrammeren van logica. Visualforce heeft veel weg van XML en kan gebruikt worden voor het realiseren van de gui. Naast uitbreiding op de CRM oplossingen is het ook mogelijke om applicaties voor nieuwe doeleinden te schrijven. Op de AppExchange kunnen applicaties geschreven voor SalesForce door verschillende partijen aangekocht worden. Communicatie met het platform is mogelijke d.m.v. webservices. Betalingsmodel Het model van SalesForce wijkt sterk af van bijvoorbeeld het model zoals deze door Microsoft en Google gebruikt worden. Het biedt een aantal abonnement aan die uitsluitend toegang geven tot de contacten management software van Salesforce of de CRM oplossingen. De latere voornamelijk duurdere modellen geven de mogelijkheden om eigen applicaties te ontwikkelen. Dit gaat oplopend van applicaties die uitsluitend integreren op het platform tot applicaties die op zichzelf staan. IDE Salesforce heeft een IDE uitgegeven voor het ontwikkelen met Apex en Visualforce. Deze IDE genaamd Force.com IDE is gebaseerd op Eclipse en maakt het mogelijke om naast de applicatie te ontwikkelen deze ook te deployen in de Salesforce cloud. Frameworks & Tooling Salesforce biedt een groot aantal API s die het mogelijke maakt om gebruik te maken van het platform zonder dat er in apex of visualforce geschreven moet worden. Veelal gaat het daarbij om het beschikbaar stellen van bepaalde Force platform functionaliteiten aan applicaties via bijvoorbeeld webservices. Op de development portal van Salesforce kan onder integratie de complete en actuele lijst gevonden worden. Pagina 20
4.2. DATA STORAGE Allereerst is het belangrijk onderscheid te maken tussen twee aspecten van data storage. Het eerste aspect is de opslag van bestanden zoals afbeeldingen, spreadsheets en documenten. Het tweede aspect is de opslag van gestructureerde data in databases. In deze paragraaf wordt van beide aspecten bekeken welke mogelijkheden er zijn bij Cloud Computing. DATA OPSLAG De grote namen op dit gebied zijn Amazon, Microsoft en Google. Het type van de database hangt af van de aanbieder. In de begindagen van Cloud Computing was er geen aanbod van relationele databases in een Cloud omgeving. Relationele databases zijn van nature lastig te schalen waardoor zij slecht aansluiten op de ideeën van Cloud Computing. Het schaalbaar maken van databases leidt al snel tot het partitionering en verspreiden van data over meerdere instanties. Een gevolg hiervan is dat de consistentie van de data niet altijd gegarandeerd kan worden zonder dat aspecten als availability en fouttolerantie achteruit gaan zoals beschreven door de CAP theorie van Dr. Eric A. Brewer. Echter bestaat er tegenwoordig toch zeker een aanbod van relationele databases. Hier volgt een greep uit het aanbod van databases services: Amazon s SimpleDB De SimpleDB service van Amazon betreft een key/value database waardoor deze gemakkelijk schaalt in een Cloud omgeving. Via een Web service kunnen calls gedaan worden als PUT, DELETE en SELECT om data te bewerken of lezen. SimpleDB hanteert geen database schema. Objecten kunnen dus direct en onafhankelijk van data types direct naar de database geschreven worden. Amazon s RDS Een latere toevoeging in het assortiment van Amazon is de Relational Database Service (RDS). Onderhuids gaat het om een MySQL database. Met deze service geeft Amazon de mogelijkheid om bestaande MySQL databases gemakkelijk over te zetten naar een Cloud omgeving. RDS is volledig compatibel met de tooling die gebruikt wordt voor normale MySQL databases, en dat komt de toegankelijkheid sterk ten goede. Microsoft s SQL Azure Microsoft heeft met SQL Azure een relationele database service, dat gebaseerd is op SQL server. Met deze service biedt Microsoft een laagdrempelige oplossing voor gebruikers die ervaring en bestaande toepassingen hebben met SQL Server. SQL Azure bevat dezelfde functionaliteit als SQL Server bijvoorbeeld op het gebied van T-SQL ondersteuning, stored procedures, triggers en transacties. Tevens is SQL Azure compatibel met tools als de SQL Server Management Studio. Google s DataStore Het aanbod van Google bestaat uit de Datastore service welke onderdeel is van de Google AppEngine. Datastore is de publieke laag bovenop het bekende BigTable filesysteem dat tevens door Google zelf gebruik wordt voor haar producten. Deze service is vergelijkbaar met de SimpleDB service van Amazon, in de zin dat het een key/value database betreft waarin objecten schemaless geplaatst kunnen worden. NON-RELATIONELE / OO DATABASES EN ENTERPRISE APPLICATIONS Een punt genoemd door dhr. Guy Harrison in zijn artikel Is the Next DBMS Revolution Looming? is het ontbreken van ondersteuning voor Business Intelligence (BI) bij non-relationele databases doordat de data hier applicatie gericht is. Voor bedrijven waarvoor het vergaren van BI van belang is, zal de keuze in Cloud databases zich wenden van non-relationele databases. Pagina 21
BESTAND OPSLAG Op het gebied van data storage in een Cloud Omgeving zijn verschillende oplossingen. De oplossingen bestaan in de meeste gevallen uit een webservice die gebruikmakend van een API aangeroepen kan worden. Enkele grote spelers op het gebied van Cloud Storage zijn Amazon en Rackspace. Amazon Simple Storage Service (S3) De S3 service van Amazon wordt aangeboden via een Web Service. Data worden in zogenaamde buckets geplaatst waarop vervolgens PUT, GET, DELETE en WRITE instructies uitgevoerd kunnen worden. Rackspace Cloud Files Rackspace biedt haar storage service aan via een REST API. Gegevens kunnen in een container geplaatst worden. De gebruiker kan kiezen of een container private of public toegankelijk is. Private containers zijn alleen toegankelijk voor de gebruiker over een beveiligde verbinding. Naast directe toegang tot een REST API biedt Rackspace tevens verschillende bindings voor verschillende gangbare programmeertalen en frameworks als: PHP Java Python.NET Ruby Pagina 22
4.3. SECURITY Er is al veel geschreven over beveiliging in de Cloud en welke gevaren dit met zich mee brengt. Veel van deze teksten hebben als doel om aan te kaarten dat er zorgen zijn of deze zorgen juist weg te nemen. Meestal wordt er gesproken in globale termen en wordt er weinig concreets gezegd over hoe deze problemen aangepakt gaan worden. Immers is men het er in het algemeen over eens dat Cloud Computing als technologie een belangrijke nieuw inzicht gaat leveren (Pettey, 2009). In de volgende paragrafen wordt beschreven welke mogelijkheden er bestaan voor ontwikkelaars om eventuele beveiligingsproblemen aan te pakken. Het begint echter met een kort overzicht van de gebruikelijke security concerns. ALGEMENE SECURITY CONCERNS (BRODKIN, 2008) De volgende punten kunnen gebruikt worden bij het maken van een keuze voor Cloud serviceproviders. 1. Privileged user access Omdat bedrijfsinformatie opgeslagen wordt buiten het bedrijf is het belangrijk dat duidelijk is wie er toegang heeft tot deze informatie. Dit moet aangekaart worden bij de Cloud service provider alvorens met besluit contracten te tekenen. 2. Aansprakelijkheid De klant zelf blijft verantwoordelijk voor de beveiliging en integriteit van zijn data. Als de Cloudservice provider geen audits en certificering accepteert dan is dit aldus Gartner (Brodkin, 2008) een signaal dat het slechts vertrouwd kan worden met triviale taken. 3. Data locatie Het is niet altijd bekend waar de data opgeslagen wordt. Maak met de Cloud provider afspraken om er voor te zorgen dat deze bijvoorbeeld niet buiten rechtelijke bevoegdheden valt. Dit in verband met privacyrechten. 4. Scheiding van data In de Cloud omgeving kan data van de klant naast die van een andere klant staan. Encryptie is een effectieve techniek om deze data te beveiliging maar er moet wel een encryptie schema opgesteld zijn de data gescheiden houdt. De provider moet dit kunnen garanderen. 5. Herstel Ondanks dat de data over de hele wereld kan staan zal de provider moeten kunnen aantonen wat er met de data gebeurd en hoe deze te herstellen is. Als er geen replicatie plaatst vind is de kans op data verlies groot. 6. Support & Logging Onderzoek of de provider mogelijkheden heeft om ongewenst of illegaal gebruik te onderzoeken. Dit is niet altijd mogelijk, en als de provider niet kan aantonen over deze mogelijkheden te beschikken, dan kan men aannemen dat deze niet in bezit is. 7. Op de lange termijn Het is belangrijk dat bij het failliet gaan of andere calamiteiten van de Cloud service provider de data beschikbaar blijft. Pagina 23
IDENTITY MANAGEMENT Identity management is een concept dat mogelijkheden biedt voor gebruikers om geïdentificeerd en geauthenticeerd te worden in een computersysteem. Eenmaal geauthenticeerd kan een gebruiker vervolgens de taken uitvoeren waarvoor hij gemachtigd is. Het is belangrijk om hierbij rekening te houden met de gedachte dat identity geen access control is. De verschillende aspecten van een identity kunnen verschillen per partij waar de gebruiker contact mee heeft. Voor een bank is bijvoorbeeld het saldo interessant terwijl in een Enterprise Applicatie de afdeling waar deze werkzaam is misschien wel belangrijker is. In dit voorbeeld kan de bank één van de partijen voorstellen maar ook beiden. Doordat het anno 2009 niet langer realistische is dat Enterprise Applicaties alleen gebruik maken van identities in eigen beheer is het concept Fedaration ontstaan. Hierbij wordt er een derde partij expliciet vertrouwd door de organisatie. Op deze manier kan men een identity vertrouwen (trust) zonder dat deze in het eigen systeem opgenomen is. FIGUUR 6: FEDERATED IDENTITY (COMPACT.NL) Federated Identities komen vaak voort uit Enterprise Applicaties aangezien het domein hiervan vaak de grenzen van de locatie, verschillende afdelingen of zelfs organisatie overschrijdt. Het overschrijden van locatie als eigenschap zien we terugkomen bij Cloud applicaties die communiceren met meerdere Clouds, legacy applicaties of hybride Cloud applicaties. Dit maakt identies bij Cloud Computing een belangrijk onderdeel van de security. De meeste Cloud aanbieders geven de mogelijkheid om identies te gebruiken. De Google AppEngine heeft als doel OpenID te ondersteunen en Microsoft bied identity management via.net Access Control Service (ACS). In de volgende paragraaf zal deze ACS verder besproken worden om een concreter beeld te kunnen vormen. ACCESS CONTROL SERVICE (APPFABRIC) De AppFabric Access Control Service is een concreet voorbeeld van een Cloud based security oplossing. De ACS is een onderdeel van Azure, maar kan ook gebruikt worden om voor bestaande on-premises applicaties de identity management te regelen. ACS werkt met tokens, deze tokens kunnen aangevraagd worden bij de ACS zelf. Met deze tokens kunnen applicaties vervolgens communiceren. Dit is toegepast volgens het Common Interaction Pattern (Microsoft.a, 2010), zie ook Figuur 7: Common Interaction Pattern. Pagina 24
FIGUUR 7: COMMON INTERACTION PATTERN Deze Web Service en Consumer kunnen overal zitten, binnen Azure, internet of een andere Cloud. ACS maakt gebruik van verschillende standaarden zoals REST/HTTPS voor communicatie en bijvoorbeeld SAML en Simple Web Token (SWT) voor beveiligen (Microsoft.b, 2010). In Figuur 7: Common Interaction Pattern is tevens te zien dat ACS het Federated principe hanteert. ACS zorgt voor een token die vertrouwd wordt door de webservice. Op die manier weet de webservice dat de consumer te vertrouwen is en krijgt deze toegang. Pagina 25
4.4. TESTEN Testen is een begrip met vele facetten. Het bedrijf Breaking Point beschrijft op haar website punten als Elasticity, Realism, Scalability en Security waarop testen van belang is bij Cloud Computing infrastructuren. Hoewel de ontwikkelaar deze verschillende aspecten in zekere mate kan testen, zal hij niet altijd invloed kunnen uitoefenen naar de resultaten. Elasticity, waarbij de Cloud infrastructuur groeit en krimpt op basis van de belasting is een aspect waar de ontwikkelaar weinig invloed op kan uitoefenen. De verantwoordelijkheid in dat geval zal dan bij de Cloud provider liggen. GOOGLE APPENGINE GAE heeft ondersteuning voor Unit Testing bijvoorbeeld aan de hand van JUnit testcases. Services worden dan in een lokale setting uitgevoerd. Door de lokale setting worden elementen die normaal gesproken bij een in de Cloud deployed applicatie van toepassing zijn buiten beschouwing gelaten. Het is dan ook puur een methode om op code niveau de functionaliteit te testen. Voor testing op een hoger niveau dan Unit Testing biedt GAE de mogelijkheid om meerdere versies van een service te deployen. Hiervan is één de standaard live versie die voor publieke doeleinden ingezet kan worden. Daarnaast kunnen andere versies voor test doeleinden gebruikt worden. FIGUUR 8: GAE VERSIONERING WINDOWS AZURE Vergelijkbaar met GAE biedt Windows Azure de mogelijkheid om verschillende versies van een service te deployen. Azure maakt hierbij onderscheid tussen het deployen naar een live productie omgeving en een Staging omgeving. Services in de productie omgeving krijgen een publieke URL (bijvoorbeeld eaddemo.appspot.net). Echter krijgen services in de Staging omgeving een tijdelijke en veel abstractere URL (bijvoorbeeld http://440fa13ad9bc44769baff9549cbb48e3.cloudapp.net/). De Staging omgeving kan gebruikt worden als omgeving voor integration testing. FIGUUR 9: AZURE DEPLOYMENTS Pagina 26
4.5. LIFECYCLE Met het ontwikkelen en testen van een applicatie is het natuurlijk nog niet klaar. Hoe gemakkelijk is het om je applicatie te deployen? En welke mogelijkheden worden geboden om een Cloud applicatie te beheren en onderhouden? In deze paragraaf wordt gekeken naar de platforms van Google en Microsoft en op welke manier verschillende belangrijke factoren aanwezig zijn, onderverdeeld in deployment (deployen, updating, versionering) en beheer (monitoring, error handling/logging). PaaS biedt namelijk een volledige oplossing voor de gehele lifecycle van applicaties. Daarom is het verstandig te kijken naar de mogelijkheden van de platformen van twee grote softwareaanbieders en hoe dit het beheren van een applicatie kan vergemakkelijken. DEPLOYMENT Het deployen van applicaties naar een Cloud verschilt in zekere zin niet veel met het deployen naar een normale applicatie- of webserver. Bij het gebruik maken van Cloud platforms wordt het allemaal nog makkelijker gemaakt. Googles AppEngine gebruikt bijvoorbeeld een plug-in voor Eclipse waarin met groot gemak een applicatie gecompileerd en direct geüpload wordt naar de Cloud. Niet iedereen gebruikt natuurlijk Eclipse als IDE, daarom zijn er ook bestanden bijgevoegd die het via command prompt (of terminal) mogelijk maken een WAR bestand (ingepakt web project) te uploaden. Er kunnen bij een nieuwe upload ook enkele eigenschappen, zoals versie, aangepast worden. Op de webinterface van het domein op AppEngine staan deze versies ook los deployed en kunnen geraadpleegd worden. Als er een andere versie deployed wordt, dan is een andere versie nog steeds bereikbaar in de Cloud. Er moet, indien er een nieuwe versie deployed is, ook eerst aangegeven worden dat dit de default versie is. Anders zal de vorige versie nog als standaard bereikt worden. Dit heeft als gevolg dat er geen downtime is bij het deployen van een nieuwere versie van een applicatie. Er kan ook, zo nodig, zonder problemen worden gewisseld naar een vorige versie van een applicatie of deze kunnen naast elkaar gebruikt worden. Per versie zijn dezelfde beheer en monitor functies beschikbaar. Meer hierover verderop in deze paragraaf. Microsoft houdt er met Azure een iets andere werkwijze op na. Er kan met een Visual Studio plug-in wel een cloud-ready project gepubliceerd worden, maar deze moet wel handmatig (tenzij er zelf iets voor geschreven wordt) via de webinterface geüpload worden. Om downtime te voorkomen heeft Microsoft een andere manier dan Google, namelijk het gebruik van een staging naast een production deployment. In Figuur 10: Azure service overview staat de weergave op de webinterface (developer portal) van Azure. Hierbij, kan zoals in de vorige paragraaf ook al genoemd is, de staging deployment FIGUUR 10: AZURE SERVICE OVERVIEW gebruikt worden om te testen. En als dit gedaan is, kan dit omgedraaid worden met de production deployment. Op een zelfde manier als Google dit doet met versies, met uiteraard dezelfde voordelen. Deze twee versies zijn ook beiden bereikbaar en kunnen apart geconfigureerd en geüpgrade worden. Wat bij Microsoft een goede bijkomstigheid is dat er gekozen kan worden of de gebruiker zijn applicatie in binnen de Verenigde Staten wil deployen, in verband met wetgeving t.a.v. privacy bijvoorbeeld. En het geeft de Pagina 27
gebruiker natuurlijk een vertrouwelijk gevoel. Verder zijn in de developer portal nog Certificaten te uploaden in verband met security. Iets dat bij Google toch handmatig opgelost moet worden. Op het gebied van deployment zijn beide platformen goed uitgerust en bieden ze mogelijkheden als versionering en het zonder downtime wisselen tussen versies van een applicatie. BEHEER Een belangrijk aspect is natuurlijk ook het beheer van de applicatie. Bij problemen moeten logs een uitkomst bieden en tevens moet één foutmelding (error) er natuurlijk niet voor zorgen dat de gehele applicatie ermee ophoudt. Tevens bieden platforms ook een vorm van monitoring zodat ontwikkelaars kunnen zien wat het gebruik/verbruik van een applicatie is. In een normale situatie, van één eigen server, is het makkelijker om transacties te volgen of logging te doen, simpelweg omdat het bekend is waar de server staat en omdat deze waarschijnlijk zelf ingericht is. Het is mogelijk zelf hier en daar tracing aan te zetten, dus lokaal enkele aanpassingen te doen. Maar als niets bekend is over de achterliggende architectuur zoals bij Cloud Computing, en deze ook nog eens erg dynamisch is, moet het Cloud platform ervoor zorgen dat de diagnostiek wel goed kan verlopen. De twee platformen die bekeken worden verschillen ook hierbij in aanpak. Google heeft veel energie gestoken in het aanbieden van monitoring via het Dashboard (de web interface van de AppEngine). Alle informatie over verbruik van een applicatie worden getoond op het gebied van data, CPU tijd, aantal requests en natuurlijk het versiebeheer. In Figuur 11: GAE Diagnostics Dashboard staat de chart en informatie over usage. Dit heeft als voordeel dat het financiële aspect goed in de gaten gehouden kan worden en alle monitoring out-of-thebox bijgehouden en geraadpleegd kan FIGUUR 11: GAE DIAGNOSTICS DASHBOARD worden. Een ander voordeel van de AppEngine is dat ook Logging op dit Dashboard te vinden is. Vanuit een applicatie worden (in het geval van Java) out/err.println() opgevangen en in de Logs gestopt, die op het Dashboard te raadplegen zijn (naar wens, per niveau). Niet alleen deze Java functies worden opgevangen, maar hier kan ook log4j of de java.util.logger voor gebruikt worden. Het nadeel is dat, als de logs ergens anders dan in het Dashboard terecht moeten komen, er een handmatige oplossing gemaakt zal moeten worden. En de documentatie hiervan is, uit eigen ervaring, niet optimaal. Microsoft heeft dit met Azure anders aangepakt. Op de web interface is namelijk geen monitoring te vinden en ook logging is niet hier inbegrepen. Dit zal de ontwikkelaar zelf moeten doen, gelukkig zitten er in Azure daarvoor de mogelijkheden. Hoewel dit allemaal zeer nieuw is (rond het moment van schrijven uitgebracht), zijn de mogelijkheden hiervan al wel bekend (Microsoft PDC, 2009). Microsoft heeft namelijk een Diagnostics SDK toegevoegd aan het Azure platform. Dit stelt ontwikkelaars in staat om logs bij te houden en nog meer informatie bij te houden. Het nadeel hiervan is dat ontwikkelaars zelf aanpassingen moeten maken in de code om logging toe te voegen. Een voordeel is dat er vanuit Microsoft wel informatie en vooral samples gemaakt zijn, die genoeg informatie bieden (zie Microsoft PDC 2009 sessies) om dit goed te kunnen implementeren. Tevens stimuleert Microsoft het maken van applicaties op Azure en die gebruik maken van technieken en verschijnen er dus al tools die het erg gemakkelijk maken om d.m.v. logs en verbruiksinformatie monitoring toe te passen. De ontwikkeling gaat rond deze tijd (eind 2009) erg snel en er komen steeds meer mogelijkheden binnen Azure die deze problemen aanpakken en oplossingen voordragen. Pagina 28