Præsentation af hovedopgave og resultater

Præsentationer af emnet: "Præsentation af hovedopgave og resultater"— 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 Dato:

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 id Beskrivelse 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.5 Leverage VM technology to dynamically assign resource shares according to service requirements. QoS QoS 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 til 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-healing Systemet detekterer automatisk, diagnosticerer og reparerer lokaliserede software og hardware problemer. Self-optimizing Komponenter og systemer søger kontinuerligt at forbedre deres ydelse og effektivitet. Self-protecting Systemet forsvarer sig automatisk mod ondsindede angreb eller flere på følgende fejl. Det benytter tidlig advarsel og forhindrer fejl på system niveau.

7 . Hovedkategori Underkategori Krav Id Krav beskrivelse Opførsel
Element KO.1 Skal 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.2 Skal 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 ) Relationer KO.3 Etablere og vedligeholde relationer med andre autonome elementer herunder hvilke services udbydes til og services som benyttes KO.4 Service skal beskrives korrekt og være tilgængelig og forståelig for andre autonome elementer KO.5 Skal forstå og opfylde aftale krav KO.6 Skal kunne forhandle for at etablere aftaler (relationer) KO.7 Skal 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.8 2 typer forpligtigelse(obligations): - opfylde aftaler(agreements) og - modtage og opfylde politikker(policies) KO.9 Skal forkaste service forespørgsler som bryder politikker eller aftaler KO.10 Skal nægte eller give andre forslag til foreslåede relationer eller politikker som vil bryde eksisterende relationer eller politikker KO.11 Administrative relationer håndteres lige som andre relationer KO.12 Direktiver 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.13 Konfliktende forespørgsler fra administrative elementer skal løses af det modtagne element KO.14 Skal kunne oversætte højniveau, globale direktiver til specifikke aktiviteter vha. politikker KO.15 En politik er en repræsentation i en standard ekstern form for ønskede opførsel eller begrænsninger på opførsel KO.16 Der 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.17 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 KO.18 Et element, der benytter Utility function politikker, skal have tilstrækkelig modellering og optimeringsegenskaber for at oversætte mål til actions Interface KI.1 Udover 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.2 Dette gør det muligt for at et element at blive monitoreret af et andet element med de nødvendige rettigheder KI.3 Kan anvendes til at styre mængden af logning og trace data, som et element indsamler og få tilgang til dette data KI.4 Kan anvendes til at instruere et element til at udføre en self-test og tilgå resultater Lifecycle interfaces KI.5 Muliggø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.6 Muliggør ændring af lifecycle tilstand for et element f.eks. nedlukning Politik interface KI.7 Muliggør for administrative elementer at sende nye politikker til et element og politikker som anvendes at elementet Negotiation og binding interfaces KI.8 Tillader et element at forespørge en service fra et andet element eller at blive forespurgt at levere en service KI.9 I 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.10 I 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.11 Opstår når et element har tilladt at levere en service til et andet element typisk ved forhandling mellem elementerne KI.12 En forhandling kan fejle som følge af manglende rettigheder eller elementet ikke har tilstrækkelige ressourcer KI.13 Relationer er måden hvorpå elementer sammensættes til at danne et autonomt system KI.14 Relationer dannes typisk runtime (modsat fastholdt ved udrulning) og kan ændres på et givent tidspunkt KI.15 Relationer dannes af elementerne selv og ikke af administratorer Inteaction integrity KI.16 Et 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.17 Et elements interne kommunikation må ikke blive tilgængelig udenfor elementet System sammensætning Interaktion KS.1 For 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. Discovery KS.2 Autonome elementer skal kunne finde/søge andre elementer KS.3 Autonome elementer skal kunne identificere andre elementer for kommunikation Komposition KS.4 Autonome elementer skal via andre elementer kunne opnå end-to-end service level mål Støtte elementer KS.5 For 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 Foranalyse Eksperiment Notationen Firkant: Aktivitet Trekant: Beslutning Firkant med afrundede hjørner: Artefakt

12 Metode Taksonomi og evaluerings kriterier

13 Hovedkonklusioner

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

