Cloud i brug. Migrering af Digitalisér.dk til cloud computing infrastruktur

Transkript

1 Cloud i brug Migrering af Digitalisér.dk til cloud computing infrastruktur

2 02 Indhold > Executive Summary Digitaliser.dk Udviklingsprojektet Den tekniske infrastruktur Mål med migrering til Cloud baseret infrastruktur Løsningsmodel for driften Konklusion

3 03 Executive Summary > I efteråret 2009 blev det besluttet at flytte driften af Digitalisér.dk fra en traditionel hosting leverandør til en cloud computing baseret på Amazon Web Services (AWS). Et af målene med flytningen var at øge fleksibiliteten i udviklings- og test miljøerne, men samtidig bevare den egenskab, at udviklings- og testmiljøer kunne holdes teknisk set identiske med produktionsmiljøet en kombination vi ikke havde været i stand til at opnå hos den daværende hosting leverandør. Samtidig var der en forventet omkostningsbesparelse. Projektet var ved at overgå fra udvikling til vedligehold og det ville betyde, at det ikke længere ville være nødvendigt at have alle miljøer kørende hele tiden, som det var tilfældet under udviklingsforløbet. Forventningen var, at AWS ville give os muligheden for løbende at tilpasse eller helt at slukke for udviklings- og testmiljøet i perioder. Udover de isolerede projektmål blev Digitalisér.dk valgt som et projekt, der ville kunne give IT- og Telestyrelsen erfaring på Cloud Computing området. Digitalisér.dk blev identificeret som driftsmæssigt lavrisiko, da driften foregik på standard infrastruktur og SLA kravene ikke var i den kritiske ende. Desuden havde en risikovurdering af Digitalisér.dk ikke identificeret nogen kritiske områder, der vurderedes til at blive påvirket af en drift baseret på AWS. Udgangen blev, at vi gik fra at have en leverandør, der hostede alle miljøer, hvilket sikrede ensartethed men begrænsede fleksibiliteten og var omkostningstungt, til en leverandør der nu udelukkende står for produktionsmiljøet. Brugen af AWS til infrastrukturen sikrer i denne model, at udviklings- og testmiljøerne stadig kan holdes identiske med produktionsmiljøet, men samtidig har udviklingsteamet i denne model opnået fuld kontrol med udviklings- og test miljøet netop den kombination af krav der i den gamle model synes at være modstridende.

4 04 > Der har samtidig været en omkostningsbesparelse på driften også hvis der ses isoleret på produktionsmiljøet. Produktionsmiljøet anvender ikke skalerbarheden hos AWS, men kombinationen af en produktionsinfrastruktur hos AWS med en driftsleverandør har stadig skåret i driftsomkostningerne. Rent driftsmæssigt har Digitalisér.dk fungeret meget tilfredsstillende på AWS, hvor det har kørt siden julen Besparelserne på udviklings- og testmiljøer har været væsentlige, da vi nu kun betaler for den egentlige infrastruktur og ikke har driftsleverandøren involveret. Det har dog vist sig, at ideen med at slukke for udviklings- og testmiljøer når de ikke anvendes, endnu ikke har fungeret i praksis. Ofte kan det være svært at vurdere om et miljø skal slukkes, da man ikke ved om det skal bruges næste dag. Hvis denne model skal virke, skal det at tænde og slukke miljøer være som at tænde og slukke for en kontakt, men der er vi endnu ikke henne.

5 05 Digitalisér.dk > Digitalisér.dk er udviklet og drevet at IT- og Telestyrelsen ud fra ideen om at skabe en fælles samarbejdsplatform omkring digitaliseringen af Danmark. Med udgangspunkt i ideerne fra sociale medier er Digitalisér.dk et værktøj for IT professionelle, der tager udgangspunkt i brugergenereret indhold. Digitalisér.dk passerede i maj registrerede brugere og indeholder mere end ressourcer. Samtidig er Digitalisér.dk et ressourcebibliotek over bl.a. standarder, hvor brugerne kan finde autoritativ information om brugen af standarder indenfor den offentlige sektor.

