Evaluering af Udbud og Modenhed af Cloud Computing Software Teknologier Præsentation af hovedopgave og resultater Vejleder: Henrik Bærbak Christensen Af:

Præsentationer af emnet: "Evaluering af Udbud og Modenhed af Cloud Computing Software Teknologier Præsentation af hovedopgave og resultater Vejleder: Henrik Bærbak Christensen Af:"— Præsentationens transcript:

1 Evaluering af Udbud og Modenhed af Cloud Computing Software Teknologier Præsentation af hovedopgave og resultater Vejleder: Henrik Bærbak Christensen Af: Thomas Mollerup Lanng 20070583 {u070583@cs.au.dk, thomas.lanng@gmail.com} Dato: 04.02.2011

2 Disposition Præsentation af hoved ideerne i hovedopgave: – Motivation – Problemstilling – Hovedkonklusioner Detaljeret redegørelse for eksperimentet omkring udvikling af services, usability scenarie 2, afsnit 7.3.2.

3 Motivation og problemstilling

4 Motivation Cloud computing : Aktuelt emne og spændende emne, hvordan kan dette emne sættes i en problem kontekst Vs. Definition af Cloud computing [Buyya et al.]: En cloud er en parallel og distribueret type system bestående af en samling forbundne og virtualiserede computere, som allokeres dynamisk og præsenteres som en computer ressource baseret på service level agreements (SLA) etableret gennem forhandling mellem service udbyder og service brugere Definition af Autonomic computing [Kephart et al.]: Store computer systemer, der styrer sig selv i forhold til højniveau målsætninger fra mennesker. De lever deres eget liv og fungerer autonomt i deres miljø.

5 Motivation [Buyya] definerer en markeds baseret Cloud arkitektur med følgende krav til kommercielle produkter. Krav idBeskrivelse K.1 Support customer-driven service management based on customer profiles and requested service requirements K.2 Define computational risk management tactics to identify, assess, and manage risks involved in the execution of applications with regards to service requirements and customer needs K.3 Derive appropriate market-based resource management strategies that encompass both customer-driven service management and computational risk management to sustain SLA-oriented resource allocation K.4 Incorporate autonomic resource management models that effectively self-manage changes in service requirements to satisfy both new service demands and existing service obligations K.5Leverage VM technology to dynamically assign resource shares according to service requirements. QoSQoS parameters to consider in a service request, such as time, cost, reliability and trust/security. In particular, QoS requirements cannot be static and need to be dynamically updated over time due to continuing changes in business operations and operating environments. In short, there should be greater importance on customers since they pay for accessing services in Clouds.

6 Motivation [White et. al] definerer en self managed arkitektur til opfyldelse af autonomic computing aspekter [White et. al] definerer krav et autonomt element som indgår i den self managed arkitektur. Aspekt Beskrivelse Self- configuration Automatiseret konfiguration af komponenter og system som følger højniveau politikker. Resten af system justerer sig automatisk og problemfrit. Self-healingSystemet detekterer automatisk, diagnosticerer og reparerer lokaliserede software og hardware problemer. Self-optimizingKomponenter og systemer søger kontinuerligt at forbedre deres ydelse og effektivitet. Self-protectingSystemet forsvarer sig automatisk mod ondsindede angreb eller flere på følgende fejl. Det benytter tidlig advarsel og forhindrer fejl på system niveau.

