Utvikling i skyen

Utvikling i skyen

KRONIKK: Sky-plattformene sin egen samling med svakheter å passe seg for.

Cloud computing gjør det mulig å utvikle løsninger raskere, med resultater som er mer robuste og lettere å vedlikeholde enn før. Samtidig har disse plattformene sin egen samling med svakheter å passe seg for.

Hvis du vil henge med som utvikler, bør du gjøre deg kjent med mulighetene som ligger i skyen, slik at du kan gjøre et fornuftig valg om når du bør ta dem i bruk. Les videre for å lære mer, eller kom på JavaZone 2012 og hør på foredrag fra erfarne skyutviklere.

Cloud computing har vært et tåkete begrep lenge. National Institute of Standards and Technology (NIST) i USA trekker fram fem sentrale egenskaper i "The NIST Definiton og Cloud Computing":

- Selvbetjent når som helst. Det er ingen åpningstider og ingen kasse, du gjør alt (eller det aller, aller meste) gjennom nettleser og åpne API-er.

- Alment tilgjengelig over nett. Du kan nå systemene over internett, fra pc, mobil eller andre enheter med standardprotokoller.

- Ressursdeling. Løsningen kjører på delte maskinvareressurser (nettverk, disk, prosesskapasitet, og så videre), som omfordeles etter behov. Som bruker vet du ikke akkurat hvilken maskin systemet kjører på, og du bryr deg ikke.

- Rask elastisitet. Det er enkelt, og kanskje helautomatisert, å utvide systemkapasitet ved økt last, og tilsvarende å trappe ned igjen når behovet minker.

- Målt bruk. Plattformen måler og tilgjengeliggjør metrikker som viser belastningen på systemet (båndbredde, diskplass, prosessorlast, antall transaksjoner), og disse metrikkene kan benyttes til for eksempel skalering, lastbalansering, sperrer mot overbruk og fakturering.

Ingenting av dette er nytt, disse egenskapene har vært tilstede til ulik grad i forskjellige it-systemer i flere tiår. Det nye er tilgjengeligheten: Aldri før har det vært så lett å sette opp en løsning som har alle disse egenskapene, med et mangfold av tilbydere å velge mellom og rike API-er som lar deg sette opp alt selv, uten noen forsinkelser og uten å trenge en eneste telefonsamtale eller epost i forkant.

Den første gevinsten er at det er lett å sette opp nye miljøer. Ved å plassere serverne dine i skyen, trenger du ikke vente på tungrodde bestillingsprosesser for å få på plass test- eller produksjonsoppsett. Du trenger ikke rydde fysisk plass i en serverhall og kable opp maskinene (eller vente på at noen andre gjør det for deg), og du trenger ikke bekymre deg for å bestille riktig maskinvare eller slåss med drivere for å få alt til å spille i hop. Hvis du noensinne har vært på et prosjekt som ble forsinket av miljøoppsett, vet du at dette kan dreie seg om store arbeidsbesparelser.

En annen gevinst er at du betaler bare for det du bruker. Det er flere betalingsmodeller ute og går, men de fleste leverandørene lar deg betale for tiden du benytter deg av ressursene, med lave eller ingen etableringskostnader. Samtidig går det raskt å utvide ressursene om du trenger det. Dermed slipper du, eller firmaet du jobber for, å gjøre store investeringer i maskinvare i forkant i tilfelle lasten blir større enn forventet, samtidig som du unngår risikoen for at systemet ikke klarer ta unna. Hvis løsningen har kapasitetsbehov som varierer gjennom året, kan du øke antallet servere midlertidig i høysesongen, og redusere så snart trykket er over. Eller hvis du skal kjøre en stor engangsjobb, for eksempel for å konvertere data fra et system til et annet, kan du sette opp et midlertidig miljø som du skroter straks jobben er gjort, og betale langt mindre enn om du skulle kjøpt inn egen maskinvare som ville stått ubrukt etterpå.

Og ikke minst kan du jobbe hvor som helst. Med mindre du setter opp sperrer selv av sikkerhetsgrunner, kan du koble deg på skyplattformen din uansett hvor du sitter fysisk, uten å trenge VPN-oppsett, kodebrikker eller annet styr.

