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

12. Metode • Taksonomi og evaluerings kriterier

13. Hovedkonklusioner

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

15. Hoved konklusioner - 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. Hoved konklusioner - foranalyse

17. Hoved konklusioner - foranalyse

18. Hoved konklusioner - foranalyse

19. Hoved konklusioner - foranalyse

20. Hoved konklusioner - foranalyse

21. Hoved konklusioner - foranalyse Foranalyse • Microsoft Azure

22. Hoved konklusioner - foranalyse Foranalyse • Microsoft Azure

23. Hoved konklusioner - foranalyse Foranalyse • Amazon EC2 (Amazon Web Services – AWS)

24. Hoved konklusioner - foranalyse Foranalyse • GoogleAppEngine

25. Hoved konklusioner - foranalyse Foranalyse • Heroku

26. Hoved konklusioner - foranalyse Foranalyse • Joyent

27. Hoved konklusioner - eksperiment • Mapning af AWS til autonomicselfmanaged arkitektur elementer • Manager • Managed element

28. 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: clientsare independent • Modifiability (decouple sender and receiver) • Availability, • Scalability (indsætte flere komponenter) • location transparency • modifiabilitywrt. re-configurations of network • marshalling/unmarshalling • ArchitecturalTactics • A design decision that influences the control of a quality attribute response • Surgical means for getting a quality • E.g., Heartbeat to control availability • CloudComputing • Kvalitetsattributter • Uafhængighed • Høj koherens (samhørighed) • Skalering • Arkitektur styles og kvalitetsattributter

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

30. Eksperiment - 2 • Arkitektur styles • (Klient – Server) RMI • (Web services arkitektur - Restfull) • Adressering af unikke ressourcer • Selvbeskrivende service interfaces • AWS • Broker (observer-listenerpattern) • Blacboard (queue)

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

32. Eksperiment - 3 • ..

33. Eksperiment - 4

34. Konklusion

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 CloudComputing Software Teknologier, Thomas Mollerup Lanng, 2011, https://master-evu-au-2010.googlecode.com/svn/trunk/docs/R04.pdf