7 . HovedkategoriUnderkategoriKrav IdKrav beskrivelse OpførselElementKO.1Skal være self-managing det vil sige ansvarlig for: - intern konfiguration(self-configuration) - overkomme interne fejl (self-healing) - optimering af opførsel (self-optimizing) - beskytte mod ekstern probing og angreb (self-protecting) KO.2Skal håndtere problemer lokalt, hvor muligt for at gøre global system management simplere (service afhængighed ikke opfylder aftale - f.eks. kræve den opfyldes eller afslutte relation og finde en anden service udbyder ) RelationerKO.3Etablere og vedligeholde relationer med andre autonome elementer herunder hvilke services udbydes til og services som benyttes KO.4Service skal beskrives korrekt og være tilgængelig og forståelig for andre autonome elementer KO.5Skal forstå og opfylde aftale krav KO.6Skal kunne forhandle for at etablere aftaler (relationer) KO.7Skal kunne styre opførsel og relationer således, at dens forpligtigelser(obligations) opfyldes, dette kan gøres ved konfiguration af egne parametre eller ved at anvende andre autonome elementers resurser Politikker (policies)KO.82 typer forpligtigelse(obligations): - opfylde aftaler(agreements) og - modtage og opfylde politikker(policies) KO.9Skal forkaste service forespørgsler som bryder politikker eller aftaler KO.10Skal nægte eller give andre forslag til foreslåede relationer eller politikker som vil bryde eksisterende relationer eller politikker KO.11Administrative relationer håndteres lige som andre relationer KO.12Direktiver modtagnes på samme måde som andre forespørgsler; hvis politikken beskriver at forespørgeren har rettighed til at få udført kommando, så udføres denne KO.13Konfliktende forespørgsler fra administrative elementer skal løses af det modtagne element KO.14Skal kunne oversætte højniveau, globale direktiver til specifikke aktiviteter vha. politikker KO.15En politik er en repræsentation i en standard ekstern form for ønskede opførsel eller begrænsninger på opførsel KO.16Der tillades mindst 3 niveauer af relaterede politikker: - Action politikker er den laveste politik specifikation, som typisk har en if-then kontrol struktur f.eks. If(ResponseTime > 2 sec) Then (CPU+5%) - Et autonomt element der benytter action politikker skal måle kvantiteterne beskrevet i betingelsen(If) og udføre action (Then), når betingelsen er opfyldt - Mål politikker (goal policies) er det mellemste niveau af politikker, som beskriver betingelser som skal opfyldes, men uden at beskrive hvordan, dette kunne f.eks. være respons tid må ikke overstige 2 sek. - Utility function politikker er det højeste niveau af politikker, som at specificere de relative ønskede alternative tilstande, hvilket opnås ved at tildele en numerisk værdi eller en partiel eller fuldstændig beskrivelse af rækkefølge for mulige tilstande KO.17Et autonomt element, der benytter action politikker, skal måle kvantiteterne beskrevet i betingelsen(If) og udføre action (Then), når betingelsen er opfyldt KO.18Et element, der benytter Utility function politikker, skal have tilstrækkelig modellering og optimeringsegenskaber for at oversætte mål til actions InterfaceElementKI.1Udover standard interfaces som en serviceorienteret arkitektur beskriver, hvor services beskrives, søges/findes og leveres skal autonome elementer yderligere realisere interfaces for at opnå self management Monitoring og test interfaces KI.2Dette gør det muligt for at et element at blive monitoreret af et andet element med de nødvendige rettigheder KI.3Kan anvendes til at styre mængden af logning og trace data, som et element indsamler og få tilgang til dette data KI.4Kan anvendes til at instruere et element til at udføre en self-test og tilgå resultater Lifecycle interfacesKI.5Muliggør for administrative elementer at forespørge lifecycle tilstanden af et element f.eks. om det er startet eller i pause og hvilken lifecycle model der anvendes KI.6Muliggør ændring af lifecycle tilstand for et element f.eks. nedlukning Politik interfaceKI.7Muliggør for administrative elementer at sende nye politikker til et element og politikker som anvendes at elementet Negotiation og binding interfaces KI.8Tillader et element at forespørge en service fra et andet element eller at blive forespurgt at levere en service KI.9I den simple form, som anvendes i serviceorienteret arkitekturer, tillades et element at forespørge en specifik service og modtage enten en bekræftelse eller en fejl KI.10I den avancerede form som tillader mere fleksibel self-management kan elementer også understøtte interfaces som tillader: forslag eller mod forslag, forhandling om eksakte betingelser og egenskaber for service der skal leveres (herunder reliabilty, availability, performance mv.), og dannelse og styring af langtids relationer Relationer (relationships) KI.11Opstår når et element har tilladt at levere en service til et andet element typisk ved forhandling mellem elementerne KI.12En forhandling kan fejle som følge af manglende rettigheder eller elementet ikke har tilstrækkelige ressourcer KI.13Relationer er måden hvorpå elementer sammensættes til at danne et autonomt system KI.14Relationer dannes typisk runtime (modsat fastholdt ved udrulning) og kan ændres på et givent tidspunkt KI.15Relationer dannes af elementerne selv og ikke af administratorer Inteaction integrityKI.16Et autonomt element skal kommunikere med andre elementer via service interfaces defineret i den tilknyttede service specifikation og må ikke kommunikere på andre måder KI.17Et elements interne kommunikation må ikke blive tilgængelig udenfor elementet System sammensætning InteraktionKS.1For at opnå self management på system niveau skal dets elementer være i stand til at kommunikere og koordinere, således at deres gensidige mål kan opnås. DiscoveryKS.2Autonome elementer skal kunne finde/søge andre elementer KS.3Autonome elementer skal kunne identificere andre elementer for kommunikation KompositionKS.4Autonome elementer skal via andre elementer kunne opnå end-to-end service level mål Støtte elementerKS.5For at opnå dette anvendes et antal af infrastruktur elementer: Registry: - Tilbyder mekanismer således elementer kan finde andre elementer og forbinde sig med hinanden - Tilbyder mekanismer således elementer kan publicere services Sentinel: - Tilbyder services til monitorering for andre elementer Aggregator: - Kombinere 2 eller flere elementer, således at en forbedret services kan tilbydes f.eks. højere pålidelighed eller performance end elementer hver for sig er i stand til Broker: - Faciliteter interaktion f.eks. ifm. at støtte et element med at udføre opgaver som kræver komplekse relationer - Kan danne en aggregering af elementer, som opfylder specifikt behov f.eks. lagringsservices og give denne adresse til et element Negotiator: - Støtter andre elementer i at fortage komplekse forhandlinger som f.eks. kræver rationale som det enkelte element ikke er i stand til, f.eks. trade off latency ift. Throughput