6 06 Udviklingsprojektet > Digitalisér.dk projektet blev startet i forsommeren 2008 og det blev besluttet at anvende den agile udviklingsmetode SCRUM. Den første offentlige beta version af Digitalisér.dk gik i luften oktober I den agile udviklingsmetodes ånd var målet, at alle efterfølgende 14 dages sprints skulle afsluttes med at release en ny version til produktion. Med andre ord skulle hver 14 dages sprint indeholde både en udviklings, test, stabilisering og release fase! I forhold til infrastrukturen i projektet betød dette, at applikationen skulle gå fra udviklingsmiljøet til test til staging og endeligt til produktion inden for én 14 dages sprint. Figur 1: Udviklingsflowet for Digitalisér.dk

7 07 Den tekniske infrastruktur > Selve driften af Digitalisér.dk foretages på en relativt simpel infrastruktur: En Windows server som frontend, da brugergrænsefladen er baseret på.net platformen En Unix (OpenSolaris) backend server, hvor backend delen er baseret på Java platformen Desuden er der en server til håndtering af NemLogin, da denne funktion af tekniske årsager ikke kunne lægges på frontend serveren. Frontend serveren udstiller en web baseret brugergrænseflade, mens backend serveren udstiller et REST baseret API mod omverdenen. Kommunikationen fra frontend til backend serveren er udelukkende baseret på webservices. Denne infrastruktur er relativt simpel, så udfordringerne til infrastrukturen kom i højere grad fra de krav, som den agile udviklingsproces stillede. Da vi, som nævnt, inden for en 14-dages sprint skulle igennem en cyklus, hvor applikationen gik fra udviklingsmiljø til testmiljø og videre til staging og endelig produktion, var det kritisk for os at disse overgange kunne gennemføres effektivt og uden overraskelser. Konklusionen var, at dette kun ville fungere, hvis de fire miljøer var (næsten) identiske. Desuden skulle vi have en effektiv deployment funktion, der kunne tage en version fra vores build server og deploye den på en vilkårlig af de fire miljøer. Behovet for identiske miljøer blev opnået ved at etablere det hele hos en traditionel hosting leverandør. Og når vi efterfølgende evaluerer denne beslutning i forhold til kravet om effektiv flytning mellem miljøerne, har denne model været en succes. Det lykkedes stort set at fastholde en sprintcyklus på 14 dage, hvor det at holde flere miljøer kørende og flytte applikationen fra miljø til miljø fungerede gnidningsfrit. Udfordringen i modellen var langsomme og dyre processer ved tilpasning af udviklings- og testmiljøerne. Set fra hosting leverandørens synspunkt var alle miljøer driftsmiljøer, hvor fleksibiliteten lå i, hvilken SLA man ønskede for miljøet Guld, Sølv eller Bronze. Det betød at alle miljøerne var underlagt de samme ITIL processer, hvor alle ændringer til miljøerne skulle igennem de samme procedurer hos driftsleverandøren.

8 08 > Under udviklingsforløbet var der løbende behov for at lave større eller mindre tilpasninger af miljøet. I nogle tilfælde var teamet ikke i stand til på forhånd at sige præcist, hvordan miljøet skal tilpasses for at møde ændrede applikationskrav. Derfor var denne afhængighed til driftsleverandøren for selv den mindste ændring til udviklings- og testmiljøerne en kilde til irritation og ikke mindst var det en dyr model både i direkte omkostninger og i skjulte omkostninger i projektteamet grundet flere afhængigheder til driftsleverandøren. Problemstillingen blev diskuteret med driftsleverandøren, men problemet set fra leverandørens synspunkt var, at leverandøren ikke kunne differentiere sine produkter herunder SLA per kunde. Det ville leverandøren ganske enkelt ikke kunne administrere og der ville ikke være basis for forretning i en sådan model. Figur 2: Skitsering af idéen til den nye cloud model Disse krav til løbende tilpasninger af miljøet blev forstærket af den agile udviklingsmetode, hvor kravene til applikation og dermed miljøet ikke lægges fast tidligt, men løbende ændrer sig. Man kan sige at behovet for agilitet også bliver afspejlet på infrastrukturniveau.