15 Hovedkonklusioner - 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 Hovedkonklusioner - Foranalyse
Kandidater Kriterier Evaluering Microsoft Azure Platform Azure 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æne En 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 Licensmodel Azure understøtter: forbrugsmodel og abonnent model, hvor der betales et fast beløb for en periode, herefter time prisen reduceres for ressourcen. Styringsmyndighed Microsoft corporation. Understøttende standarder Azure understøtter .NET teknologi, web services teknologi REST for infrastruktur services og egne teknologier til f.eks. databaser vha. TDS. Vedligeholdelse Udfører vedligeholdelse af udviklingssoftware, service interfaces og instans software med daglig, månedlig og kvartal frigivelsesplaner. Brugerunderstøttelse Leverer dokumentation af service interfaces og udviklingssoftware samt guides. Desuden gives mulighed for bruger interaktion i form af fora og andre kanaler Værktøjsunderstøttelse Leverer software udviklingsværktøj (SDK) til applikationsudvikling. Leverer udover .NET også til Ruby, Java og PHP. Understøtter Eclipse IDE integration. Arkitektur Azure 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. Kvalitetsattributter Udføres på udvalgte kandidat i eksperiment

17 Hovedkonklusioner - Foranalyse
Kandidater Kriterier Evaluering Heroku Platform Heroku er PaaS baseret på Ruby teknologi. Anvendelsesdomæne Målretter platformen til udvikling af web applikationer Licensmodel Understøtter en forbrugsmodel. Styringsmyndighed Heroku incorporated fra den 31. januar 2011 en underafdeling af Salesforce.com incorporated. Understøttende standarder Heroku anvender Ruby til runtime miljø og applikationsudvikling. Derudover anvendes REST til applikations management service. Vedligeholdelse Udfører vedligeholdelse af udviklingssoftware, service interfaces og instans software med daglig, månedlig og kvartal frigivelsesplaner. Brugerunderstøttelse Leverer dokumentation af service interfaces og udviklingssoftware samt guides. Desuden gives mulighed for bruger interaktion i form af fora og andre kanaler Værktøjsunderstøttelse Leverer software udviklingsværktøj (SDK) til applikationsudvikling Arkitektur Heroku 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. Kvalitetsattributter Udføres på udvalgte kandidat i eksperiment.

18 Hovedkonklusioner - Foranalyse
Kandidater Kriterier Amazon Web Services (AWS), EC2 Platform EC2 er IaaS og understøtter virtuelle maskiner baseret på forskellige operativ systemer med mulighed for konfiguration af forskellige runtime miljøer og applikationer. Anvendelsesdomæne En 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 Licensmodel EC2 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. Styringsmyndighed Amazon Web Services Limited Liability Company (LLC) ejet af Amazon.com incorporated. Understøttende standarder EC2 understøtter web services teknologier REST og SOAP til beskrivelse af infrastruktur services. Vedligeholdelse Udfører vedligeholdelse af udviklingssoftware, service interfaces og instans software med daglig, månedlig og kvartal frigivelsesplaner. Brugerunderstøttelse Leverer dokumentation af service interfaces og udviklingssoftware samt guides. Desuden gives mulighed for bruger interaktion i form af fora og andre kanaler Værktøjsunderstøttelse Leverer software udviklingsværktøj (SDK) til applikationsudvikling. Leverer SDK til Java, PHP, Ruby, .NET og Python. Understøtter Eclipse IDE og Visual Studio integration. Arkitektur EC2 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. Kvalitetsattributter Udføres på udvalgte kandidat i eksperiment.

19 Hovedkonklusioner - Foranalyse
Kandidater Kriterier Evaluering Joyent Platform Joyent 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æne Miljøer, hvor applikationer hurtigt skal skalerer vertikalt eller horisontalt for at behandle uventede trafik krav. Licensmodel Understøtter en forbrugsmodel. Styringsmyndighed Joyent incorporated Understøttende standarder Joyent tilbyder ikke udviklingssoftware og har ingen infrastruktur services, som instanser kan tilgå. Vedligeholdelse Ingen software til vedligeholdelse Brugerunderstøttelse Leverer ikke udviklingssoftware eller yderligere services Værktøjsunderstøttelse Arkitektur Joyent 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. Kvalitetsattributter Udføres på udvalgte kandidat i eksperiment.