8 Motivation Cloud computing og Autonomic computing forekommer at have lignende egenskaber indenfor ressource management baseret på politikker Definere problemformulering, hvor cloud computing teknologier undersøges for understøttelse af autonomic computing.

9 Problemstilling I denne rapport foretages en evaluering af udbud og modenhed af cloud computing teknologier, der understøtter autonom computing teorien, som defineret af [Kephart et al.] I projektet vil følgende spørgsmål blive besvaret: Hvilke cloud computing teknologier understøtter helt eller dele af teorien? Hvordan er modenheden af de aktuelle cloud computing teknologier?

10 Problemstilling Modenheden af de udvalgte cloud computing teknologier vurderes ud fra en evalueringstaksonomi med følgende kriterier: – Hvor godt understøttes autonomic computing teorien? – Hvor svært er det at anvende (defineret vha. usability kvalitetsattribut scenarier)? – Hvor god er dokumentationen? – Hvordan vedligeholdes teknologien? – Hvilken værktøjs understøttelse findes? – Hvilke standarder understøttes?

11 Metode Problemformuleringen behandles i en faseopdelt metode, som tillader planlægning af opgave i tids opdelinger. Aktiviteter i faserne, som er styret af kriterier

12 Metode Taksonomi og evaluerings kriterier

13 Hovedkonklusioner

14 Foranalyse – Udbud af teknologi kandidater Eksperiment – Usability scenarier Samlet konklusion – Problemstilling

15 Hoved konklusioner - Foranalyse Stor brutto kandidatliste for cloud computing teknologier - projektet fortsatte ift. Beslutning ’gate’ 21 kandidater fundet – Fravalgte kandidater klassificeret i: Udgået teknologi Ikke baseret på public cloud model Anvendelse af proprietær teknologi som ikke tillader åbenudvikling på platform Mangel på brugerdokumentation og værktøjsunderstøttelse Mangel på understøttelse af cloud computing og self managed arkitektur egenskaber 5 kandidater udvalgt – Microsoft Azure – Heroku – Amazon Web Services (AWS), EC2 – Joyent – Google App Engine

