21. Strøm er fantastisk! Naboen påvirkes ikke av ditt strømforbruk Du betaler kun for det du bruker. Stikkontakter og apparater virker i mer enn 3. år uten at de må byttes (og uten supportavtale) Apparater kan hente den strømmen de trenger og sikringen går hvis de tar for mye Apparater kan skrus på og av, og nye kan legges til Grensesnittet er standardisert (220v/2 pinner + jord) El-selskap legger opp strøm til huset og en elektriker legger opp kurser og kontakter
27. Enklere hverdag med EC2? Naboen påvirkes ikke av ditt strømforbruk Du betaler kun for det du bruker. Stikkontakter og apparater virker i mer enn 3. år uten at de må byttes (og uten supportavtale) Apparater kan hente den strømmen de trenger og sikringen går hvis de tar for mye Apparater kan skrus på og av, og nye kan legges til Grensesnittet er standardisert (220 volt og stikkontakt med 2 pinner El-selskap legger opp strøm til huset og en elektriker legger opp kurser og kontakter Du kjører alene på din virtuelle maskin Betaler for det du bruker og en fast support avgift Dynamisk skalering Enkelt grensesnitt for installere ny applikasjoner og starte nye servere Webservices, OS (Linux/ Windows), nettverk og lagring Amazon EC2
I stedet for at dere skal sitte å lure til vi har vært igjennom halve agendaen så sier jeg det med en gang. Så da slipper dere å lure hva jeg mener om saken, og da kan vi se på hva jeg egentlig skal snakke om den neste snaue timen.
Det var en kollega som nevnte ordet tåkeheimen… Med bakgrunn i praktisk erfaring med implementering av forretningskritiske applikasjoner. Beskrive kort begreper som virksomhetskritiske applikasjoner, virtualisering, Grid og Cloud Computing Vise hvordan man setter opp en EC2-konto og begynner å kjøre en javabasert applikasjon med webgrensesnitt. Gi innspill på hva man bør tenke på før man bestemmer seg for å benytte EC2 eller en annen Cloud/Grid løsning
Konsekvenser for forretnings, teknologi og organisasjon skal beskrives nærmere.
Fortelle om hvordan GRID kan benyttes Basert på egen erfaring fra diverse prosjekter. Fra 12mnd til 3,5 år. Blir ikke så lett entusiastisk lenger etter å vært gjennom 4-5 lignende paradigme skifter (SOA var vel den siste…)
Det finnes sikkert andre definisjoner, men for dette foredraget er det et ok utgangspunkt
Da ser vi litt nærmere på hvilke logiske deler en slik applikasjon består av: Brukere må kommunisere med den. Det betyr rike klienter eller browser type grensesnitt Det finnes forretningslogikk, det som faktisk gjør den forretningskritisk. I form av filer, database, webservices eller annen integrasjon går det data inn og ut av applikasjon Data må lagres i en form. Ofte er dette en database. Som regel stilles det krav til bevaringen av disse dataene i korrekt form. Det er ok å miste dem eller at det blir endret/ikke er komplette etc. En slik løsning må overvåkes og driftes. Den kjører på maskiner som ikke skal stoppe, den har integrasjon som må virke. Nye versjoner må kunne rulles ut. Egenskaper:
!!TODO: Endre tegning slik at man får en edderkopp i midten
Dette kan de lese selv. Oppsummer med nøkkel ord. Det er snakk om internett, flere maskiner og man kan få mer eller mindre datakraft ved behov. Det handler mye om infrastruktur for å kjøre applikasjoner
Virtualisering: Man har er ikke lenger direkte koblet i fysiske servere, nettverk eller hardisker/san. Dette er ressurser kan tildeles logisk og dynamisk. Dersom noe av de fysiske går is stykker kan man kjøre videre et annet sted. Grid Computing: Man kan benytte mange servere for applikasjonen sin dersom man lager en skalerbar arkitektur.
Elastic Compute Cloud?!! Virtuelle servere som du får full tilgang (root) til og hvor du kan installere det du trenger
Snakke litt om arkitekturegenskaper: Failover Skalering Backup Database Integrasjon Sikkerhet 15 minutter: Vise hvor på amazon man kan opprette konto! Vise at man kan starte en applikasjon på en fersk instans i løpet av 10 minutter. Sette opp elastifox Hente sikkerhetscredentials Logge på Forklare flipper i Elastifox AMI Sikkerhet Instanser Elastic IP AMI Starte server Vise at man kan installere software / oppgradere Vise logger Vise konsoll Vise deploy Koble opp domene Elastic IP koble opp DNS via Inexpensive (oops. Forklar DNS cache også lokalt på PCen) Endre nginx Vise redploy Deploy Vis endring i JSP. Vise litt hardware Nettverk Disker (fdisk –l, fdisk /dev/sda1, mkfs.ext3 S3? Gå til aws.amazon.com og opprett konto for følgende tjenester: Amazon Web Services (AWS) Amazon Simple Storage Service (S3) Amazon EC2 Demo: Hvordan starte din første virtuelle maskin Sette opp EC2 kontoer for lagring og selve GRIDet Start en server Installer softwaren du trenger (hvis den ikke allerede er der) Koble opp IP-adresse og disker og S3-lagring FERDIG-KOM-OG-TØRK eller nei..KOM OG BRUK var det visst.
Det var en kollega som nevnte ordet tåkeheimen… Med bakgrunn i praktisk erfaring med implementering av forretningskritiske applikasjoner. Beskrive kort begreper som virksomhetskritiske applikasjoner, virtualisering, Grid og Cloud Computing Vise hvordan man setter opp en EC2-konto og begynner å kjøre en javabasert applikasjon med webgrensesnitt. Gi innspill på hva man bør tenke på før man bestemmer seg for å benytte EC2 eller en annen Cloud/Grid løsning
Kode på lager gir ingen verdi. Å overgå driftskrav har ingen verdi (akkurat som ved utvikling, bedre enn kravet gir ingen verdi). En av fordelene med å jobbe Miles er at uansett hvor flink man er og hvor mye man kan må man ha faglig ydmykhet. Når man som arkitekt har blitt kalt både overkikkador og j.vla bøtteknott kan ydmyket være litt vrient, men jeg får altså forsøke.
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.
Kan jeg få det samme uten å ha en elektrikker boende på hybel! Dersom man skal nå målet om få ting ut I produksjon kan man ikke ha en elektrikker boende på hybel.
TODO: Bilde av en Salat. For å dra nytte av fordelene ved Cloud Computing kreves endring på følgende områder: Teknologi Forretning Organisasjon 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: Ny funksjonalitet på en eksisterende virksomhetskritisk applikasjon med eksisterende infrastruktur
Vesentlig utfordring kostnad ved drift: - Driftsressurser/opplæring/kompetanse. - Endringstakt på underliggnede infrasktur matcher ikke applikasjon - End-Of-Life på software - End-Of-Life på hardware - Følge problemer av EOL (testing/endret funksjonalitet).Disse endringene gir sjelden noe forretningsmessig verdi. Virtualiserte ressurser: EOL er leverandørens problem og tatt med i prisingen.
Det var en kollega som nevnte ordet tåkeheimen… Med bakgrunn i praktisk erfaring med implementering av forretningskritiske applikasjoner. Beskrive kort begreper som virksomhetskritiske applikasjoner, virtualisering, Grid og Cloud Computing Vise hvordan man setter opp en EC2-konto og begynner å kjøre en javabasert applikasjon med webgrensesnitt. Gi innspill på hva man bør tenke på før man bestemmer seg for å benytte EC2 eller en annen Cloud/Grid løsning
!!TODO: Endre tegning slik at man får en edderkopp i midten
Akkurat som vanlige bjørner er disse farlige: Fordi de hindrer oss i å gjøre jobben… Det aller værste er kanskje at vi synes vi er så flinke at vi må håndtere komplesistet. Det er vel ikke noe IT-folk liker en noe shiny nytt mega coolt konsept som løser alle våre problemer… (klient/tjener, objekt-orientert programmering, web, applikasjonsserver, webservices, SOA, REST) Og jeg er jo en av de verste (jeg leker med Cloud på fritiden…) Historien om Nasa sitt firkantede hull og det runde filteret Det er en god del virksomheter som har firkantede hull med firkantede filtere (og da skal man ikke bruke teknologisk motivasjon for å gå over til Cloud)
Grid-mode: * Everything on the Grid * Mixed * Mixed with Reverse lookup (fra GRID til eget system. Kan være nyttig med eget mini-cluster. Dersom man får katastrofale problemer). * Compute GRID, no local storage Avgjørende for bruk av Cloud /EC2. Man har ikke kontroll over nettverket. Spesielt fordi det er over internet. Kan man leve med integrasjon over en kanal som man ikke har kontroll på. Den kan være godt nok, men det avhenger nok av hvilken type integrasjon man har. SAP mm. er ikke ennå like aktuelt å kjøre på gridet. Avgjørende for bruk av Cloud /EC2. Man har ikke kontroll over nettverket. Spesielt fordi det er over internet. Kan man leve med integrasjon over en kanal som man ikke har kontroll på. Den kan være godt nok, men det avhenger nok av hvilken type integrasjon man har. SAP mm. er ikke ennå like aktuelt å kjøre på gridet. TODO: Topolgi tegning av en virkelig stor appliasjon (5-6 forskjellige plattformer: Mvs, Solaris, Linux, SAP, Windows) Complexity Bears - du har bare 100! (Ta bilder: grupper av bears på hvit papier, tastatur etc.) Grid med imager, sikkert, dynamisk oppstart/stopping av instanser => høy faktor. Advarsel: En del av SOA leverandørene pusher nå SOA på GRID. Dette er løsninger med svært høy kompleksistet. Vær sikker på at du hvorfor man skal migrere over på et GRID. Det er andre løsninger. Kanskje ikke like rimelig, ikke skalerbart. Generiske løsninger på avanserte problemer => høy kompleksitet. Hva er det man egentlig skal => gi forretningmessig verdi. Å løse avanserte tekniske problemer man ikke egentlig har gir lite forretningsmessig verdi. Eksempel: Forretnignssiden sier vi må ha en backup løsning, applikasjonen er forretningskritisk -> arkitekt sier: OK da setter jeg innen feiltolerang grid løsning basert på clusterede applikasjonsservere med automatisk failover og databasegrid. I stedet må man spørre. Er det ok at man er nede noen minutter dersom man får total diskkrasj. Er det ok at man manuelt går over til failover løsning. Da blir det i stedet: en standby server hvor applikasjonen er deployet, manuell swithover og aktiv/passiv database replikering. Løser forretningskravet på samme måte, men det skjer ikke dynamisk og umiddelbart.
Dette er en presentasjon i seg selv om hvordan bygge arkitektur for cloud. Jeg nøyer meg med å si at: ---
Der kom bingoen gitt….
Det var en kollega som nevnte ordet tåkeheimen… Med bakgrunn i praktisk erfaring med implementering av forretningskritiske applikasjoner. Beskrive kort begreper som virksomhetskritiske applikasjoner, virtualisering, Grid og Cloud Computing Vise hvordan man setter opp en EC2-konto og begynner å kjøre en javabasert applikasjon med webgrensesnitt. Gi innspill på hva man bør tenke på før man bestemmer seg for å benytte EC2 eller en annen Cloud/Grid løsning
Slik er det i dag også for de som har outsourcet: De som har en lokal IT-organisasjon kan gå ned å fikse problemet selv, MEN har de bedre kompetanse enn Amazon. Er det en fordel at mange gjører på samme infrastruktur??! Normalt så er den tiden de tar å finne bugger er avhengig av hvor mange som bruker den.
Poenget er ikke alt jeg kan kjøre 9 år, poenget er at dette er vesentlig rimeligere enn all intern drift, spesielt når man tar hensyn til person kostnader, 3 års syklus på hardware/software Vanlige servere ligger på ca. 30.000 i innkjøp. I tillegg kommer betydelig strøm konstnader pga. kjøling og drift. Etter 3 år Pay-As-You-GO S3 All permanent lagring. Tar betalt for lagring og overføring (utenfor EC2) EC2 Instanstyper Nettverk Til og fra EC2-instansene Elastic IP Faste IP-adresser Hvis du vil betale for support? Amazon Web Services Premium Support (AWS Premium Support) Silver: $100 pr mnd. (for mindre oppsett) Gold: $400 pr. mnd. (gir 24x7 + mulighet for å telefonkontakt) Gratis AWS Forum – her sitter et par Amazon-ansatte (responstid varierer, men får ofte svar i løpet av et døgn) Kilde digi/HP: 21 servere gir en årlig kostnad på 368 767. I tillegg skal de passes på og vedlikeholdes. Nettverskutstyr I tillegg. Basis Software lisenser. 40 tusen pr. server og omtrent det samme i driftpersonell. 100.000 pr server.
Det var en kollega som nevnte ordet tåkeheimen… Med bakgrunn i praktisk erfaring med implementering av forretningskritiske applikasjoner. Beskrive kort begreper som virksomhetskritiske applikasjoner, virtualisering, Grid og Cloud Computing Vise hvordan man setter opp en EC2-konto og begynner å kjøre en javabasert applikasjon med webgrensesnitt. Gi innspill på hva man bør tenke på før man bestemmer seg for å benytte EC2 eller en annen Cloud/Grid løsning
Henger sammen med salatplukking, men selv med få salat plukkere er det ikke sikker man kan være skikkelig agil. Knytte tilbake til mål (levere den man skal til ønsket tid)…. Agil utvikling uten salatplukkere er best. 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.
Jammen, infrastruktur og driftsressurser representerer en viktig kompetanse… Det gjør de og (en del av) de bør være med på flyttelasset
Teknologisk sett er EC2 fin plattform for selv om det er noen utfordringer I forhold til integrasjon Organisatorisk kan bety vesentlige endringer I måten man tenker utvikling og drift Forretningsmessig er kanskje det som avgjør om man bør
Demo: Hva kan dette brukes til? Utvikling Teste fullverdig arkitektur Personlig ”produksjonsinfrastruktur” Test Proof-of-Concept på arkitektur Ekstern testing (evig problem) Last/ytelsestest Produksjonssystemer Dersom behovet for å vokse (uten initielle kostnader) er større en potensielle ulemper Konsekvenser – Situasjon utfordring løsning: Teknologi: Situasjon: Komplisert hverdag Utfordring: Complexity bears Løsning: Forenkling og enkel cloud arkitektur (self contained) Organisasjon Situasjon: Salat kokere Utfordring: Endre hele sulamitten Løsning: Bruk Cloud og legg ned driftsavdelingen Forretning: Situasjon: EC2 er der Utfordring: Juss/Risiko Løsning: Ulike modeller / Inhous TODO: Er EC2 klar til produksjonssystemer? Ja, men ikke uten at man må leve med en del ”tvilsomme” arkitekturegenskaper: EC2 er en beta tjeneste! Instansene dine kan stoppe på et hvilket som helst tidspunkt Permanent disk har akkurat kommet i etter lukket Alfa-testing (ingen garantier) Avansert lastbalansering krever en del arbeid Sikkerhet: Man setter opp en haug av linux bokser som er tilgjengelig via public IP og ssh inngang. Hva skal til for at min organisasjon skal kunne bruke Cloud Computing Risiko, Sannsynlighet, konsekvens, tiltakSummary of risk: | Risk | Mitigation| Hva passer det til? - virksomhetskritisk, men greit nok juridisk - ekstern integrasjon eller grensesnitt - presset konstandssituasjon, ordinær drift er for høyt. - behov for rask vekst, lav initiell kostnad Amazon tilbyr flere tjenester SimpleDB Mechanical Turk Pay-as-you go Oracle, Websphere, RedHat