20 Hovedkonklusioner - Foranalyse
Kandidater Kriterier Evaluering Google App Engine Platform App Engine er PaaS baseret på Java og Python teknologi. Anvendelsesdomæne Beskriver 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. Licensmodel Understøtter en forbrugsmodel. Tilbyder kvoter for forbrug, således at det er muligt at sætte en begrænsning på forbrug af ressourcen. Styringsmyndighed Google incorporated. Understøttende standarder App Engine anvender Java og Python til runtime miljø og applikationsudvikling. Vedligeholdelse Udfører vedligeholdelse af udviklingssoftware, service interfaces og instans software med daglig, månedlig og kvartal frigivelsesplaner. Brugerunderstøttelse Leverer dokumentation af service interfaces og udviklingssoftware samt guides. Desuden gives mulighed for bruger interaktion i form af fora og andre kanaler Værktøjsunderstøttelse Leverer software udviklingsværktøj (SDK) til applikationsudvikling. understøtter Eclipse IDE integration. Arkitektur App 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. Kvalitetsattributter Udføres på udvalgte kandidat i eksperiment.

21 Hovedkonklusioner - Foranalyse
Pris sammenligning Pris pr. time i dollars for CPU kerner for teknologierne. Heroku er omregnet til 4 applikations instanser (dynos) 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 Hovedkonklusioner - Foranalyse
Pris sammenligning Pris pr. time i dollars for instans lagerplads i MB for teknologierne.

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

24 Hovedkonklusioner - Foranalyse
Pris sammenligning fordeling af placeringer Teknologi CPU Hukommelse Lager Azure 3 2 EC2 1 App Engine ikke oplyst Heroku 4 Joyent 5

25 Hovedkonklusioner - 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 Hovedkonklusioner - Eksperiment
Scenarierne målt på de definerede tids metrikker 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. Single point of failure muligheder ved placering af funktionalitet på centrale komponenter / services 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. EC2 monitorerer instanser og starter ny instans, hvis en forkert tilstand detekteres 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.

27 Hovedkonklusioner - Konklusion
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.

28 Redegørelse for usability scenarie 2: ”Udvikling af services”
Eksperiment Redegørelse for usability scenarie 2: ”Udvikling af services”

29 Eksperiment Aspekterne self-healing og self-configuration Usability scenarier driver eksperimentet og realiserer CP09 casen Casen afgrænser CP09 systemet til komponenterne: Kontrol Monitor Sensor par (temperatur og tryk) Aktuator Kontrol komponent indlæser periodisk sensor værdier Monitor komponent visualisere sensor værdier Ved temperatur værdier over 30 grader celsius sendes en besked til varmelegeme aktuator om at reducere temperaturen. Tryk behandles ikke i casen ud over en visuel repræsentation vha. Monitor komponenten. Systemet har angivet vha. en politik, at hvis en komponent i systemet belastes med mere end 80 % af CPU kapaciteten, så skal der startes en ny virtuel maskine instans for den givne komponent type. Disse aspekter af self management skal den valgte kandidat evalueres ud fra.

30 Eksperiment Usability scenarie 2 – Udvikling af første services
Systemets komponenter udvikles givet casens afgrænsning Proces steps Valg af arkitektur style Beskrivelse af komponenter Implementering Test Kilde Forfatteren af rapport og udvikleren af case Stimulus Lære at lave services, der kommunikerer med hinanden. Artefakt(er) Kodegenerering, command line interface, associeringsfunktionalitet Miljø Linux / Windows platform, med udviklingsmiljø konfigureret. Respons Understøttelse for udvikling af interservice kommunikation. Måling Opgaven skal udføres på under 7 timer

31 Eksperiment Valg af arkitektur style / pattern [Buschmann]
Definition [Bass]: 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.

