IaaS / UH-sky USIT Julebord Blindern, Oslo 27.nov 2014

Agenda Hvorfor sky? Hvorfor nå? Skymodeller (IaaS, PaaS, SaaS) Worst practices Nøkkelen til skyen: RESTful services Utvikling i skyen OpenStack

Hvorfor sky? Hvorfor nå?

Software Defined ANYTHING Software-Defined Data Center Networking Software-Defined Storage Software Defined ANYTHING Open Compute Project Virtual Data Centers Fabric-Based Computing Integrated Systems Real-Time Infrastructure

Gartner's 2014 Hype Cycle for Emerging Technologies

Skyens evolusjon I begynnelsen var Mainframe Livet var godt PC-alderen kom med distribuert client-server Ting kunne bygges raskere og billigere Mer komplekst, mindre standardisering Nye utfordringer med patching, styring, vedlikehold Så kom Internet Utfordringer med sikkerhet Ting ble enda mer komplekst

Enter skyen Vi kombinerer det beste fra mainframe-tiden med det beste fra PC-alderen, sammen med Internet Pay as you go, på samme måte som man betaler for strøm og vann Massiv skalering Ting kan automatiseres, forenkles og gjøres tilgjengelig som on-demand-tjenester Software is king

Skymodeller

Slutt- brukere SaaS Applikasjons- utviklere PaaS IT-arkitekter IaaS

Worst practices

Misforståelse Migrering til skyen er en enkel løsning som vil føre til store besparelser Forstå forskjellen på stateful og stateless design Kompetanse til å avgjøre om en bestemt applikasjon er en god kanditat for migrering til skyen

Feil antakelser om sikkerhet Skyen er grunnleggende og katastrofalt usikker! Min skyleverandør håndterer sikkerheten for meg Arkitekter, utviklere og sikkerhetsfolk må ha en bred forståelse av sikkerhet i skyen, samt lover og regler Designe for sikkerhet i utgangspunktet, ikke tette hullene i etterkant

Velge favorittleverandør Vi foretrekker å programmere i .NET, så da velger vi Microsoft Azure Vi liker Python, så det naturlige valget er Google App Engine Forstå forskjellene på de ulike tjenestemodellene (SaaS, PaaS, IaaS). Vite hvilke business cases som egner seg for hver modell

Undervurdere organisasjonsendring Vår organisasjon er klar for skyen, våre medarbeidere skjønner poenget Start med små prosjekter med minimal risiko Formidle ønsket og visjonen om sky ved hver anledning og så ofte som mulig

Mangel på kompetanse Utvikling i skyen er bare minimalt forskjellig fra “vanlig” utvikling, dette tar vi på strak arm Vite hvilken kompetanse som trengs i et prosjekt Tette eventuelle hull via opplæring, nyansettelser, innleide konsulenter e.l.

Nøkkelen til skyen: RESTful services

Hvorfor REST De fleste skyløsninger i dag eksponerer sine tjenester via REST REST bidrar til å abstrahere bort kompleksiteten i et heterogent miljø Sterkt skille mellom forretningslogikk og den komplekse teknologien som ligger i bunn API-ene skal være tilgjengelig overalt, for mange ulike dingser og maskiner

Representational State Transfer Skille ressurs fra representasjon. F.eks. kan ressurs være noe data, mens representasjon kan være JSON eller XML Kan skalere ulike komponenter uavhengig av hverandre Manipulering av ressurser skjer via representasjonen. Det er nok informasjon via metadata slik at en klient kan gjøre endringer eller slette ressursen på serveren, forutsatt at klienten har lov til det

REST forts. Selvbeskrivende meldinger. Enhver melding gir nok informasjon om hvordan meldingen skal prosesseres. F.eks. vil “Accept application/XML” fortelle en parser at den kan forvente at meldingen er i XML. Hypermedia as the engine of application state (HATEOAS). Klienten kommuniserer med applikasjoner kun via hypermedia (hyperlinks) Applikasjonens tilstand representeres av URI-er på klientsiden. Failover på serversiden har derfor ingen konsekvenser for klienten.

Utvikling i skyen

Utvikling i skyen Selvbetjening Pay as you use Elastisitet, skalerbarhet Automatisering Dev-Ops Sky er en “game changer”

Har navn som happy.uninett.no De er unike, elsket og oppdratt for hånd Når de blir syke, tar man dem til veterinær og pleier dem tilbake til god helse Store VM-er med tilstand Levetiden måles i år Applikasjoner skalerer opp (mer CPU, RAM) Applikasjoner er ikke designet til å tolerere feil

Har nummernavn som b086.uninett.no De er nesten identiske med hverandre Når de blir syke, avliver man dem og skaffer en ny Små tilstandsløse VM-er Levetid måles i timer til måneder Applikasjoner skalerer horisontalt med flere VM-er Applikasjoner forventer feil

Hva med legacy-systemer? Hvordan skal vi kunne ta i bruk denne raske innovasjonen, og samtidig levere på det vi allerede har? Vi blir ikke kvitt legacy Vi må leve i begge verdener, men vi må fornye oss Ikke bare teknologi Også prosesser, kultur Automatisering, deling, samarbeid, DevOps, CAMS!

ACID vs. BASE Mange legacy-applikasjoner avhenger av ACID-transaksjoner. ACID (acomicity, consistency, isolation, durability) sikrer at en transaksjon er komplett og konsistent Med ACID er transaksjonen ikke komplett inntil den er oppdatert overalt (f.eks. skrevet til disk)

ACID vs. BASE Skyarkitektur bruker en annen tilnærming via BASE: Basically Available, Soft State, Eventually Consistent BASE brukes ofte i miljøer der man forventer at noder feiler, eller der et system må fortsette å virke selv om klienten er på nett eller ikke (mobile klienter)

Hvilket problem løser OpenStack? OpenStack leverer et rammeverk for å bygge elastisk sky-infrastruktur i massiv skala Fasiliterer håndtering av Compute-, Nettverks-, og Lagringsressurser Leverer infrastruktur for elastiske applikasjoner

WTF?

OpenStack Modulær arkitektur Basert på et (voksende) sett av kjernetjenester Designet for skalerbarhet og elastisitet

OpenStack Dashboard (Horizon) Enkel self-service-UI for brukere Basisfunksjoner for management av skyen (ikke av infrastruktur) Definere brukere, prosjekter og kvoter

OpenStack Compute (Nova) Støtter flere hypervisors (KVM, Xen, LXC, Hyper-V, ESXi) Eget Openstack-API og support for Amazon EC2 API Distribuerte controller-tjenester håndterer skedulering, API-kall osv.

OpenStack Block Storage (Cinder) Leverer blokklagring for virtuelle maskiner (persistente disker) Ligner på Amazon EBS Plugin-arkitektur slik at leverandører kan legge inn utvidelser

OpenStack Networking (Neutron) Nettverkstjeneste Rammeverk for Software-Defined Networking (SDN) Tillater integrering av nettverksløsninger basert på software eller hardware

OpenStack Image Service (Glance) Lagrer og henter disk images (templates for virtuelle maskiner) Støtter Raw, QCOW, VMDK, VHD, ISO, OVF og AMI/AKI I bakgrunnen: Filsystem / Swift / Amazon S3

OpenStack Object Storage (Swift) Modellert etter Amazon S3 Leverer en enkel tjeneste for lagring og henting av vilkårlig data Eget API og S3-kompatibelt API

OpenStack Telemetry (Ceilometer) Samler performance-data (CPU, nett etc.) Designet for integrasjon og utvidelser Innsamlet data tilgjengelig via REST-API

OpenStack Orchestration (Heat) Leverer template-basert orkestrering av sky-applikasjoner Modellert etter AWS CloudFormation Avansert funksjonalitet som høytilgjengelighet og automatisk skalering

OpenStack Identity Service (Keystone) Felles rammeverk for autentisering Håndterer brukere, prosjekter og roller Pluggbare backends (SQL, PAM, LDAP etc.)

OpenStack Database Service (Trove) Ny tjeneste, ikke produksjonsklar Under kraftig utvikling Database-as-a-Service Tradisjonelle transaksjonsdatabaser og NoSQL-databaser Gjør det enklere for applikasjoner som trenger en database, man slipper å sette opp og forholde seg til database-management

Message Queue Openstack bruker message queue for kommunikasjon mellom komponenter Støttede backends: RabbitMQ, QPID og ZeroMQ

Mer info om IaaS / UH-sky UiOs avsluttede IaaS-prosjekt: http://www.usit.uio.no/prosjekter/nansen-iaas/ UH-sky: https://iaas.readthedocs.org/en/latest/ IRC-kanalen #uh-sky på Freenode: http://webchat.freenode.net/?channels=uh-sky

Modell for innovasjon i morgen Teknologivalg i dag = Modell for innovasjon i morgen Jim Whitehurst, CEO, Red Hat