16 Hoved konklusioner - Foranalyse Kandidater Kriterier Evaluering Microsoft AzurePlatformAzure er PaaS med mulighed for IaaS for Windows server virtuel maskine. Asure understøtter.Net teknologi og har mulighed for konfiguration af andre runtime miljøet herunder Java. AnvendelsesdomæneEn uafhængig software leverandør (independent software vendor - ISV) kan udvikle applikationer målrettet forretningsbrugere. Software as a Service (SaaS) En ISV kan målrette en SaaS applikation til forbruger grupper Organisationer kan anvende Microsoft Azure til udvikling af applikationer til ansatte LicensmodelAzure understøtter: forbrugsmodel og abonnent model, hvor der betales et fast beløb for en periode, herefter time prisen reduceres for ressourcen. StyringsmyndighedMicrosoft corporation. Understøttende standarderAzure understøtter.NET teknologi, web services teknologi REST for infrastruktur services og egne teknologier til f.eks. databaser vha. TDS. VedligeholdelseUdfører vedligeholdelse af udviklingssoftware, service interfaces og instans software med daglig, månedlig og kvartal frigivelsesplaner. BrugerunderstøttelseLeverer dokumentation af service interfaces og udviklingssoftware samt guides. Desuden gives mulighed for bruger interaktion i form af fora og andre kanaler VærktøjsunderstøttelseLeverer software udviklingsværktøj (SDK) til applikationsudvikling. Leverer udover.NET også til Ruby, Java og PHP. Understøtter Eclipse IDE integration. ArkitekturAzure opfylder delvis autonomic computing krav. I forhold krav Politikker KO.8-18 er det ikke muligt vha. politikker at bestemme, hvordan systemet skal opfører sig i givne situationer f.eks. under CPU belastning. I forhold krav Interfaces krav KI.1-17 er der ikke mulighed for at forespørge tilstanden eller lifecycle model af en given service. KvalitetsattributterUdføres på udvalgte kandidat i eksperiment

17 Hoved konklusioner - Foranalyse Kandidater Kriterier Evaluering Heroku PlatformHeroku er PaaS baseret på Ruby teknologi. AnvendelsesdomæneMålretter platformen til udvikling af web applikationer LicensmodelUnderstøtter en forbrugsmodel. StyringsmyndighedHeroku incorporated fra den 31. januar 2011 en underafdeling af Salesforce.com incorporated. Understøttende standarderHeroku anvender Ruby til runtime miljø og applikationsudvikling. Derudover anvendes REST til applikations management service. VedligeholdelseUdfører vedligeholdelse af udviklingssoftware, service interfaces og instans software med daglig, månedlig og kvartal frigivelsesplaner. BrugerunderstøttelseLeverer dokumentation af service interfaces og udviklingssoftware samt guides. Desuden gives mulighed for bruger interaktion i form af fora og andre kanaler VærktøjsunderstøttelseLeverer software udviklingsværktøj (SDK) til applikationsudvikling ArkitekturHeroku opfylder delvis autonomic computing krav. I forhold til krav Element KO.1, KO.2 og Relationer KO. 3-7 og System KS.1-5 gives der ikke mulighed for service discovery for understøttelse af konfiguration af service sammensætning. Desuden findes der ikke mekanismer eller services for selvbeskyttelse i forhold til krav Element KO.1, KO.2. I forhold krav Politikker KO.8-18 er det ikke muligt vha. politikker at bestemme, hvordan systemet skal opfører sig i givne situationer f.eks. under CPU belastning. I forhold krav Interfaces krav KI.1-17 er der ikke mulighed for at forespørge tilstanden eller lifecycle model af en given service. KvalitetsattributterUdføres på udvalgte kandidat i eksperiment.