32 Eksperiment Valg af arkitektur style / pattern [Buschmann] Problem
Definition [Bass]: en arkitektur style er en beskrivelse af komponent typer og et pattern for deres runtime kontrol og data overførsel. Valg af arkitektur style / pattern [Buschmann] Problem Placerings transparens: Control skal kunne tilgå sensor værdier uden at kende netværks adresse Komponenter skal være uafhængige af hinanden og må derfor ikke kommunikere direkte med hinanden. Modifiability: det skal være muligt at indsætte flere sensorer eller andre komponenter uden at foretage konfiguration Løsning Kandidater Blackboard Funktionalitet for denne findes i platformen i form a Simple Queue Service Broker Der findes ikke Broker / Service registry funktionalitet i AWS platformen, derfor skal denne udvikles eller installeres i platformen Konsekvenser Blackboard vælges, hvilket betyder, at der skal ændres på hvorledes komponenterne kommunikerer I modsætning til Broker er der ikke funktionalitet til marshalling / unmarshalling af beskeder Kontrol kan ikke kommunikere med sensorer, som om de er lokale objekter Begge kandidater er single point of failure (Broker/Control) muligheder med mindre availability taktikker anvendes Der skal udvikles en Queue test stub i stedet for en f.eks. et Java RMI registry Manglende mulighed for anvendelse af observer pattern for sensorer, som Kontrol og Monitor kan abonnere på

33 Eksperiment Beskrivelse af komponenter Ændring af ansvar Komponent
Monitor Der oprettes en Monitor kø, hvortil Control knude kan sende sensorværdier læst fra sensor kø og SNS service kan sende alarmer fra CloudWatch. Hertil sendes også hændelser foretaget af Actuator f.eks. ved åbning af ventil. Desuden sendes deployment beskeder, når komponenter starter i instanser. Monitor knude skal slette beskeder læst fra denne kø. Control Der oprettes en Control kø, hvortil Sensor par knude skriver sensorværdier for temperatur og tryk. Control knude skal slette beskeder læst fra denne kø. Sender deployment besked til Monitor, når komponenter startet instansen Actuator Der oprettes en Actuator kø, hvortil Control sender kommandoer for styring af temperatur, tryk og produktion. Actuator knude skal slette beskeder læst fra denne kø. Sensor Sensor par sender beskeder til Control indeholdende aflæste beskeder.

34 Eksperiment Beskrivelse af komponenter Besked data struktur, JSON
Message { "Type" : "", "Message" : "", "Value" : "", "MachineName" : "", "MachineAddress" : "”, "Timestamp" : "" } Beskrivelse af komponenter Besked data struktur, JSON 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

35 Eksperiment Component & Connector view

36 Eksperiment Component & Connector view

37 Eksperiment Module view

38 Eksperiment Module view Beskrivelse af pakker Pakke Beskrivelse
cp09.monitorgui Denne pakke indeholder realiseringen af GUI delen for Monitor og Controller og View delen af MVC pattern cp09.monitor Denne pakke indeholder realiseringen af Monitor model delen af MVC pattern. cp09.sensor Denne pakker indeholder realiseringen af temperatur og tryk sensorer med simulerede sensor værdier. cp09.actuator Denne pakke indeholder realiseringen af Actuator. cp09.control Denne pakke indeholder realiseringen af Control. cp09.logging Denne pakke indeholder realiseringen af logging funktionalitet til konsol og fil log. cp09.instance Denne pakke indeholder realiseringen af funktionalitet til kommunikation med EC2 service og Auto Scaling service. cp09.queue Denne pakke indeholder realiseringen af funktionalitet til kommunikation med Simple Queue service. cp09.message Denne pakke indeholder realiseringen af CP09 JSON baseret beskeds system.

39 Eksperiment Module view

40 Eksperiment Module view

41 Eksperiment Deployment view

42 Eksperiment System test – lokal deployment

43 Eksperiment System test – lokal deployment

44 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, Market-Oriented Cloud Computing: Vision, Hype, and Reality for Delivering IT Services as Computing Utilities, Buyya et. al., Proceedings of the th IEEE International Conference on High Performance Computing and Communications, 2008 An Architectural Approach to Autonomic Computing, IBM Research, White et. al., 2004

45

46

47