![Spørsmål? Takk for oppmerksomheten! [email_address]](https://image.slidesharecdn.com/cloudcomputingiasa-12520643129057-phpapp03/85/En-guide-igjennom-takeheimen-23-320.jpg)
More Related Content
Similar to 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?
- 3. Hvem er det som ikke skal tjene penger på Cloud? Gartner, Computerworld, InfoQ, Morten Udnæs(!), Konsulenter, Media, Rådgivere, Konferanser, Software selgere, Open Source prosjekter
- 9. Bygge forretningskritiske løsninger som holder mål og få satt disse i produksjon (med eller uten Cloud) Kun kjørende software har en verdi for oppdragsgiver Siden kun kjørende software har verdi, bør man ha mulighet til å sette ting ofte i produksjon Er det noe å lære av andre?
- 11. En kort historie om en kompis som leverer verdi til kundene sine: Planter, Skjærer og Pakker En mye lenger historie om hvordan jeg leverer verdi: Utvikler, Systemarkitekt, Testleder, Tester, Webserver-administrator, Sikkerhetsansvarlig, Nettverksansvarlig, Applikasjonsserver administrator, Databaseadministrator, Deploy ansvarlig, Unix administrator, Driftsovervåker, Driftsutvikler og Teknisk ressurs koordinator og Driftskoordinator
- 16. Er ikke Cloud bare ”outsourcing” da.. Kostnadseffektiv/oppgave orientert vs. Smidig/Selvbetjent ” Vanlig” drift og infrastruktur er så kostbart at må gjøres effektiv Standardisering, konsolidering og gjenbruk av infrastruktur har store konsekvenser Mange av de er negative for evnen til å levere verdi til oppdragsgiver Kan man bruke Cloud Computing for å få en selvbetjent infrastruktur, standard arkitektur og gjenbruke tjenester?
- 18. Man tilpasser arkitekturen til kravene, bygger tjenestene og gjenbruker gode open-source rammeverk Eller man tilpasser kravene til ferdig arkitektur/plattform for å “overleve”. Bruk av Software as a Service er eksempel på dette Negativ erfaring med ”Leverandør Orientert System(LOSt) arkitektur? IBM, Microsoft, Oracle .
- 20. Utfordring nr. 1: Skape forretningsmessig verdi av IT-investeringer Trøbbel med samhandling, forankring, prioritering, kost/nytte og avstand Trøbbel med smidighet i forskjellige deler av organisasjon … Utfordring nr. 8: Samhandling mellom IT-ressurser Hvorfor organiser vi ofte IT-ressurser sammen i en IT-avdeling??!
- 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]
Editor's Notes
- #2: 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.
- #4: 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!
- #6: Nivået sier noe om ditt ansvar (og cloud leverandøren sitt ansvar)
- #8: 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)
- #10: Kode på lager gir ingen verdi.
- #12: 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.
- #14: 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
- #15: Når du blander disse 4 Har du en betydelig utfordring I forhold til å levere på tid, Kost, kvalitet
- #16: Spørsmålet er jo da om Cloud hjelper deg med dette
- #17: 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.
- #21: 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.
- #23: 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.