9 09 Mål med migrering til Cloud baseret infrastruktur > I efteråret 2009 blev det besluttet at flytte infrastrukturen til Amazon Web Services (AWS). Målene med denne flytning var: At give udviklingsteamet større kontrol over udviklings- og testmiljøer og dermed reducere frustrationer og omkostninger ved ændringer til miljøerne. At reducere driftsomkostninger til udviklings-, test og staging miljøer ved - at have en meget begrænset SLA på disse miljøer - at kunne lukke ned for nogle af miljøerne i perioder Digitalisér.dk skulle overgå fra at være et udviklingsprojekt til at være et vedligeholdelsesprojekt og det var derfor ikke nødvendigt at have disse miljøer kørende hele tiden. At reducere omkostningerne til driften af produktionsmiljøet gennem en forventet billigere drift baseret på en Cloud infrastruktur. Udover disse projektmål blev Digitalisér.dk valgt som et projekt, der skulle give IT- og Telestyrelsen erfaring på Cloud Computing området. Driftsmæssigt var Digitalisér.dk et lavrisiko system, da driften foregik på standard infrastruktur og SLA kravene ikke var i den kritiske ende. Desuden havde en risikovurdering af Digitalisér.dk ikke identificeret kritiske områder, der blev vurderet til at blive påvirket af en drift baseret på AWS.

10 10 Løsningsmodel for driften > Som beskrevet tidligere var udgangspunktet, at vi havde alle fire miljøer hos den samme hosting udbyder for at sikre, at kravet om ensartethed på tværs af miljøer var opfyldt. Med AWS blev det muligt at have miljøer baseret på samme infrastruktur og samtidig adskille driften af staging og produktionsmiljøer fra driften af udviklings- og testmiljøer. For produktions- og stagingmiljø blev der lavet en separat kontrakt med en driftsleverandør, hvor kontrakten specificerer, at driften skal være baseret på AWS infrastruktur. AWS kontoen til produktion og staging ligger dermed hos denne driftsleverandør. applikationsteamet kan starte miljøer til udvikling og test, der er helt identiske med produktionsmiljøet inklusive seneste opdateringer til platformen herunder sikkerhedspatches. Med andre ord har vi med denne model opnået både at kunne sikre ensartethed i miljøerne, samtidig med at applikationsteamet har fuld kontrol over udviklings- og testmiljøer. Figur 3: Endelig løsningsmodel for Digitalisér.dk i clouden Derudover er der en vedligeholdelseskontrakt på applikationen, hvor leverandøren på denne kontrakt anvender AWS til udviklings- og testmiljøer dvs. udvikling og testmiljø er etableret under en anden AWS konto end staging og produktionsmiljø. I driftskontrakten er det desuden specificeret, at images af produktionssystemet (AWS AMIs) skal stilles til rådighed for vedligehold. Dette sikrer at

11 11 Konklusion > Generelt har vi nået målene med flytningen af Digitalisér.dk til AWS og driften har til dags dato kørt meget tilfredsstillende i 6 måneder hos AWS. Vi har opnået det ønskede fleksibilitet i udviklingsog testmiljøer, samtidig med at vi kan holde disse identiske med produktionsmiljøet. Der har været en omkostningsbesparelse både på selve driften af produktionsmiljøet og især på udviklings- og testmiljø. Produktionsmiljøet anvender ikke skalerbarheden hos AWS, men kombinationen af en produktionsinfrastruktur hos AWS med en driftsleverandør har stadig skåret i driftsomkostningerne. For udviklings- og testmiljøer er besparelserne større, da vi her kun betaler for den rå infrastruktur og ikke har en driftsleverandør involveret. Det eneste sted hvor praksis har vist sig anderledes end forventet er på muligheden for at slukke miljøer når de ikke anvendes. Da det at tænde miljøet ikke bare er at trykke på en knap bliver miljøerne sjældent slukket i praksis, da man ikke ved om man eventuelt skal bruge dem igen næste dag.

12 > Kontaktoplysninger For yderligere oplysninger, kontakt: IT- og Telestyrelsen Holsteinsgade 63 DK-2100 København Ø Telefon: Fax: