Evaluering af Udbud og Modenhed af Cloud Computing Software Teknologier

1. Evaluering af Udbud og Modenhed af CloudComputing 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 • Cloudcomputing : Aktuelt emne og spændende emne, hvordan kan dette emne sættes i en problem kontekst Vs. • Definition af Cloudcomputing [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 Autonomiccomputing [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 baseretCloud arkitektur med følgende krav til kommercielle produkter .

6. Motivation • [White et. al] definerer en selfmanagedarkitektur til opfyldelse af autonomiccomputing aspekter • [White et. al] definerer krav til et autonomtelement som indgår i den selfmanagedarkitektur .

7. .

8. Motivation • Cloudcomputing og Autonomiccomputing forekommer at have lignende egenskaber indenfor ressource management baseret på politikker • Definere problemformulering, hvor cloudcomputing teknologier undersøges for understøttelse af autonomiccomputing .

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

10. Problemstilling • Modenheden af de udvalgte cloudcomputing teknologier vurderes ud fra en evalueringstaksonomi med følgende kriterier: • Hvor godt understøttes autonomiccomputing 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: AktivitetTrekant: Beslutning Firkant med afrundede hjørner: Artefakt

12. Metode • Taksonomi og evaluerings kriterier

13. Hovedkonklusioner

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

15. Hovedkonklusioner - Foranalyse • Stor brutto kandidatliste for cloudcomputing 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 cloudcomputing og selfmanaged arkitektur egenskaber • 5 kandidater udvalgt • Microsoft Azure • Heroku • Amazon Web Services (AWS), EC2 • Joyent • GoogleAppEngine

16. Hovedkonklusioner - Foranalyse

17. Hovedkonklusioner - Foranalyse

18. Hovedkonklusioner - Foranalyse

19. Hovedkonklusioner - Foranalyse

20. Hovedkonklusioner - Foranalyse

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

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 cloudcomputing og selfmanaged 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 Scalinggroup 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 selfmanagedautonomiccomputing 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. Blackboardpattern 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 autonomiccomputing 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 Cloudcomputing, 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 hostingprovider af server ressourcer, at disse kan benævne produktet ”cloud” uden at have egenskaber som f.eks. auto scaling og en forbrugsafregnet prismodel.

28. 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

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 Definition [Bass]: en arkitektur style er en beskrivelse af komponent typer og et pattern for deres runtimekontrol 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 deer 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

34. Eksperiment • 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 & Connectorview

36. Eksperiment • Component & Connectorview

37. Eksperiment • Moduleview

38. Eksperiment • Moduleview • Beskrivelse af pakker

39. Eksperiment • Moduleview

40. Eksperiment • Moduleview

41. Eksperiment • Deploymentview

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 CloudComputing Software Teknologier, Thomas Mollerup Lanng, 2011, https://master-evu-au-2010.googlecode.com/svn/trunk/docs/R04.pdf • Market-OrientedCloudComputing: Vision, Hype, and Reality for Delivering IT Services as ComputingUtilities, Buyya et. al., Proceedings of the 2008 10th IEEE International ConferenceonHigh Performance Computing and Communications, 2008 • An Architectural Approach to AutonomicComputing, IBM Research, White et. al., 2004 • Software Architecture in Practice 2nd Ed, Bass, Clements, and Kazman, Addison-Wesley, 2003