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 0.1
Datum 17-11-2009
0.2 0.3 0.4
15-12-2009 18-12-2009 09-01-2010
0.5
14-01-2010
1.0
15-01-2010
Wijziging Structuur en inhoudsopgave opgezet. Al uitgewerkte stukken ingevoegd. Scenario’s uiteengezet en omschrijving uitwerken. Uitwerkingen hoofdstuk 4 ingevoegd. Gedeelte scenario’s aangepast. Hier moet nog veel bijgevoegd worden. Scenario multicloud, Security met ACS en Cloud platforms aangepast. Tevens Enterprise Applicaties hoofdstuk uitgebreid met eisen. Schaalbaarheid aangevuld. Bronnen ingevoegd en begrippen geïdentificeerd. Scenario public back-end samengevoegd met public data en ingevoegd. Inleiding toegevoegd. 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
3.
4.
5.
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
Enterprise Applicaties ................................................................................................................................... 15 3.1.
Wat is het? ...................................................................................................................................... 15
3.2.
Eisen ................................................................................................................................................ 16
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
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.
H OE 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.
W AT 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?
C OMBINEREN 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).
E LASTICITEIT 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.
I NFRASTRUCTUUR C LOUD 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
T OEPASSEN C LOUD 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
S AMENGEVAT 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.
H OSTING , 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.
D ATA 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.
S CHAALBAARHEID 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.
K OSTEN 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.
V OLWASSENHEID 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.
H OSTING 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.
D ATA 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.
P ROCESSING 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.
V IRTUALISATIE 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.
E NTERPRISE A PPLICATION I NTEGRATION 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.
D ATA 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.
S ECURITY 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.
S CHAALBAARHEID 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.
G LOBAAL O VERZICHT Platform Azure
Programmeertaal
C# en .Net C++ PHP Java Ruby Python GoogleApps Python
Java SalesForce
Java .Net Perl PHP Python
Opmerkingen Meer talen zullen worden toegevoegd naar verloop van tijd (20-112009). Native programmeertalen voor Azure. Ondersteuning sinds de eerste versie en veel voorbeelden beschikbaar. Via de Visual Studio IDE Via SDK beschikbaar via de developer portal van Azure. Via SDK beschikbaar via de developer portal van Azure. Via SDK beschikbaar via de developer portal van Azure. Via SDK beschikbaar via de developer portal van Azure. Meer talen zullen toegevoegd worden naar verloop van tijd (20-112009). 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). Native Beschikbaar. Frameworks moeten ondersteund worden zie hier voor de GoogleApps developer portal. 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. Via packages Via API’s Zie devportal Salesforce voor voorbeelden Zie devportal Salesforce voor voorbeelden Zie devportal Salesforce voor voorbeelden
Pagina | 17
G OOGLE A PP E NGINE 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
A ZURE 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 Outgoing Bandwidth Incoming Bandwidth CPU Time Stored Data AppFabric Access Control (Microsoft.d)
Unit gigabytes gigabytes CPU hours gigabytes per month 100.000 transactions
Unit cost $0.15 $0.10 $0.12 $0.15 $1.99
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.
F ORCE P LATFORM (S ALES F ORCE ) 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.
D ATA 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.
N ON - RELATIONELE / OO DATABASES EN E NTERPRISE A PPLICATIONS 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
B ESTAND 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.
A LGEMENE SECURITY CONCERNS (B RODKIN , 2008) De volgende punten kunnen gebruikt worden bij het maken van een keuze voor Cloud serviceproviders. 1.
2.
3.
4.
5.
6.
7.
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. 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. 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. 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. 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. 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. 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
I DENTITY 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.
A CCESS C ONTROL S ERVICE (A PP F ABRIC ) 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.
G OOGLE A PP E NGINE 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
W INDOWS A ZURE 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.
D EPLOYMENT 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 gebruikt worden om te testen. En als dit FIGUUR 10: AZURE SERVICE OVERVIEW 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.
B EHEER 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-theFIGUUR 11: GAE DIAGNOSTICS DASHBOARD box’ bijgehouden en geraadpleegd kan 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
5. ENTERPRISE APPLICATIES & CLOUD COMPUTING Enterprise applicaties zijn over het algemeen groter, robuuster en stellen hoge eisen aan betrouwbaarheid. Tevens spelen schaalbaarheid en security in gedistribueerde omgevingen een grote rol. In dit hoofdstuk worden enkele scenario’s voorgelegd van mogelijke toepassingen van Cloud Computing binnen een Enterprise Applicatie. Aan de hand van enkele kernpunten worden deze scenario’s besproken en waar mogelijk onderbouwd met praktische voorbeelden.
5.1.
PUBLIC CLOUD
Veel van de beloftes van Cloud Computing lijken waar gemaakt te worden door applicaties volledig in de Cloud te plaatsen. Zo kan er gebruik gemaakt worden van schaalbaarheid, beheersbaarheid en pay-per-use. Maar in hoeverre is dit realistisch en kunnen deze beloftes ook daadwerkelijke waar gemaakt worden? In welke situaties is het mogelijk om een applicatie volledig in de Cloud te plaatsen? Door een praktische situatie te onderzoeken en toe te lichten wordt er naar een antwoord op deze vraag gezocht. Als voorbeeld wordt een starterbedrijf genomen, dat op zoek is naar een mogelijk kantoor applicatie tussen de verschillende aanbieders. Naast de on-premises oplossingen zoals Open Office heeft het bedrijf interesse in applicaties die uitsluitend in de Cloud draaien om zo maximaal gebruik te maken van het pay-per-use model. Natuurlijk spreekt de mogelijkheid om het gebruik te laten meeschalen met de bedrijfsgroei ook een grote rol. Een van de grote aanbieders op dit vlak is Salesforce die al geruime tijd kantoorapplicaties aanbied via hun Cloud en hier zal dan ook de voornaamste interesse liggen. Daarnaast gaan we nog uit van een situatie waarin een bedrijf een al bestaande JAVA SOAP webservice graag in zijn volledigheid in de Cloud van Google wil gaan plaatsen. De ontwikkelaars van deze applicatie zullen vervolgens moeten weten of dit mogelijke is en zo ja welke gevolgen dit met zich meebrengt. Situatie 1 – De Salesforce applicatie Een CRM applicatie door gebruik te maken van het Force platform met mogelijke uitbreidingen.
A RCHITECTUUR De opzet van Salesforce maakt het niet mogelijk om applicaties in de traditionele zin te realiseren. De architectuur van de basisapplicatie wordt bepaald door hoe deze samengesteld is in de browserbased ontwikkelomgeving. De architectuur voor communicatie tussen de verschillende onderdelen en dergelijke ligt vast.
S CHAALBAARHEID & PERFORMANCE Schaalbaarheid en performance worden bij Salesforce applicaties gegarandeerd door gebruik te maken van hun eigen browserbased ontwikkelomgeving. Deze heeft factoren die performance en schaalbaarheid kunnen beïnvloeden zelf in hand. Ook met de apex taal is er weinig te veranderen aan de schaalbaarheid al is performance hier wel te beïnvloeden, maar dit nog steeds in geringe mate. Communicatie met de Salesforce applicatie gaat doormiddel van SOAP based webservices. Op het moment dat men besluit om uitbreidingen te schrijven die dit toepassen zijn de gebruikelijke zorgen van toepassing.
S ECURITY Salesforce maakt bij browser versies boven Internet Explorer 5.5 gebruik van SSL voor de bescherming van data die over de kabel de Cloud ingestuurd wordt. Encryptie wordt toegepast om er voor te zorgen dat kwaadwillende geen inzicht kunnen krijgen in de Cloud. Gebruikers toegang wordt gestuurd via de portal van een klant, maar er kan ook gebruik gemaakt worden van identity management en single sign-on (Salesforce.a).
Pagina | 29
S UITABILITY Door beperkingen op te leggen bij het ontwikkelen en deze strak in de hand te houden (zoals Salesforce doet) is het mogelijke om in relatief korte tijd een Applicatie te realiseren die binnen een beproefde Cloud omgeving draait. Daarnaast is het goed mogelijke om te communiceren met applicaties gerealiseerd op het Force platform doormiddel van de SOAP communicatie. Dit maakt het platform geschikt voor kleine en middelgrote bedrijven die geen of beperkte mogelijkheden hebben voor applicatieontwikkeling. Er zal voor de meeste bedrijven genoeg rek in de opzet van Salesforce zitten om mee te groeien. Er zijn echter een aantal grote nadelen als men applicaties (of uitbreiding) ontwikkelt voor het Force platform. Zo is er geen test framework wat het onmogelijke maakt om op een flexibele manier unit test te gebruiken. Code wordt namelijk pas gecompileerd op het moment dat het naar het Force platform geüpload wordt. Situatie 2 – De JAVA webservice Een Java webservice gerealiseerd in de Google AppEngine.
A RCHITECTUUR Wijzigingen in architectuur worden voornamelijk bepaald door de functionaliteit van de service maar in de meeste gevallen zullen de verschillen beperkt blijven. Afhankelijke van hoe een organisatie er tot op dat punt voor gekozen heeft om webservices weer te geven.
S CHAALBAARHEID & PERFORMANCE Op dit vlak heeft de nieuwe service kans om zich te onderscheiden van een normale webservice binnen SOA. De service krijgt immers de kans om gebruik te maken van de schaalbaarheid van het Cloud Platform. Dit wordt wel gelimiteerd door een aantal factoren. Zo houden de meeste Cloud providers er limieten op na gebonden aan het gebruik. Bij overschrijden werkt mogelijke de applicatie niet meer voor een bepaalde tijd of moet er extra betaald worden om de limieten op te trekken. Een andere factor die vaak genegeerd wordt bij de realisatie van Cloud applicaties door developers is dat de software waar zij aan werken wel schaalbaar ingericht moet zijn. Het is immers niet zo dat software spontaan schaalbaar wordt als het in de Cloud geplaatst wordt. In verband met de hierboven genoemde limieten is het belangrijk dat de service niet overdadig is in het gebruik van de resources. Het nadeel van een pay-per-use model is natuurlijk dat je betaald voor wat je gebruikt. Daarnaast worden processen in de Google AppEngine gestaakt als ze overmatige tijd of resources in beslag nemen. Dit is natuurlijk te verhelpen met meer geld maar met die insteek lopen de kosten hard op. Daarnaast is het zinvol om rekening te houden met de snelheden die gebruikers halen via hun internetverbinding. Als het doel van de service zou zijn om een grote verwerking te maken met veel input en deze terug te sturen dan kan de performance snel achteruit lopen door middel van dataverkeer en mogelijke latency op het netwerk.
S ECURITY Google biedt de gebruikelijke basale hulpmiddelen voor communicatie zoals HTTPS en SSL. Deze kan geactiveerd worden via de appconfig bestanden. Daarnaast biedt het een aantal simpele beveiligingsmogelijkheden via de security API. De beveiliging met specifiek oog op Enterprise Applicaties heeft wat langer op zich laten wachten. Vanaf 16 november 2009 is er een API beschikbaar gesteld door LTech (partner van Google) die het mogelijke maakt om gebruik te maken van single sign-on en identies. Deze maakt het mogelijke om bijvoorbeeld on-premises ldap authenticatie te gebruiken in de AppEngine. Google lijkt vooralsnog geen specifieke keuzes gemaakt te hebben op het vlak van identity management.
Pagina | 30
S UITABILITY Op dit vlak gaat het belangrijk worden of de Google AppEngine wel voldoende ondersteuning heeft voor de implementatie van hedendaagse webservices. Het blijkt echter, zoals de paragraaf over de Cloud Platformen in dit onderzoek beschreven staat, dat hier zeker op het moment van dit onderzoek nogal wat problemen zijn. Google is op dit moment (18-12-2009) nog druk met de ontwikkeling van het platform. Met elke release van de SDK komen er meer packages beschikbaar maar vooralsnog is dit voor bijvoorbeeld JAX-WS nog niet het geval. Dit maakt realisatie van webservices al een stuk lastiger, er zijn echter wel alternatieven beschikbaar. De volgende problemen staan de ontwikkeling van webservices in de Google AppEngine in de weg:
Het is niet toegestaan om te schrijven naar vaste opslag van het lokale systeem. JAX-WS wordt niet ondersteund
De volgende problemen zijn opgelost:
Geen JAX-B ondersteuning tot voor SDK 1.2.8.
Applicaties die gerealiseerd zijn met een SDK van voor 1.2.8 kunnen overstappen naar JAX-B of ze kunnen gebruik blijven maken van de bestaande implementatie. De nieuwe SDK’s zouden vooralsnog geen invloed hierop mogen hebben. Het is daarnaast mogelijke om gebruik te maken van Maven doormiddel van een Maven Google AppEngine plug-in als is de werking daarvan niet bevestigd door dit onderzoek. Daarnaast is het positief om te zien dat het Spring framework zijn werk kan doen in de Google AppEngine. Dependencies zoals commons-logging functioneren ook en daarmee wordt het dus mogelijke om gewoon Spring te gebruiken voor de realisatie. Het feit dat men vanuit de cloud niet naar een lokaalstation kan schrijven kan door de hele implementatie heen een probleem zijn. Bijvoorbeeld; Als men voor org.springframework.ws.soap.axiom.AxiomSoapMessageFactory kiest als vervangende messagefactory moet er eerst een eigen implementatie gerealiseerd worden die deze klasse overerft en de methode setAttachmentCacheDir uitgeschakeld omdat deze zal proberen te schrijven naar het systeem. Op dit moment zal de Virtual Machine van de AppEngine een security warning weergeven. Als vervanging voor het JAX-WS framework kan vreemd genoeg een libary van concurrent SalesForce gebruikt worden. Deze hebben een API gerealiseerd waarmee niet alleen calls naar hun eigen systeem gemaakt kunnen worden maar ook een aantal functionaliteiten die het mogelijke maken om SOAP te implementeren. Deze library kan als executable gebruikt worden om aan de hand van een WSDL een libary te generen die de webservice implementeert. Dit geeft men meteen de mogelijkheid om een connectie op te zetten. Het is nog maar de vraag of gezien deze beperkingen en de vele afwijkingen met de normale gang van zaken de Google AppEngine al gezien kan worden als geschikt platform. Het is immers nog steeds in bèta en hoewel de groep gebruikers die actief meewerkt, groeit samen met de populariteit van Cloud Computing is het in de praktijk het geval dat het geheel zich nog in de kinderschoenen bevindt. Voor JAVA ontwikkelaars is het vooralsnog belangrijk om te begrijpen dat de AppEngine niet JAVA in zijn geheel ondersteund. Een duidelijk voordeel is dat Google zijn AppEngine wel degelijke geschikt wil maken voor Enterprise Applicaties en we zien bij de releases van SDK’s ook stappen in deze richting gezet worden. Of het platform geschikt is hangt dus af van een aantal factoren en de waarde die hieraan gehecht wordt. Maar het blijkt mogelijk om SOA te implementeren waarbij de gebruikelijke zorgen over Cloud Computing wel blijven meedingen. Het is vooral belangrijk om aan de toekomst te blijven denken. Een applicatie die eenmaal volledige in de Cloud draait inclusief backend is er moeilijk uit te halen.
Pagina | 31
5.2.
PUBLIC BATCH
Amazon is ooit begonnen met Cloud Computing omdat Amazon merkte dat diens datacenters een geweldige overcapaciteit hadden die nauwelijks gebruikt werd met uitzondering van enkele piekmomenten. Deze tekortkoming zien we bij veel datacenters waarbij er omgegaan wordt met piekbelasting door overcapaciteit in te calculeren. Een van de instellingen die hier mee te maken heeft is de belastingsdienst. Deze kent jaarlijkse twee pieken waarop er veel verwerkingskracht nodig is van haar eigen datacenters. De rest van het jaar doen deze betrekkelijke weinig met uitzondering van energie op verbruiken. Is het daarom niet beter om dit soort batch verwerkingstaken aan een Cloud te delegeren? Voorbeelden van het succesvol uitvoeren van dit model zijn al bekend. Aan de hand van het belastingsdienst voorbeeld gaan we kijken hoe een batchverwerking in de Cloud in zijn werk kunnen gaan. Architectuur Applicaties die gebruik maken van Amazon EC2 (Amazon’s PaaS) draaien op een of meerdere AMI’s (Amazon Machine Images). Deze bevatten een besturingssysteem met de software die nodig is om de ontwikkelde applicaties op de AMI’s uit te voeren. Qua architectuur hoeft er in principe dan ook weinig te veranderen ten opzichte van applicaties die buiten een Cloud draaien. Schaalbaarheid & performance Door gebruik te maken van de web service API’s van Amazon kan een applicatie elastische schalen door zelf nieuwe AMI’s op te starten of uit te schakelen. Dit kan op schaal van enkele images tot honderden simultaan wat applicaties de beschikking geeft over een schijnbaar ongelimiteerde opschaling. Zoals altijd blijft het hierbij wel van belang dat de applicatie gerealiseerd is op een manier dat deze schaalbaarheid ook daadwerkelijke gebruikt wordt. De grootste invloed op performance zal de communicatie zijn. Als er veel gegevens opgehaald moeten worden buiten het eigen netwerk dan wordt latency een beperkende factor voor de performance. Op latency zelf kan een ontwikkelaar weinig invloed uitoefenen. Men zou er wel voor kunnen kiezen om deze in te perken door gebruik te maken van de dataopslag faciliteiten die Amazon ook aanbiedt. Suitability Het voornaamste probleem in het scenario van de belastingsdienst is het gebrek aan mogelijkheden om verwerkingen op te schalen zonder dat hiervoor een groot aantal extra machines geplaatst moet worden. Amazon’s EC2 maakt het mogelijke om dit probleem aan te pakken. Het combineert daarmee ook een van de belangrijkste factoren van zowel Cloud Computing als Enterprise Applications. Daarnaast is het mogelijke om goede afspraken te maken met Amazon over de veiligheid en de beschikbaarheid van de gegevens. Een van de grotere nadelen bij het gebruik van Cloud Computing applicaties namelijk latency is relatief beperkt bij grote batchverwerkingen mitst de gegevens snel toegankelijke zijn voor de applicatie. Dat heeft als nadeel dat gevoelige gegevens op de een of andere manier in de Cloud geplaatst moeten worden. Er zijn een aantal maatregelen genomen door Amazon om dit risico in te perken. Security Amazon lijkt zich te realiseren wat voor invloed beveiligingsproblemen hebben bij Cloud Computing en heeft op dat vlak een aantal initiatieven gestart die de beveiliging van de gegevens in de Cloud probeert te garanderen. Naast bijvoorbeeld de mogelijkheid om firewalls aan te sturen heeft het met Amazon Virtual Private Cloud een service waarmee beveiligde verbindingen tussen het netwerk van een bedrijf en de Cloud opgezet kan worden. Daarnaast maakt de Virtual Private Cloud het ook mogelijke om alleen gebruik te maken
Pagina | 32
van servers in een bepaalde IP-adres range. Op deze manier kan ervoor gezorgd worden dat er alleen gebruik gemaakt wordt van de rekenkracht van servers in bijvoorbeeld Europa. Certificaten zijn daarnaast een belangrijk onderdeel van de security in de Amazon cloud. Toegang tot de API’s en bijvoorbeeld administrator toegang op de hostimages zijn voorbeelden waarbij certificering toegepast wordt (Amazon.a, 2009).
Pagina | 33
5.3.
CLOUD STORAGE
Het gebruik van Cloud Computing voor het op afstand bewaren van data heeft voor- maar ook zeker enkele nadelen. In dit hoofdstuk zullen verschillende Cloud data storage oplossingen bekeken worden, toegespitst op de aspecten architectuur, schaalbaarheid en performance, security en suitability. Googles Datastore en Microsofts Azure Storage vormen de lijdraad van dit hoofdstuk. Tot slot zal SQL Azure genoemd worden. De scenario’s die hierbij genomen zijn is ten eerste het gebruik van de storage services vanuit applicaties deployed in AppEngine en Windows Azure. Daarnaast zal de ondersteuning om deze services als storage back-end in zetten verkend worden. Situatie 1 – Googles Datastore
A RCHITECTUUR Google biedt geen oplossingen om direct, van buiten de Cloud, verbinding te maken met de DataStore. Het gebruik van DataStore is dan ook slechts mogelijk via applicaties die deployed zijn in de AppEngine. Dit is een grote beperking wanneer de DataStore slechts inzetten moet worden als back-end voor storage praktijken. In die situatie zal hij een webservice moeten realiseren die de DataStore API van buiten de Cloud beschikbaar maakt.
S CHAALBAARHEID & P ERFORMANCE Schaalbaarheid is een van de peilers waarop GAE en DataStore hun krachten baseren. Onderhuids maakt DataStore gebruik van BigTable en GFS. Beide zijn gericht om gestructureerde data schaalbaar en gedistribueerd op te slaan. Google maakt tevens zelf gebruik van BigTable en GFS voor een groot aantal van haar applicaties.
S ECURITY DataStore is verweven met de AppEngine en de gebruikersaccount waarmee de applicatie deployed is. Dit voorziet de service van enige security gezien iemand die de account gegevens niet kent dan ook geen toegang tot DataStore kan verkrijgen. Wanneer men de DataStore faciliteiten als storage back-end wil inzetten zal hij zelf verdere security maatregelen moeten treffen. Op het gebied van in- en uitgaande verbindingen ondersteunt AppEngine beperkt het gebruik van SSL. De beperking hier is dat een SSL verbinding slechts naar het appspot.com domein gemaakt kan worden via een URL als https://applicatie.appspot.com.
S UITABILITY Google DataStore betreft een object database dat gericht is op het efficiënt omgaan met het uitlezen van data en het verwerken van queries. Wanneer men specifiek een relationele database oplossing zoekt zal hij verder moet kijken, bijvoorbeeld naar SQL Azure welke later in dit hoofdstuk aanbod komt. Wat suitability betreft zijn er enkele beperkingen die mogelijk roet in het eten kunnen gooien. Zoals eerder genoemd is het niet mogelijk om direct verbinding te maken met de database. DataStore functionaliteit is alleen via in AppEngine deployed applicaties toegankelijk. Google biedt hierbij tevens ondersteuning voor Java en Python. Voor Java is er vervolgens ondersteuning voor de JDO en JPA API´s. Andere noemenswaardige beperkingen zijn enkele technische limieten die Google handhaaft bij haar AppEngine. Deze zijn:
Query result sets zijn gelimiteerd tot 1000 records. Queries hebben een time-out tijd van 30 seconden. Data structuren zijn gelimiteerd tot een grootte van 1MB.
Pagina | 34
Het betreft ruime getallen maar ze zijn wellicht te beperkend voor situaties waarbij bijzonder complexe queries die langer dan 30 seconden nodig hebben om te voltooien of queries met result sets groter dan 1000 records. De maximale entiteit grootte van 1MB zou een serieuze domper kunnen zijn, bijvoorbeeld wanneer men een PDF document die deze grootte overschrijd wil uploaden. Situatie 2 – Azure Storage
A RCHITECTUUR Het storage aanbod van Microsoft bestaat uit drie componenten. Namelijk Azure Table, Azure Blob en Azure Queue. Azure Table is vergelijkbaar met Google DataStore gezien deze entiteiten gestructureerd maar schemaloos opslaat. Azure Blob stelt de gebruik in staat om tekst of binaire data op te slaan. Daarnaast kan Azure Queue ingezet worden wanneer men gebruik wil maken van REST messaging om van binnen of buiten de Azure Cloud toegang te verkrijgen tot zijn data te verkrijgen. Een in Azure deployed applicatie zou de volgende architectuur kunnen hanteren, waarbij entiteiten in de Table Store gaan en ruwe data als bestanden naar de Blob Store tussen de front en backend, zie Figuur 12: Build Cloud application with azure queue.
FIGUUR 12: BUILD CLOUD APPLICATION WITH AZURE QUEUE
S CHAALBAARHEID & P ERFORMANCE Azure Tables is een schaalbare oplossing door het feit dat data gepartitioneerd opgeslagen word. Door deze partitionering kan data over verschillende servers in de Cloud verspreidt worden. De gebruiker heeft de optie om partitiegroepen te benoemen en data naar specifieke partities te schrijven. Relevante en samenhorige data kan op dezelfde partitie geplaatst worden wat de query efficiëntie ten goede komt.
FIGUUR 13: EXAMPLE OF PARTITIONS
Vergelijkbaar van Tables slaat Azure Blob zijn data gesegmenteerd op. Data in de vorm van blobs worden hierbij opgedeeld in meerdere blocks die individueel verspreidt kunnen worden over meerdere servers wat de schaalbaarheid ten goede komt. Daarnaast worden blobs gedistribueerd over meerdere servers voor verhoogde data zekerheid.
Pagina | 35
S ECURITY Toegang tot data wordt alleen verleend na het tonen van de user account key. Aan de hand van deze authenticatie waarborgt Microsoft dat alleen de eigenaar toegang tot zijn data kan verkrijgen. Connecties tussen de applicatie en Azure Storage kunnen overigens zowel over HTTP als HTTPS afhankelijk van hoe de gebruiker deze connecties opzet. Wanneer men gebruikt maakt van REST dient in elke request de account specifieke access keys opgenomen te worden. Daarnaast ken men gebruikelijke security praktijken van REST inzetten.
S UITABILITY Waar Azure Storage een streepje voor heeft op Google DataStore is de ondersteuning van REST door de Azure Queue service. Via deze service kunnen applicaties directe toegang tot de Azure Storage faciliteiten verkrijgen onafhankelijk van programmeerplatform en locatie. Daarnaast kan gebruik gemaakt van componenten uit het .NET framework zoals LINQ en ADO.NET voor het beheer en verkrijgen van data. Net als Google gelden er bij Azure Tables enkele technische limieten, deze zijn:
Query result sets zijn gelimiteerd tot 1000 records. Queries hebben een time-out tijd van 60 seconden. Data structuren zijn gelimiteerd tot een grootte van 4MB.
Hoewel Azure Tables exact dezelfde elementen als Googles DataStore limiteert zijn de waardes in de meeste gevallen ruimer. Bij Google zijn deze 1000 records, 30 seconden en 1MB.
SQL A ZURE Een extra storage service binnen Windows Azure is SQL Azure. Dit betreft een relationele database service, dat gebaseerd is op SQL Server technologie. Met deze service biedt Microsoft een laagdrempelige cloud database voor bedrijven met een bestaande SQL Server oplossing. Via de SQL Data Sync applicatie van Microsoft kunnen data en instellingen tussen SQL Server en SQL Azure gesynchroniseerd worden waarna SQL Azure de functionaliteiten van SQL Server binnen een applicatie kan overnemen. SQL Azure is daarbij volledig compatibel met tools de doorgaans voor SQL Server ingezet worden.
.
Pagina | 36
5.4.
MULTICLOUD
Interoperabiliteit is voor een Enterprise belangrijk. Er is heel zelden sprake van een ‘green field’ situatie waarin er geen rekening gehouden moet worden met bestaande data, applicaties of legacy systemen. Ook bij Cloud Computing speelt interoperabiliteit een rol, want hoe verloopt communicatie buiten de Cloud waar een applicatie zich bevindt? Is het mogelijk om delen van een applicatie is verschillende Clouds (van verschillende providers) te hebben en deze samen te laten werken? We gaan hier uit van een scenario waarin een deel van de applicatie zich in de Google Cloud bevindt en de andere in de Microsoft Cloud. In de AppEngine Cloud is een simpele (SOAP) webservice opgebouwd (in Java) die communiceert met een externe webservice om toegeleverde informatie te valideren. In de Azure Cloud is een applicatie aanwezig die informatie van een gebruiker vraagt, middels een formulier. Deze gegevens gaat de applicatie verifiëren door de AppEngine wenservice aan te roepen. Op die manier kunnen we testen in hoeverre de methodes aansluiten en welke stappen er ondernomen moeten worden om deze applicaties met elkaar te laten communiceren.
A RCHITECTUUR Een onderdeel van het Microsoft Azure platform is .NET Services (op moment van schrijven hernoemt naar AppFabric). In deze .NET Services zitten een Service Bus (SB) en Access Control Service (ACS). De SB neemt connectivity issues over van de gebruiker door op een makkelijke manier connecties te kunnen maken met externe services of applicaties. Hierin zit ook SOAP functionaliteit waar gebruik van gemaakt kan worden. Met ACS worden zaken als authenticatie geregeld, zonder de ontwikkelaar op de zadelen met veel configuratie. Dit kan doordat ACS is gebouwd op standaarden en hierdoor aansluiting heeft op veel gestandaardiseerde functies (Microsoft.b, 2010). Om de connectie van Azure naar de Webservice in AppEngine te maken, kan de SB gebruikt worden. Indien er een bepaalde vorm van authenticatie gebruikt moet worden, kan de ACS uitkomst bieden. De architectuur komt er dan uiteraard anders uit te zien. In de volgende figuur staat een weergave van de communicatie tussen de services. Microsoft
Google
.NET Service Bus
Applicatie
ACS
SOAP / HTTP
Applicatie
HTTP
Client
FIGUUR 14: MULTICLOUD COMMUNICATIE
Het gebruik van Cloud specifieke oplossingen zorgt ervoor dat de architectuur t.o.v. een normale Service Oriented Architecture wel anders wordt. Deze aanpassingen zijn nodig om enkele restricties, op het gebied van ondersteuning en aansluiting op standaarden, van de Cloud platformen weg te nemen. Ook maakt het de authenticatie makkelijker en draagt het bij aan een voordeel van Cloud Computing, namelijk minder zorgen om configuratie. Dit is allemaal al voor de ontwikkelaar gedaan en wordt in dit geval door Azure uit handen genomen. Nadeel is de afhankelijkheid van deze systemen en Cloud architectuur.
Pagina | 37
S CHAALBAARHEID & PERFORMANCE Een voordeel van het gebruik van de SB en ACS is dat de ontwikkelaar zich over de schaalbaarheid van beveiliging/authenticatie en service componenten geen zorgen hoeft te maken. Voor de applicatie zelf is het eigenlijk ook niet meer of minder een factor t.o.v. andere applicaties waar rekening mee gehouden moet worden. Aan beide kanten kan prima geschaald worden doordat beide applicaties onafhankelijk van elkaar zijn. Voor performance geldt hetzelfde. De bottlenecks die kunnen optreden zijn latency of performance van de AppFabric. Deze factoren liggen buiten bereik van de ontwikkelaar, dus tijdens de ontwikkeling kan hier geen rekening mee gehouden worden.
S ECURITY Gebruik maken van ACS biedt voldoende mogelijkheden om de applicatie te beveiligen en een single sign-on (niet voor iedere service opnieuw in te hoeven loggen) mogelijkheid te bieden, indien de verschillende services een andere autorisatie vereisen. Meer informatie over ACS staat in paragraaf 4.3. In samenwerking met de Service Bus (ook onderdeel van AppFabric en stelt verschillende applicaties in staat te communiceren) kan hiermee een veilige verbinding gemaakt worden over meerdere Clouds. Voor dit onderzoek was het helaas niet mogelijk om dit in de praktijk te testen, maar gebaseerd op de uitgebreide documentatie (Microsoft.b, 2010) van de AppFabric biedt het veel mogelijkheden om op een veilige manier de applicatie vorm te geven. Een nadeel kan zijn dat, mocht er al gebruik gemaakt worden van een bepaalde vorm van authenticatie (of identity management) het moeilijk kan zijn om met de ACS hierop aan te sluiten. Tevens stelt ACS eisen aan gebruikte protocollen. Echter wordt de ACS bij het realiseren van een service al geïmplementeerd, dan biedt het, nogmaals gebaseerd op documentatie en voorbeelden, zeer uitgebreide mogelijkheden.
S UITABILITY Een Multicloud applicatie heeft enkele voor- en nadelen die de suitability voor Enterprise Applicaties beïnvloeden. Het stuk in het public cloud scenario (5.1) is, hoewel toegespitst op Google’s AppEngine, ook van toepassing op dit scenario. Hierin zien we ook dat er beperkingen zitten aan het gebruik van Google AppEngine, maar als er meerdere Clouds gebruikt worden dan is er ook de afhankelijkheid van meerdere aanbieders. Deze aanbieders kunnen ieder hun eigen gebreken (of juist positieve aanvullingen) hebben en deze kennis moet er wel zijn. Een voorbeeld hiervan is Azure, met diens Service Bus en ACS die specifieke kennis vereisen. Interoperabiliteit speelt dus een grote rol. Het kan zijn dat bijvoorbeeld bij het maken van webservices er verschillende versies SOAP gebruikt worden of alleen maar REST wordt ondersteund. Ook het gebruik van andere security en identity management speelt een rol bij Multicloud ontwikkeling, zoals eerder besproken. Een reden om een Multicloud applicatie te ontwikkelen is bijvoorbeeld dat er al een bepaalde service zich in een andere Cloud bevindt en deze gebruikt moet worden. In het voorbeeld dat uitgewerkt is voor dit scenario is hier vanuit gegaan. Er bestaat een webservice in Google AppEngine die ISBN nummers kan valideren (die hiervoor overigens weer een andere webservice gebruikt, maar voor dit voorbeeld is dit niet relevant). Deze is als webservice aangeboden en willen we met Azure bereiken. We beperken hierbij het interoperabiliteit risico tot het protocol wat uitgekozen is, in dit geval SOAP over http. Dit maakt het geschikt om in beide Clouds te kunnen gebruiken. Hoewel de beste situatie natuurlijk één Cloud is, kan het zeker voorkomen dat er een reden is om een applicatie over meerdere Clouds te moeten verdelen. Deze mogelijkheid is er zeker, maar er moet dan wel op de mogelijke beperkingen t.a.v. interoperabiliteit gelet worden. Als dit goed uitgewerkt is, dan is Cloud Computing prima geschikt voor Multicloud Enterprise Applicaties.
Pagina | 38
6. CONCLUSIE In dit rapport is de volgende hoofdvraag behandeld: Welke invloed heeft Cloud Computing op de ontwikkeling van Enterprise Applicaties? De invloed op de ontwikkeling is afhankelijk van meerdere factoren. Dit is de vorm waarin het toegepast wordt, de Cloud aanbieder (of provider). Tevens zijn er nog enkele Cloud specifieke aspecten waar rekening mee gehouden moet worden bij het ontwikkelen van een Cloud gerichte applicatie. Er zal bij de ontwikkeling van een Enterprise Applicatie (hierna EA) eerst gekeken moeten worden op welke manier Cloud Computing toegepast wordt. Er zal bekeken moeten worden welke toepassing het beste bij een situatie pas. Hierbij maken we onderscheid tussen de in dit rapport uitgewerkte scenario’s: public Cloud, public batch, public storage, multicloud en als laatste die niet in scenario’s voorkomt, private Cloud. In dit laatste geval is er eigen beheer van de Cloud, waardoor vele inrichtingen mogelijk zijn. Uit de uitwerking van de scenario’s blijkt dat iedere toepassing weer andere invloeden op de ontwikkeling heeft. Als een toepassing gekozen is, hangt het ook sterk van de aanbieder af tegen welke beperkingen de ontwikkelaar aanloopt of juist welke mogelijkheden deze krijgt. Microsoft biedt met Azure een erg compleet platform met, binnen de AppFabric, een Service Bus en Access Control Service voor interoperabiliteit en security. Terwijl bijvoorbeeld Google met AppEngine dit niet heeft. Ook zijn de storage oplossingen van beiden verschillend. Salesforce en Amazon verschillen hiervan ook weer met wat deze aanbieden. Cloud Computing beheersbaarheid hangt ook af van de aanbieder. Google heeft op het gebied van monitoring al een gedeelte uit handen genomen, maar voor Azure zal de ontwikkelaar zelf iets moeten maken dat gegevens van de applicatie bijhoudt. Het gebruik van verschillende programmeertalen, en dus ook restricties tot het gebruik van een IDE, dragen er ook nog eens toe bij dat de invloed op de ontwikkeling van applicaties per aanbieder enorm kan verschillen. Hierbij komt ook de conclusie dat er wel sprake is van een bepaalde vendor lock-in, omdat voor iedere aanbieder specifieke kennis en inrichting van de applicatie vereist is. Wisselen tussen aanbieders zal dus resulteren in het aanpassen van de applicatie. Voor Cloud Computing in het algemeen is er ook sprake van invloeden op applicatie ontwikkeling. De Cloud aanbieders maken gebruik van het pay-per-use principe. Als een applicatie meer CPU tijd verbruikt, zal deze meer geld kosten. Voor de ontwikkeling geldt dus dat efficiënter gebruik van resources resulteert in een goedkopere applicatie. Een gevaar is wel dat Cloud Computing een schaalbare omgeving biedt, maar het nog steeds aan de applicatie zelf ligt in hoeverre het daadwerkelijk schaalbaar is. Zoals in het rapport aangegeven is zal als een applicatie buiten de Cloud niet schaalt, het dit binnen de Cloud waarschijnlijk ook niet doen. Hoewel de voordelen van Cloud Computing evident zijn, zal er bij de ontwikkeling dus wel rekening gehouden moeten worden met deze aspecten van Cloud Computing. Anders zullen deze niet volledig benut worden. Samengevat zal het ontwikkelen van een Cloud (Enterprise) applicatie (of het omzetten naar een Cloud) toegespitst moeten worden op de vorm van toepassing en de aanbieder. Lang niet iedere applicatie is geschikt om de voordelen van Cloud Computing te ervaren. Specifieke eisen of restricties, 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 | 39
7. BEGRIPPEN .Net
Applicatieframework ontwikkeld door Microsoft ten behoeve van samen werkingen tussen applicaties en libraries geschreven in verschillende talen.
Amazon Machine Images
Virtuele machine die het mogelijke maakt om gebruik te maken van het Cloud Computing netwerk van Amazon.
AMI
Zie Amazon Machine Images.
APEX
Programmeertaal voor het Salesforce platform. Lijkt op bijvoorbeeld Java.
AppExchange
Systeem waar ontwikkelaars van applicaties hun producten kunnen delen.
Applicatie
Een computerprogramma dat gebruikers in staat stelt om een informatiesysteem te gebruiken.
Applicatie Instantie
De applicatie tijdens uitvoer (of runtime).
Architectuur
Beschrijft de samenhang van applicaties en applicatie onderdelen binnen een informatiesysteem. Vaak in een modelmatige beschrijving.
Audit
Controle van de automatisering van een organisatie.
Availability
Beschikbaarheid van een dienst of product. Vaak onderhevig aan service level agreements.
BI
Zie Business Intelligence.
BigTable
Een door Google dataopslag.
Blob
Binary Large Object. Potentieel groot verzameling van bytes waar geen tekencodering aan is verbonden.
Business Intelligence
Het verzamelen van informatie binnen de eigen handelsactiviteit. Dit door gegevens te verzamelen en deze om te zetten naar informatie.
Certificaat
Een soort van digitaal paspoort wat gebruikt wordt voor beveiliging van computersystemen.
Cloud Computing
Het aanbieden van resources om verwerkingen uit te voeren of diensten aan te bieden.
Common-Interaction-Pattern
Een patroon om security aan de hand van tokens te orkestreren.
Compatibiliteit
Onderlinge aansluitbaarheid softwareconfiguraties.
Data
Gegevens. Kan bijvoorbeeld het resultaat zijn van de uitvoer van een applicatie.
Data Partitionering
Het opdelen van een onafhankelijke delen.
ontwikkelde
Salesforce
database
van
database
voor
verschillende
in
meerde
Pagina | 40
Datacenter
Locatie waar computerapparatuur wordt samengebracht en onderhouden. Doel kan zijn het aanbieden van de gezamenlijke rekenkracht of dataopslag.
Dataopslag
Het veelvoudig opslaan computersystemen.
Deployed
Het uitrollen van een applicatie naar een systeem zodat deze beschikbaar wordt voor gebruik.
Downtime
De tijd waarin een computersysteem niet beschikbaar is.
EC2 Service
Het Cloud Computing platform van Amazon.
Eclipse
Een open-source IDE vaak geassocieerd met Java.
Enterprise Applicatie
Een multi-user applicatie die een oplossing biedt voor een bedrijfsprobleem, tegenover een afdelingsprobleem.
Enterprise Application Integration
Het koppelen van meerdere Enterprise Applicaties, zodat deze samenwerken en tot een efficiënter geheel leiden.
Federated Identity
Een identiteit van een gebruiker tot stand gekomen doordat twee of meerdere systemen een gebruiker valideren en aspecten aan de identiteit toevoegen.
Framework
Een verzameling software componenten dat helpt bij het ontwikkelen van een computer applicatie.
Google AppEngine
Het Cloud Computing platform van Google.
Grid
Aan elkaar gekoppelde computersystemen met als doel gezamenlijke rekenkracht aan te bieden.
Horizontaal schalen
Het inzetten van meer machines of applicatie instanties om de verwerkingskracht te vergroten.
Hosting
Het opslaan en aanbieden van informatie, applicaties etc. zodat deze benadert en gebruikt kunnen worden.
IAAS
Het aanbieden van een computerinfrastructuur als dienst naar een gebruiker.
IDE
Integrated Development Environment. Een software ontwikkelomgeving voor programmeurs.
Identity
De identiteit van een gebruiker binnen een computersysteem. Kan bepaald worden door verschillende aspecten.
Identity Management
Het proces gericht op het administreren van gebruikers van computersystemen.
Internet
Een wereldwijd netwerk van computernetwerken.
van
gegevens
uit
Pagina | 41
Interoperabiliteit
De mate waarin systemen of apparatuur in staat zijn onderling uitwisselingen en/of communicatie te volbrengen.
Java
Platformonafhankelijke programmeertaal.
Java Development Kit
Software die programmeurs nodig hebben om Java applicaties te ontwikkelen, vaak afgekort met JDK.
JAX-B
Een Java API die het makkelijker maakt om toegang te krijgen tot XML documenten.
JAX-WS
Een Java API die het mogelijke maakt om webservices te realiseren.
Key/value database
Database waarbij datastructuren sleutelwaarde opgeslagen worden.
Latency
De tijd die nodig is voor informatie om van punt a naar b te komen.
LDAP
Lightweight Directory Access Protocol. Netwerkprotocol dat beschrijft hoe gegevens uit een directoryservice benaderd moeten worden.
Legacy Systemen
Een computersysteem dat ondanks de ouderdom nog steeds in gebruik is.
Library
Verzameling code functies en routines die door computerprogramma’s gebruikt kunnen worden.
Lifecycle management
Het management van een applicatie zijn hele levenscyclus van conceptie to uitfasering.
Load
Indicatie van de werklast op een computersysteem.
Loadbalancing
Een techniek om de werklast te verdelen tussen verschillende systemen.
Logging
Het bijhouden van voor gedefinieerde gebeurtenissen in een computersysteem.
Microsoft Azure
Het Cloud Computing platform van Microsoft.
Middleware
Computersoftware dat het mogelijke maakt om verschillende softwareonderdelen of applicaties met elkaar te laten communiceren.
Monitoring
Het bewaken van voor gedefinieerde criteria op een computersysteem.
On-premises
Aanwezig op de bedrijfslocatie.
On-demand
Op het moment dat de gebruiker iets wil bijvoorbeeld extra verwerkingskracht kan dit meteen opgeroepen worden.
ORM
Programmeertechniek die het mogelijke maakt om data om te zetten tussen een relationele database en een objectgeoriënteerde applicatie.
objectgeoriënteerde
onder
een
Pagina | 42
Outsourcing
Het uitbesteden van bedrijfsactiviteiten aan een dienstverlenende onderneming.
PAAS
Het aanbieden van een computerplatform als service.
Paradigma
Beschrijft de stijl waarin geprogrammeerd wordt.
Pay-as-you-go
Betalingsmodel waarbij er betaald wordt voor wat er gebruikt wordt in plaat van bijvoorbeeld een abonnement met maandelijkse kosten en limieten,
Python
Een in de jaren negentig ontworpen dynamic strong programmeertaal.
Resource
Een hulpmiddel wat gebruikt kan worden om een bepaald doel te bereiken.
REST
Representational State Transfer. Stijl van software architectuur voor gedistribueerde systemen.
SAAS
Software As A Service. Het aanbieden van software als afneembare dient.
Schaalbaarheid
Betreft de mate waarin een applicatie of component in staat is zijn capaciteit te verhogen.
SDK
Software Development Kit. Verzameling hulpmiddelen die nodig of handig zijn voor het ontwikkelen van computerprogramma’s. Vaak voor een specifieke taal of systeem.
Security
Beveiliging tegen dreigingen.
Server
Computersysteem of applicatie dat diensten verleent.
Service
Dienst die gebruikt kan worden.
Service Provider
Aanbieder van een service.
SimpleDB
Schemaloze database service van Amazon.
Single Sign-on
Technologie waarmee aan de hand van een enkele inlog procedure de identiteit van de gebruiker vastgesteld wordt voor gebruik in meerdere applicaties.
SOA
Service Oriented Architecture. Set van principes. Toegepast op een informatiesysteem zou moeten leiden tot een aantal geïntegreerde services.
Software Stack
Een koppeling van meerdere softwarecomponenten dat als geheel een gezamenlijk doel nastreeft.
SQL Transacties
Een aaneenschakeling van een of meerdere SQL queries die als eenheid uitgevoerd wordt.
Stacktrace
Hiërarchische lijst met gekoppelde softwarecomponenten met het doel om foutief gelopen processen te herleiden.
Pagina | 43
Stored Procedures
Vastgelegde en herbruikbare procedures of aaneenschakelingen van functies bij database systemen.
Suitability
In de context van informatica betreft dit de mate van geschiktheid als oplossing voor een probleemstelling.
Terrabyte
Eenheid waarin data opslagcapaciteit gemeten word.
Thick (client) platform
Variant van thin client waarbij het platform tevens zelf rekenkracht in respectievelijk grotere mate inzet,
Thin (client) platform
Client platform met betrekkelijk weinig rekenkracht dat voornamelijk applicaties vanuit een ander systeem visualiseert.
Tracing
Waarneming en vastlegging van fouten in de operatie van een applicatie.
Triggers
In de context van database systemen betreft dit het uitvoeren van een procedure wanneer een bepaald situatie afspeelt.
Unit Testing
Testen van componenten op code niveau of resultaten naar verwachting geproduceerd worden.
Utility Computing
Aanbod van opslagruimte computersystemen.
Versionering
Inzetten van nieuwe of terugschakeling naar een oudere versie van een softwareapplicatie.
Verticaal schalen
Schalen aan de hand van het inzetten van meer hardware.
Verwerkingskracht
Mate van snelheid en capaciteit waarin een computersysteem berekeningen maakt.
Virtualisatie
Techniek waarmee op een enkel computersysteem meerdere besturingssystemen simultaan kunnen functioneren.
VisualForce
Applicatie voor gebruikersinterfaces.
Volwassenheid
In de context van informatica betreft dit de mate van de inzetbaarheid, betrouwbaarheid en integriteit van een product of dienst in ontwikkeling.
Webserver
Software applicatie dat over het HTTP protocol web content zoals webpagina’s aanbiedt.
Webservice
Software systeem dat door de uitwisseling van XML documenten platformonafhankelijk gegevens kan verstrekken of verwerken.
WSDL
Web Services Description Language. Een XML bestand dat messages, types, bindings en endpoints van een webservice omschrijft.
het
of rekenkracht
ontwerpen
van
van
Pagina | 44
8. BIBLIOGRAFIE Amazon.a. (2009, 11). AWS Security. Retrieved 1 11, http://awsmedia.s3.amazonaws.com/pdf/AWS_Security_Whitepaper.pdf
2010,
from
Amazon
:
Brodkin, J. (2008, 8 30). Gartner: Seven cloud-computing security risks. Retrieved 10 2010, from InfoWorld: http://www.infoworld.com/d/security-central/gartner-seven-cloud-computing-security-risks-853 Browne, J. (2009, Januari 11). Brewer's CAP Theorem. Retrieved Januari 4, 2010, from julianbrowne: http://www.julianbrowne.com/article/viewer/brewers-cap-theorem Cloud Computing Testing. (2009, October). Retrieved December 15, 2009, from BreakingPoint: http://www.breakingpointsystems.com/solutions/cloud-infrastructure-testing Compact.nl. (n.d.). Retrieved from http://www.compact.nl/img/C-2005-3-Verbree-01.jpg Gartner.a. (2008, April 2). Gartner Says Virtualization Will Be the Highest-Impact Trend in Infrastructure and Operations Market Through 2012. Retrieved Oktober 12, 2009, from Website van Gartner IT: http://www.gartner.com/it/page.jsp?id=638207 Gartner.b. (2009, Augustus 11). Gartner's 2009 Hype Cycle Special Report Evaluates Maturity of 1,650 Technologies. Retrieved Oktober 10, 2009, from Website van Gartner IT: http://www.gartner.com/it/page.jsp?id=1124212 Google.a. (2009, 10 4). Quotas . Retrieved http://code.google.com/appengine/docs/quotas.html Google.b. (n.d.). Google App Engine. http://en.wikipedia.org/wiki/Google_App_Engine
1
4,
Retrieved
2010,
1
from
2010,
Google
4,
from
App
Engine:
Wikipedia:
Google.c. (2009, December 3). Will it play in App Engine. Retrieved December 5, 2009, from Google App Engine for Java: http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine Gottfrid, D. (2007, November 1). Self-service, Prorated Super Computing Fun! Retrieved November 18, 2009, from The New York Times - Open: http://open.blogs.nytimes.com/2007/11/01/self-service-prorated-supercomputing-fun/ Harrison, G. (2008, Juni 15). Is the Next DBMS Revolution Looming? Retrieved 2009, from Database Trends and Applications: http://www.dbta.com/Articles/Editorial/Trends-and-Applications/Is-the-Next-DBMS-RevolutionLooming-51615.aspx How Google App Engine Datastore Works. (2009, December 31). Retrieved Januari 4, 2010, from CTOEDGE: http://www.ctoedge.com/content/how-google-app-engine-datastore-works IT PRO. (2009, Februari 3). Gartner says cloud computing needs to mature . Retrieved Oktober 10, 2009, from IT PRO: http://www.itpro.co.uk/609749/gartner-says-cloud-computing-needs-to-mature Jai Haridas, Niranjan Nilakantan, Brad Calder (Microsoft). (2009). WINDOWS AZURE TABLE. Johnston, S. Cloud Computing economics. Cloud Computing economics. Wikipedia, Internet. Microsoft PDC. (2009, November 18). Windows Azure Monitoring, Logging, and Management APIs. Retrieved December 18, 2009, from Microsoft PDC 2009: http://microsoftpdc.com/Sessions/SVC15
Pagina | 45
Microsoft.a. (2010). Building Web Services that Trust AC. Retrieved Januari 10, 2010, from MSDN Azure Platform: http://msdn.microsoft.com/en-us/library/ee725241.aspx Microsoft.b. (2010). AppFabric Access Control Service. Retrieved Januari 10, 2010, from MSDN Microsoft: http://msdn.microsoft.com/en-us/library/ee732536.aspx Microsoft.c. Products Overview Infographic. http://www.microsoft.com/windowsazure/img/products-overview-infographic.gif. Microsoft.d. (n.d.). Azure Platform Pricing. Retrieved http://www.microsoft.com/windowsazure/pricing/
1
4,
2010,
from
Microsoft,
Microsoft
Windows:
Microsoft.e. (n.d.). Windows Azure Blob – Programming Blob Storage. Retrieved December 2009, from Microsoft. Microsoft.f. (n.d.). Windows Azure Table – Programming Table Storage. Retrieved December 2009, from Microsoft: http://go.microsoft.com/fwlink/?LinkId=153401 Microsoft.g. (n.d.). Windows Azure Queue - Programming Queue Storage. Retrieved December 2009, from Microsoft. Pettey, C. (2009, 10 20). Gartner Identifies the Top 10 Strategic Technologies for 2010. Retrieved 11 2009, from Gartner: http://www.gartner.com/it/page.jsp?id=1210613 Salesforce.a. (n.d.). Security. Retrieved http://trust.salesforce.com/trust/security/
1
8,
2010,
from
SalesForce.com:
Turban, E. (2008). Electronic Commerce A Managerial Perspective. Retrieved Oktober 12, 2009, from PrenticeHall: http://wps.prenhall.com/wps/media/objects/5073/5195381/pdf/Online_Chapter_19.pdf Washington Technology. (2009, Maart 23). Cloud computing needs standards to mature, experts say. Retrieved November 1, 2009, from Washington Technology: http://washingtontechnology.com/articles/2009/03/23/web-cloud-computing.aspx Wikipedia.a. (n.d.). Utility Computing Wikipedia. Retrieved November 10, 2009, from Wikipedia: http://en.wikipedia.org/wiki/Utility_computing Wikipedia.b. (2009, December 31). Scalability. Retrieved Januari 10, 2010, from Wikipedia, the free encyclopedia: http://en.wikipedia.org/wiki/Scalability Wikipedia.c. (n.d.). Cloud Computing. http://en.wikipedia.org/wiki/Cloud_computing
Retrieved
10
13,
Wikipedia.d. (n.d.). Cloud Computing. http://nl.wikipedia.org/wiki/Cloud_computing
Retrieved
10
2009,
2009,
from
Wikipedia:
13,
from
Wikipedia:
Wikipedia.e. (n.d.). Enterprise application integration. Retrieved Oktober 30, 2009, from Wikipedia NL: http://nl.wikipedia.org/wiki/Enterprise_application_integration
Pagina | 46
I.
BIJLAGE ‘THE NIST DEFINITION OF CLOUD COMPUTING’
A UTHORS : P ETER M ELL AND T IM G RANCE V ERSION 15, 10-7-09 N ATIONAL I NSTITUTE OF S TANDARDS AND T ECHNOLOGY , I NFORMATION T ECHNOLOGY L ABORATORY
Note 1: Cloud computing is still an evolving paradigm. Its definitions, use cases, underlying technologies, issues, risks, and benefits will be refined in a spirited debate by the public and private sectors. These definitions, attributes, and characteristics will evolve and change over time. Note 2: The cloud computing industry represents a large ecosystem of many models, vendors, and market niches. This definition attempts to encompass all of the various cloud approaches.
D EFINITION OF C LOUD C OMPUTING : Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models.
Essential Characteristics: On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service’s provider. Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs). Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, network bandwidth, and virtual machines. Rapid elasticity. Capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time. Measured Service. Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported providing transparency for both the provider and consumer of the utilized service.
Pagina | 47
Service Models: Cloud Software as a Service (SaaS). The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings. Cloud Platform as a Service (PaaS). The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations. Cloud Infrastructure as a Service (IaaS). The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).
Deployment Models: Private cloud. The cloud infrastructure is operated solely for an organization. It may be managed by the organization or a third party and may exist on premise or off premise. Community cloud. The cloud infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be managed by the organizations or a third party and may exist on premise or off premise. Public cloud. The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services. Hybrid cloud. The cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for loadbalancing between clouds). Note: Cloud software takes full advantage of the cloud paradigm by being service oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability.
Pagina | 48