18 Hoved konklusioner - Foranalyse Kandidater Kriterier Amazon Web Services (AWS), EC2 PlatformEC2 er IaaS og understøtter virtuelle maskiner baseret på forskellige operativ systemer med mulighed for konfiguration af forskellige runtime miljøer og applikationer. AnvendelsesdomæneEn infrastruktur web services platform, som kan tilbydes organisationer af forskellige størrelser. Computer, lagring og andre services kan købes efter forretningsbehov. Der er mulighed for at vælge udviklingsplatform og programmering model efter det specifikke behov. Forskellige forretningsområder nævnes, som målgrupper for den fleksible udvidelse af ressourcer, herunder e- handel, som ikke kan forudsige web trafik, farmaceutiske organisationer med behov for simulationer i stor skala og medie organisationer som kan levere video, musik og andet LicensmodelEC2 understøtter: forbrugsmodel (on demand), udbudsmodel (spot instances), hvor der bydes på den billigste ressource og abonnent model (reserved instans), hvor der betales et fast beløb for en periode, herefter time prisen reduceres for ressourcen. StyringsmyndighedAmazon Web Services Limited Liability Company (LLC) ejet af Amazon.com incorporated. Understøttende standarderEC2 understøtter web services teknologier REST og SOAP til beskrivelse af infrastruktur services. VedligeholdelseUdfører vedligeholdelse af udviklingssoftware, service interfaces og instans software med daglig, månedlig og kvartal frigivelsesplaner. BrugerunderstøttelseLeverer dokumentation af service interfaces og udviklingssoftware samt guides. Desuden gives mulighed for bruger interaktion i form af fora og andre kanaler VærktøjsunderstøttelseLeverer software udviklingsværktøj (SDK) til applikationsudvikling. Leverer SDK til Java, PHP, Ruby,.NET og Python. Understøtter Eclipse IDE og Visual Studio integration. ArkitekturEC2 opfylder delvis autonomic computing krav. I forhold til krav Relationer KO.3-7 og System KS.1-5 gives der ikke mulighed for service discovery for understøttelse af konfiguration af service sammensætning. KvalitetsattributterUdføres på udvalgte kandidat i eksperiment.

19 Hoved konklusioner - Foranalyse Kandidater KriterierEvaluering Joyent PlatformJoyent er IaaS og understøtter forskellige operativ systemer med mulighed for konfiguration af forskellige runtime miljøer hovedsagelig baseret på GNU applikationer. Joyent benytter eget operativ system, SmartOS, som også anvendes til virtualisering af andre operativ system herunder Windows og Linux. AnvendelsesdomæneMiljøer, hvor applikationer hurtigt skal skalerer vertikalt eller horisontalt for at behandle uventede trafik krav. LicensmodelUnderstøtter en forbrugsmodel. StyringsmyndighedJoyent incorporated Understøttende standarderJoyent tilbyder ikke udviklingssoftware og har ingen infrastruktur services, som instanser kan tilgå. VedligeholdelseIngen software til vedligeholdelse BrugerunderstøttelseLeverer ikke udviklingssoftware eller yderligere services VærktøjsunderstøttelseLeverer ikke udviklingssoftware eller yderligere services ArkitekturJoyent opfylder delvis autonomic computing krav. I forhold til krav Element KO.1, KO.2 og Relationer KO. 3-7 og System KS.1-5 gives der ikke mulighed for service discovery for understøttelse af konfiguration af service sammensætning. I forhold krav Politikker KO.8-18 er det ikke muligt vha. politikker at bestemme, hvordan systemet skal opfører sig i givne situationer f.eks. under CPU belastning. I forhold krav Interfaces krav KI.1-17 er der ikke mulighed for at forespørge tilstanden eller lifecycle model af en given service. KvalitetsattributterUdføres på udvalgte kandidat i eksperiment.

20 Hoved konklusioner - Foranalyse Kandidater KriterierEvaluering Google App Engine PlatformApp Engine er PaaS baseret på Java og Python teknologi. AnvendelsesdomæneBeskriver ikke specifikke anvendelses domæner, men App Engine afvikler applikationer efter f.eks. Java Servlet og JavaServer Pages og er derfor målrettet web applikationer. LicensmodelUnderstøtter en forbrugsmodel. Tilbyder kvoter for forbrug, således at det er muligt at sætte en begrænsning på forbrug af ressourcen. StyringsmyndighedGoogle incorporated. Understøttende standarderApp Engine anvender Java og Python til runtime miljø og applikationsudvikling. VedligeholdelseUdfører vedligeholdelse af udviklingssoftware, service interfaces og instans software med daglig, månedlig og kvartal frigivelsesplaner. BrugerunderstøttelseLeverer dokumentation af service interfaces og udviklingssoftware samt guides. Desuden gives mulighed for bruger interaktion i form af fora og andre kanaler VærktøjsunderstøttelseLeverer software udviklingsværktøj (SDK) til applikationsudvikling. understøtter Eclipse IDE integration. ArkitekturApp Engine opfylder delvis autonomic computing krav. I forhold til krav Element KO.1, KO.2 og Relationer KO. 3-7 og System KS.1-5 gives der ikke mulighed for service discovery for understøttelse af konfiguration af service sammensætning. I forhold krav Politikker KO.8-18 er det ikke muligt vha. politikker at bestemme, hvordan systemet skal opfører sig i givne situationer f.eks. under CPU belastning. I forhold krav Interfaces krav KI.1-17 er der ikke mulighed for at forespørge tilstanden eller lifecycle model af en given service. KvalitetsattributterUdføres på udvalgte kandidat i eksperiment.