Som en følge av dette kan du få til mye hyppigere leveranser. Siden det er lett og billig å sette opp, endre og ta ned miljøer, kan du raskt få rullet ut og testet nye versjoner i et dedikert, isolert testmiljø uten å påvirke produksjonsmiljøet. Det er enkelt å klone produksjonsmiljøet slik at du vet at test og produksjon kjører med likt oppsett. Ta gjerne en titt på bøkene Continuous Delivery av Jez Humble og David Farleuy, eller Release It! av Michael Nygard for gode tips om hva du bør tenke på for å få opp leveransetakten.

Du kan også benytte deg av ferdig oppsatt utviklingsverktøy. Det finnes flere leverandører som tilbyr versjonskontroll, byggeservere, brukergrensesnittstest og lignende som tjenester, slik at du slipper å sette opp og drifte det selv. Noen eksempler er GitHub, Gitorious, CloudBees og SauceLabs.

Friheten i skyen kommer dessverre ikke gratis. Først må du velge en utviklingsmodell: Vil du kjøre på virtuelle servere der du gjør oppsett selv (Infrastructure as a Service, eller IaaS) eller vil du bygge løsningene dine på en skyplattform (Platform as a Service, eller PaaS)?

Dersom du velger IaaS, har du større frihetsgrader i hvordan du setter opp løsningen, men du trenger mer driftskunnskaper i utviklingsteamet for å få utnyttet denne friheten godt. Dette er en av grunnene til oppmerksomheten rundt Devops-bevegelsen, som prøver å redusere avstanden mellom drift og utvikling. Det vil være lurt å se på løsninger for automatisk provisjonering av servere, slik som CfEngine, Chef eller Puppet, for å forenkle jobben med å konfigurere virtuelle servere likt. Du bør også sette opp målings- og varslingssystemer, enten ved å benytte deg av det leverandøren din tilbyr eller sette opp ditt eget system, slik som Hyperic, Nagios eller Zabbix. Noen eksempler på IaaS-plattformer er Amazon EC2, GoGrid og RackSpace.

For å kunne nyte godt av skalerbarheten til skyen, må du også passe på å lage en systemarkitektur der du kan skalere horisontalt, ved å sette opp nye servere, i stedet for vertikalt, ved å øke kapasiteten til eksisterende servere. Det vil si at løsningen din må unngå komponenter som det bare kan finnes én av.

Dersom du velger PaaS, er mange av de vriene arkitekturvalgene allerede tatt for deg, og du utvikler på en plattform som er designet for å skalere opp og ned fritt etter behov. Til gjengjeld mister du noen av frihetsgradene, og risikoen for å binde seg til én leverandør er større. Du må også lære deg API-ene og designreglene for plattformen du tar i bruk, som du slipper med IaaS. Noen eksempler på Platform as a Service er Force.com, Heroku, Google App Engine og Microsoft Azure.

Det er noen farer du bør være obs på før du hopper over i skyen:

- Valg av prismodell. Ta deg tiden til å undersøke de ulike prismodellene leverandørene tilbyr, og vurder hvilken som passer best for deg. Betaling for bruk er sannsynligvis billigst for kortvarige løsninger og prototyper, men det kan være mye å spare på å reservere kapasitet fast dersom du vet at du alltid vil trenge minst to servere.

- Sikkerhet. Enkel tilgang gjør livet lettere for de fleste, men pass på at det ikke blir for vid åpent.

- Katastrofehåndtering. Hva skjer hvis en server kræsjer? Du bør undersøke hva skyleverandøren din garanterer, det kan være at all sikkerhetskopiering er ditt eget ansvar.

- Leverandørbinding. Finnes det andre leverandører som kan tilby tilsvarende tjenester? Hvor lang tid vil det ta deg å bytte leverandør dersom den du har skrur opp prisen, går konk eller bestemmer seg for å konkurrere med deg?

- Integrasjon. Har du mange eksisterende systemer som trenger snakke med den nye løsningen? Flere leverandører tar godt betalt for datatrafikk inn og ut av skyen deres, selv om nettverkstrafikk internt i skyen som regel er gratis eller svært billig.

Ikke la dette skremme deg fra å prøve ut de nye mulighetene. Det er lett å komme i gang, og hvis skyen passer til dine behov, kan du få en mye bedre og mer produktiv utviklerhverdag, der du bruker mindre tid på å sloss med infrastruktur og kan konsentrere deg om å skrive nyttig kode. Hvis du vil møte andre som har tatt i bruk cloud computing og høre hva de har lært, bør du ta turen til Javazone 2012, der det blir mange foredrag om temaet.

Les om:

Utvikling