Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie En guide igjennom tåkeheimen
Ähnlich wie En guide igjennom tåkeheimen (20)
En guide igjennom tåkeheimen
- 1. Morten Udnæs - Seniorkonsulent En guide gjennom tåkeheimen
- 2. What's in it for me?
- 22. OOPSLA 2009 Workshops "Best practices in Cloud Computing: Designing for the Cloud" Arne Jørgen Berre (SINTEF) "Best Practices in Cloud Computing: Implementation and Operational Implications for the Cloud" Lars Arne Skår (Miles), Morten Udnæs (Miles), Ruth Lennon (University of Letterkenny, Irland) .
- 23. Spørsmål? Takk for oppmerksomheten! [email_address]
Hinweis der Redaktion
- Jobber for Miles. Vi jobber mye med store virksomheten som arkitekter, testledere og prosjektledelse. Vi har ikke typiske body-shopping ressurser Jeg begynte å programmere Turbo Pascal på slutten av 80 tallet har jobbet som arkitekt med teknologier Cobol/stormaskin, case-verktøy, klient-tjener, .NET og Java Systemarkitekt på BBSi STAY-programmet på BBS. Var /Johannes/Systemarkitekt Noe over gjennomsnittelig interesse for virtualisering og hardware. Bygget et eget grid basert på XEN I fjor, men oppdaget at Amazon EC2 var bedre til alt.
- Alle skal tjene penger på Cloud. Hvorfor er det et problem. Fordi Hype=Forvetning Dette er ikke først gangen: Noen som husker klient-tjener, OO, Komponenter, EJB, ESB, SOA, BMP Hvem er det som må levere forventningene? DU!
- Nivået sier noe om ditt ansvar (og cloud leverandøren sitt ansvar)
- Svært spennende å se hva Oralce/Sun og Microsoft gjør Software leverandører har endelig mulighet til å tjene penger på hardware Eucalyptus kan brukes til et privat Cloud (Bilde av mitt Cloud + amazon)
- Kode på lager gir ingen verdi.
- 2 egenskaper: arkitekturkrav og hvordan drift miljø (for test og produksjon) påvirker utvikling/produktivitet. Konsolidering medfører økt grad av spesialisering fordi man har et potensial for ødelegge for andre. Ved å separere kan man i større grad la folk gjøre ting selv. Enkle ting bør kunne utføres av utviklingsressurser. gjøre det innefor en akseptabel tidsramme. Konsolidering og ensarting krever ofte økt grad av spesialisering for å kunne gjennomføres med ok resultat. Stiller storekrav til agilitet i organisasjon (noe som er svært vanskelig ved høy spesialisering). Så gjør man følgende sammenligning: Produkteier sår frøet, utvikler får salaten til å vokse og test sjekker tilstanden før automatisk pakking og deploy. Men hva var det som egentlig skjedde: Før alle er ferdig = 0 verdi. Alle må ha tid til gjøre det på riktig tidspunkt, hvis ikke venter du Agil utvikling er meningsløst hvis man må ha 15 for å få verdi. Ny funksjonalitet på en eksisterende virksomhetskritisk applikasjon med eksisterende infrastruktur Spesifisering av kravet: 2 Utviklere, funksjonell tester, arkitekt og produkteier Design: Infrastrukturarkitekt, sikkerhetsansvarlig, driftressurs (script/server) og driftskoordinator Utvikling og test Webutvikler, funksjonell utvikler Databaseadministrator Testleder og tester Produksjonsmiljø: Teknisk koordinator (ressurser som styrer felles ressurser må skjermes for adhoc oppdrag) Webserver ressurs - Oppdatering av felles Webserver config (delte ressurser krever kontroll) - Sikkerhetsressurs - Oppdatering roller og tilganger + sertifikat - Nettverksressurs Åpning av porter - Applikasjonsserver administrator Konfigurasjon av applikasjon I applikasjonsserver - OS ressurs Unix (brukere og rettigheter) - Deploy ressurs Produksjonssetting av ny versjon applikasjon - Databaseadministrator Oppdatering av produksjonsdatabase (nye felter) - Driftovervåkning ressurs Innmelding av ny overvåkning - Skedulering av batchjobber Innmelding av ny tidsbasert batch jobb. (Fordi man ofte ønsker stor grad av likhet mellom test og produksjon får man samme behovet i test.) Sammenligning strøm: - Trenger ikke elektroutdannelse for å plugge i en stikkkontakt. - Trenger elektroutdannelse for å legge inn strøm i nytt hus. - Alle har ikke elektro grunnkurs.
- Rekk opp hånden de som har hørt om Complexity Bears?! En complexity bear, spiser 1% av tiden din og du Blir sliten av å sloss med dem Uansett hvor flink teamet ditt kan ikke takle flere enn er. Hvis du velger en applikasjonsserver Eller rammeverks om gjør at teamet gir 30 comlexiy bears til. Et litt avansert opplegg for automatisk testing kan gi ytterligere 30 bjørn Nå har du 10% igjen til å skape forretningsverdi Når man slåss med kompleksitet i stedet for levere verdi har man et problem De spiser både og folk fordi man sliten av å sloss med kompleksistet
- Når du blander disse 4 Har du en betydelig utfordring I forhold til å levere på tid, Kost, kvalitet
- Spørsmålet er jo da om Cloud hjelper deg med dette
- Henger sammen med salatplukking, men selv med få salat plukkere er det ikke sikker man kan være skikkelig agil. Cloud på standard infrastruktur: Den ingen som spør 6-12 måneder før de går i produksjon med hvor mange servere skal du ha, hva skal du kjøre på de. Hvor mye ressurser du trenger fra infrastruktur avd. Hvis du svarer vil jeg gjerne bestemme meg for 14 dager før produksjonssetting rister de på hode… De må være slik: Kapasitetsplanlegging og folk.
- Hadde strøm vært håndtert på samme måte som IT hadde vi hatt en elektrikker boende på hybel alle mann. Cloud computing gjør at elektrikkeren kan flytte, og da er det kanskje på tide for oss andre flytt nærmere de betaler for gildet.
- Cloud er som annen arkitektur. Det er ikke godt eller dårlig, sort eller hvit. Det kommer ann på hva man bruker det til og hvordan Cloud blir ett av fokusområdene på OOPSLA i år.