21 Hoved konklusioner - Foranalyse Pris sammenligning Pris pr. time i dollars for CPU kerner for teknologierne. Heroku er omregnet til 4 applikations instanser svarende til en CPU kerne. EC2 har en ikke-lineær funktion for pris og ressource element. Dette skyldes, at Amazon tilbyder instans konfiguration med forskellige hukommelse og lager konfigurationer for given antal CPU kerner.

22 Hoved konklusioner - Foranalyse Pris sammenligning Pris pr. time i dollars for instans lagerplads i MB for teknologierne.

23 Hoved konklusioner - Foranalyse Pris sammenligning Pris pr. time i dollars for instans hukommelse i MB for teknologierne.

24 Hoved konklusioner - Foranalyse Pris sammenligning fordeling af placeringer TeknologiCPUHukommelseLager Azure322 EC2111 App Engine2ikke oplyst Heroku4ikke oplyst Joyent555

25 Hoved konklusioner - Foranalyse Der vælges at fortsætte med teknologi kandidat Amazon AWS EC2. Denne har god understøttelse af dokumentation, blandt de bedste for understøttelse af cloud computing og self managed arkitektur krav samt værktøjsunderstøttelse for debug, service interface og udrulning af services. Desuden har den en meget fyldestgørende understøttelse af forskellige web services uden dog et service registry, som muliggør service discovery og service sammensætning. Forbrugsprisen er den laveste af teknologierne, hvilket reducerer omkostninger i udviklingsprocessen. Service findes i datacenter i Europa, således forbindelsen ikke bliver etableres til f.eks. USA med mulighed for forsinkelser på data trafik. Der findes SDK til Java, hvilket giver forfatteren mulighed for at anvende kendskab og erfaring til udvikling af case. EC2 er IaaS, hvilken i forhold til PaaS, betyder, at runtime miljø skal installeres og konfigureres i de virtuelle instanser.

26 Hoved konklusioner - eksperiment Mapning af AWS til autonomic self managed arkitektur elementer – Manager – Managed element

27 Eksperiment - 1 Detaljeret redegørelse for eksperimentet omkring udvikling af services, usability scenarie 2, afsnit 7.3.2. Arkitektur design problemer/kvalitetskrav - case: skalere ved overbelastning - availability taktik: EC2 detektere instanser i forkert tilstand, Auto scaling opstarter ny instans - Auto scaling starter ny instans ved cpu overbelastning Problemet og løsningen… – Patterns / Styles baseret på skema Kontekst: design kontekst, som hvori design problem opstår Problem: gentaget problem, som opstår i konteksten Løsning: konfiguration som skal balancere problemerne – Struktur med komponenter og relationer – Run-time opførsel Konsekvenser – Single point of failure – Marshalling – kvaliteter: Data integrability: clients are independent Modifiability (decouple sender and receiver) Availability, Scalability (indsætte flere komponenter) location transparency modifiability wrt. re-configurations of network marshalling/unmarshalling – Architectural Tactics A design decision that influences the control of a quality attribute response Surgical means for getting a quality E.g., Heartbeat to control availability Cloud Computing Kvalitetsattributter – Uafhængighed – Høj koherens (samhørighed) – Skalering Arkitektur styles og kvalitetsattributter

28 Eksperiment - 1 Detaljeret redegørelse for eksperimentet omkring udvikling af services, usability scenarie 2, afsnit 7.3.2. Arkitektur styles og kvalitetsattributter – Giver kvalitet(er) – Patterns / Styles baseret på skema Kontekst: design kontekst, som hvori design problem opstår Problem: gentaget problem, som opstår i konteksten Løsning: konfiguration som skal balancere problemerne – Struktur med komponenter og relationer – Run-time opførsel konsekvenser Definition [196]: en arkitektur style er en beskrivelse af komponent typer og et pattern for deres runtime kontrol og data overførsel. En arkitektur style definerer desuden begrænsninger for komponent typer og interaktions pattern. Arkitektur styles beskriver også arkitekturer med specifikke kvaliteter, således at kvalitetskrav til en arkitektur opfyldes, hvis en given arkitektur style anvendes. En arkitektur style eller pattern beskrives ligesom med design patterns med et navn, en kontekst, et gentaget problem som optræder i konteksten og en løsning.

