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:

Disposition Præsentation af hoved ideerne i din hovedopgave: – motivation, – problemstillinger – Samt hovedkonklusioner. Detaljeret redegørelse for eksperimentet omkring udvikling af services, usability scenarie 2, afsnit Konklusion

Motivation Cloud computing : Aktuelt emne og spændende emne til løsning af autonomic computing problemstilling. 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ø.

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?

Metode Faseopdelt Aktiviteter

Metode Taksonomi

Hoved konklusioner Foranalyse Eksperiment Samlet evaluering

Hoved konklusioner - foranalyse Foranalyse Stor brutto kandidatliste for cloud computing teknologier 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

Hoved konklusioner - foranalyse Foranalyse 5 kandidater udvalgt – Microsoft Azure – Amazon EC2 (Amazon Web Services – AWS) – Google App Engine – Heroku – Joyent

Hoved konklusioner - foranalyse Foranalyse – Microsoft Azure

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

Hoved konklusioner - foranalyse Foranalyse – Google App Engine

Hoved konklusioner - foranalyse Foranalyse – Heroku

Hoved konklusioner - foranalyse Foranalyse – Joyent

Hoved konklusioner - eksperiment

Eksperiment - 1 Detaljeret redegørelse for eksperimentet omkring udvikling af services, usability scenarie 2, afsnit 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 – 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

Eksperiment - 1 Detaljeret redegørelse for eksperimentet omkring udvikling af services, usability scenarie 2, afsnit 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.

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)

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" : "" }

Eksperiment - 3..

Eksperiment - 4

Konklusion

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, googlecode.com/svn/trunk/docs/R04.pdf