29 Eksperiment - 2 Arkitektur styles – (Klient – Server) RMI – (Web services arkitektur - Restfull) Adressering af unikke ressourcer Selvbeskrivende service interfaces AWS – Broker (observer-listener pattern) – Blacboard (queue)

30 Eksperiment - bb Arkitektur styles – Blacboard (queue) – Data struktur Message type: angiver komponent navnet på afsenderen af beskeden Message: angiver en besked fra afsenderen f.eks. at den er opstartet Value: angiver værdier fra sensorer MachineName: netværksnavnet for den virtuelle maskine MachineAddress: netværksadressen eller IP adressen for den virtuelle maskine Timestamp: angiver tidspunktet beskeden var afsendt Message { "Type" : "", "Message" : "", "Value" : "", "MachineName" : "", "MachineAddress" : "”, "Timestamp" : "" }

31 Eksperiment - 3..

32 Eksperiment - 4

33 Konklusion - Eksperiment Scenarierne målt på de definerede tidsmetrikker fejlede. Dette skyldes problemer i platformen, som skulle undersøges hvilket resulterede i, at aktiviteterne i scenarierne blev afbrudt. Problemerne blev identificeret til at være klassificeret til at være en del af leveret udviklingssoftware og selve platformen. Det første problem relateret til platformen og udviklingssoftware var konfiguration af adgangssystemet for de enkelte køer i platformen kø service. Dette skyldes en fortolknings fejl af den definerede adgangspolitik, som ikke understøttede deklareringen af en sammenlignings statement. Den efterfølgende fundne fejl var af en mere alvorlig karakter. Tidligt i det første scenarie rapporterede EC2 servicen fejl, når der blev for søgt at starte EC2 instanser i USA og APAC regionen. Da problemet blev undersøgt blev der fundet lignende problemer på AWS status site. Selvom problemet blev rapporteret til Amazon med en detaljeret beskrivelse, blev status overblikket ikke opdateret for tidspunktet, hvor problemet blev observeret. Da der blev undersøgt nærmere på fora om der fandtes lignende problemer, blev en løsning beskrevet, hvor en Auto Scaling group defineres til at starte EC2 instanser i flere regioners availability zones for dermed at sikre tilgængeligheden af ressourcerne. Denne taktik blev også anvendt under testen, em begge availability zones defineret for Auto Scaling gruppen fejlede. Det andet platform service orienteret problem, blev fundet i det sidste scenarie, da systemet var endelig designet og realiseret. Det lykkedes ikke, at aktiveret en CloudWatch alarm for metrikken CPU utilization, således skalering af flere EC2 instanser kunne demonstreres, når system bliver belastet. Modsat kunne CloudWatch alarmen for lav CPU belastning aktiveres og dette blev registreret i CP09 systemet Monitor GUI hændelse log. Subjektiv giver det umiddelbart indtryk af en umoden platform. Men der er også mange teknologi muligheder i platformen. For eksempel understøttes virtuelle maskiner med mange forskellige konfigurationer. Komponenter eksisterer i platformen for at varetage elementer i den self managed autonomic computing arkitektur. Manager delen er delt mellem CloudWatch, Auto Scaling og EC2 service. CloudWatch har til ansvar at monitorere det managed element, EC2 service skal administrerer ressourcer og Auto Scaling skal udfører politikker. Det kunne være interessant med mulighed for definition af egne metrikker i CloudWatch, som der kan defineres politikker ud fra. Platformen anvender forskellige availability taktikker. For eksempel er platformen opdelt i zoner i regionen, hvor servicen findes. AWS har flere datacentrer i Europa, USA og Asien og brugeren har mulighed for at vælge, hvordan systemet skal udrulles for at opnå den bedst mulige tilgængelighed. Det kræver specifikke kvalitetskrav for en arkitektur anvendt til en cloud service, hvis denne skal udnyttes. For at systemet kan skalere skal der være lav kobling mellem services og de må gerne være uafhængige, hvis muligt. Dermed kan services, som afvikles på platformen, startes og stoppes uden af brugeren bemærker dette. Men der findes mange arkitekturer patterns, som har denne kvalitet, f.eks. Blackboard pattern anvendt i casen.

34 Konklusion Problemstilling: – Hvilke cloud computing teknologier understøtter helt eller dele af teorien? – Hvordan er modenheden af de aktuelle cloud computing teknologier? Metoden og den tilhørende proces for projektet og rapporten har været formaliseret for hver enkelt aktivitet, der skulle udføres for at opnå resultatet og løse problemstillingen defineret. Dette har sikret en objektiv analyse af de 5 udvalgte teknologi kandidater og en balanceret sammenligning, da kandidaten til eksperimentet skulle findes. Dette er det andet rapport produkt baseret på denne metode og konklusion er lignende observationer fra tidligere rapport[12]. Processen kræver, at man afsætter tid til at studere den givne teknologi ellers kan man ikke svare på spørgsmålene, som metoden stiller, f.eks. anvendte prismodeller, teknologi sammensætning, dokumentation og lignende. Den ikke praksis orienteret del af processen bliver valideret i det efterfølgende eksperiment og her skal teknologien bevise, at funktionelle krav og kvalitets krav opfyldes. Resultaterne fundet i den teoretisk og praktiske del viser, at metoden kan anvendes til at synliggøre eventuelle svagheder i teknologien og informere en beslutning om teknologien skal vælges til f.eks. systemudvikling. Metoden og teknologien har givet mulighed for at arbejde med arkitektur design processen. Det viste sig, at den oprindelige broker baseret arkitektur ikke kunne anvendes direkte i platformen uden at foretage yderligere udvikling eller konfiguration. Observationen med dette arbejde er, at problemerne en arkitektur skal løse skal beskrives eksplicit, således den bedste style kan findes. Når en passende style er fundet kan de i omfang mindre design patterns anvendes til at løse problemer objekter eller klasser i mellem. Teknologi kandidaten blev evalueret i det tidligere afsnit ud fra de teoretiske og eksperiment praktiske perspektiver. Indtrykket, som observationer også understøtter, er teknologien findes umoden med hensyn til tilgængelighed og udvikling understøttelse. Amazon giver dog mulighed for vha. detaljeret dokumentation, hyppige opdateringer af software, at finde løsninger på problemer. Platformen har potentiale i et autonomic computing perspektiv. Det kunne også være interessant at kombinere flere cloud teknologier (intercloud) for at dække svagheder mellem teknologierne. For eksempel, så har AWS ikke en service registry eller service til at hjælpe med komponeringen af services. Dette har Azure og man kan dermed kombinere dem. Teknologierne er desuden ikke gamle, den første frigivelse af AWS software fandt sted i 2006 for services og marts 2010 for Java SDK i version 1.0. Prisanalysen viser, at priserne for ressourcerne er meget tæt for cloud udbyderne der tilbyder lignede services f.eks. AWS og Azure. En sidste observation til rapporten er at der ikke findes en definition for begrebet Cloud computing, men flere. Dette giver det indtryk, at da brutto kandidat listen af teknologi produkt blev gennemgået producenter markedsfører produkter under begrebet uden at opfylde kravene til denne. Det er især et indtryk for traditionel hosting provider af server ressourcer, at disse kan benævne produktet ”cloud” uden at have egenskaber som f.eks. auto scaling og en forbrugsafregnet prismodel.

35 Referencer Software Architecture in Practice 2nd Ed, Bass, Clements, and Kazman, Addison-Wesley, 2003 Pattern-oriented software architecture – A system of patterns, Volume 1, Buschmann et al., John Wiley and Sons Ltd., 2001 Hovedopgave, Master i Informationsteknologi linien i Softwarekonstruktion, Evaluering af Udbud og Modenhed af Cloud Computing Software Teknologier, Thomas Mollerup Lanng, 2011, https://master-evu-au- 2010.googlecode.com/svn/trunk/docs/R04.pdf