Da fire it-folk fra Microsoft og fem it-folk fra Banedanmark mødtes hos Microsoft i Vedbæk mandag morgen 12. april, vidste de ikke præcis, hvad ugen ville bringe.
Der var dog nogle ting, der lå fast.
De havde en konkret opgave: Byg et system, der demonstrerer, at det er muligt at anvende Microsofts Azure-platform som basis for en ny version af Banedanmarks Trafikinformations-system på internettet.
Det lå også fast, at projektlokalet i Vedbæk de næste fem dage ville være stedet, hvor udviklingen fandt sted.
Deadline var også fastlagt. Fredag eftermiddag skulle systemet demonstreres for Banedanmarks it-beslutningstagere, der så ville vende tommelfingrene op eller ned for et videre projekt.
Hvad der ikke lå fast var, hvordan de skulle nå i mål.
De vidste heller ikke noget om den overraskelse, de ville få, med hensyn til datareplikering fra en Oracle-database til SQL Azure.
Uvidende var de også om, hvilken indflydelse islandsk vulkan-aske ville få på projektet.
Nu sidder Banedanmarks it-ledere og skal træffe beslutning om projektets videre forløb. Selvom pulsen banker hurtigere hos Banedanmarks CIO, Kenneth Lau Rentius, og it-udviklingschef Michael Kvistholm, når risikoen for scope-creep kommer på tale, så kan Computerworld allerede nu afsløre, at Banedanmark vil gå i gang med et egentligt projekt med at etablere Trafikinformations-systemet på Azure-platformen.
Men lad os vende tilbage til mandag morgen i projektlokalet hos Microsoft i Vedbæk.
Tror du på projektet?
"Vi lagde op til en meget åben kultur og meget åben kommunikation om tvivl og forbehold," siger Martin Born, der fungerede som projektleder.
Han var klar over, at det var en stor opgave, der skulle gennemføres på relativt kort tid.
At mange af projektdeltagerne ikke kendte hinanden, gjorde ikke udfordringen mindre.
"Mange havde en bekymring om, hvorvidt man som gruppe på så kort tid kunne nå at arbejde sammen og etablere løsningen. Ville teamet fungere?" opsummerer Martin Born projektdeltagernes bekymringer.
Der var en stor spredning i gruppen af it-folk. Banedanmark stillede eksempelvis med en .Net-udvikler, en Oracle-udvikler, en CMS-mand og arkitekt.
"Det var en broget flok med hver deres billede af verden," siger Martin Born.
Deltagerne blev bedt om at angive deres tro på, at projektet ville nå i mål - på en skala fra 1 til 5.
"1 indikerer, at man er sikker på, at projektet bliver en fiasko. 2 betyder, at man er alvorligt i tvivl, om projektet kan lade sig gøre," forklarer Martin Born.
Første tillidsmåling viste, at to projektdeltagere havde alvorlig tvivl om projektets succesmuligheder.
Selvom der således var tvivl om projektets bæredygtighed, var projektdeltagerne indstillet på at arbejde for at få det til at blive en succes.
Tillid vokser med veldefinerede opgaver
Fra Microsoft deltog blandt andre Süleyman Caglar. Han var lead developer på projektet og skulle udover at kode meget af backend-delen af systemet også sørge for at delene kom til at hænge sammen. Han var imponeret over alles indstilling til projektet.
"Alle var villige til at gøre en indsats for at få det til at lykkes. Det var også nødvendigt, når der kun var en uge til at nå det på med nogle mennesker, som ikke havde mødt hinanden før," siger han.
Deltagerne blev delt op i smågrupper, der hver især skulle tage sig af delelementer af det samlede system.
"De brugte et par timer i løbet af mandagen på at bestemme, hvordan deres opgaver skulle gribes an. De udarbejdede en liste over risici: Hvad kan gå galt og hvordan kan det afhjælpes. Det gav nok noget tro på projektet, da de selv kunne finde på løsninger til eventuelle problemer," mener Martin Born
Efter den lille øvelse var noget af skepsissen forsvundet. 2-tallerne var blevet til 3-taller.
Skepsissen blev generelt mindre og mindre, efterhånden som ugen skred frem.
Fra Banedanmark deltog blandt andre it-arkitekt Jesper Bergman. Han var indstillet på at give projektet en chance, men tvivlede på, at det hele kunne nås.
"Jeg var nok den, der var mest skeptisk til at starte med, men over dagene steg mine forventninger fra det negative til det positive, og til vores endelige demo var det en stor fornøjelse at opleve den meget positive reaktion fra Kenneth Lau Rentius og Michael Kvistholm," fortæller han.
Inden vi hører mere om Banedanmarks CIO, Kenneth Lau Rentius, og it-udviklingschef Michael Kvistholms meget positive reaktion, skal vi først se lidt nærmere på, hvad projektteamet nåede frem til.
Replikering med Biztalk
Under Arkitekturdesign-sessionen var replikering af data fra Oracle til SQL Azure blevet udpeget som et særligt område, der skulle ses nærmere på.
"Vi troede oprindelig, at datareplikering mellem Oracle og SQL Azure skulle etableres og tænkte i baner med replikering, synkronisering og sync-framework," forklarer Martin Born.
Det viste sig imidlertid, at Banedanmark havde en Biztalk-server, der kan anvendes til at skubbe data fra Oracle-databasen og op til SQL Azure.
"I den oprindelige skitse til POC-løsningen, var det tanken at lave noget database-synkronisering mellem vores interne RDS-database og SQL Azure. Dette gik vi bort fra tidligt i den indledende fase og erstattede interfacet med noget, der ligger lidt tættere på vores strategi på arkitekturområdet.
Vi har en BizTalk-baseret serviceplatform kørende og for at sikre blandt andet løs kobling mellem RDS og SQL Azure, samt muligheden for genanvendelse af trafikinformationsdata, valgte vi at bruge en WCF-SQL-adapter til at forbinde til SQL Azure og så skubbe data ud løbende," siger Jesper Bergman.
Der var imidlertid ikke etableret noget service-interface til Oracle-databasen med trafikinformationsdata, så til demo-systemet blev det simuleret ved hjælp af nogle tekstfiler.
It-udviklingschef hos Banedanmark, Michael Kvistholm, er glad for Biztalk-løsningen til replikering.
"Projektet er blevet nemmere ved, at vi i dag har en eksisterende Biztalk-løsning, der udveksler data. Vi havde ikke ved præsentationen en online-replikering, men det blev dokumenteret, at der ikke umiddelbart er nogen udfordringer i at koble Oracle 8 ud igennem Biztalk og videre ud i skyen. Det kan lade sig gøre," forklarer Banedanmarks it-udviklingschef.
Stored procedures i SQL Azure
Der er tale om en Oracle database version 8, hvilket er en usupporteret version, så Banedanmark er interesseret i at flytte data over i en ny database. Det er dog ikke kun data som ligger i databasen, men også forretningslogik i form af stored procedure.
Der er tale om 3.000 linjers stored procedures, hvilket kan være en udfordring at skulle dechifrere, men Banedanmark stillede med en Oracle-udvikler, der kendte til logikken i stored procedures, så det blev ikke et problem.
"Vi startede med at flytte alle tabeller til SQL Azure. Det er stort set samme skema i SQL Azure som i Oracle. Vi havde en Oracle-udvikler fra Banedanmark, der kunne forklare, hvad de stored procedures egentlig gik ud på. Vi brugte således ikke lang tid på at analysere dem og koncentrerede os om at implementere dele af dem i SQL Azures og så flytte noget af logikken til to andre lag; data acces og business lag. Der var noget formatering og håndtering af sammenhænge mellem tabeller, som bedre hører hjemme i data acces lag og business lag end i en stored procedure," siger Martin Born.
To teknologier i data access lag
I data access laget anvendes to tilgangsmåder til at få fat i data.
"Data access laget indeholder kode til at tilgå data i SQL Azure. Det er teknologier som Entity Framework og Linq2SQL der giver adgang til databasen. Linq2SQL har været fremme i længst tid og med den får man en model for databaselaget. Entity Framework har en model for datalag og objekter. Entity Frameworket er mere fleksibelt i den sammenhæng. Med komplekse datastrukturer i databasen kan man lave en mere logisk objektmodel. Vi har implementeret begge dele, men fremover vil vi formentlig anvende Entity Framework," siger Süleyman Caglar.
Vigtigt med domæne-eksperter
Martin Born fremhæver vigtigheden af at have de rigtige folk med i et så kort projektforløb som en uges proof-of-concept.
"Som konsulent kan man nogle gange blive tvunget til at udtænke løsninger efter eget forgodtbefindende, men her havde vi en kunde, der havde domæneviden. Deres applikations- og databaseviden var uundværlig. Det gjorde, at vi kunne skyde genveje flere steder. Blandt andet ved omskrivning af stored procedures. En fremmed skulle ikke sidde og kigge 3.000 linjers kode igennem. Vi sad med eksperten på området, der vidste, hvad der foregik," siger Martin Born.
Bedre performance og færre data til browseren
En del af motivationen for at flytte trafikinformations-systemet op i skyen er, at undgå at systemet bryder sammen i spidsbelastningssituationer.
Derfor er spørgsmålet om performance interessant for den nye platform, og projektteamet etablerede også et testmiljø, så man løbende kunne teste svartider.
"Performance blev seks gange bedre. Vi havde svartider på omkring 0,2 sekunder. Banedanmarks eget system havde svartider på mellem 1,1 sekunder og 1,8 sekunder på forskellige tidspunkter i løbet af ugen," siger Martin Born.
Det var blandt andet ved at reducere noget af datamængden, der sendes ud til browseren, at der kunne skæres noget svartid væk.
"Vi kunne halvere datamængden, der blev overført fra Azure ud til browseren i forhold til Banedanmarks eksisterende applikation. CMS-folk fra Banedanmark kiggede lidt på hvilke data, som returneres af systemet i dag. De fandt redundante og overflødige data, der kunne skæres væk, så vi fik færre data," siger Martin Born, der samtidig ser yderligere muligheder for at reducere datamængden i et kommende system.
Yderligere forbedringer med Ajax
"Der ligger en kæmpe mulighed for at forbedre yderligere. Vi kunne se, at det eksisterende system sender hele siden til browseren. Javascript og hvad der ligger af statisk information fylder omkring 200 Kb, og det bliver hentet hver gang, siden refreshes eller hvert 30 sekund, når websiden er åben. Hvis man bruger AJAX eller andet til kun at sende data, der har ændret sig, så kan man skære drastisk ned på datamængden. Det vil man gøre ved den endelige implementering. Det gjorde vi ikke i proof-of-concept," siger Martin Born.
Man kan indvende, at sammenligningen mellem
Banedanmarks nuværende systems svartider og demo-systemet på Azure-platformen ikke er helt fair, da Banedanmarks eksisterende site har flere brugere.
"Banedanmarks site har selvfølgelig flere brugere. Nu har vi ramt Banedanmark på forskellige tidspunkter - vi har været på arbejde det meste af døgnet - så vi har forhåbentligt også ramt det på tidspunkter, hvor der ikke er så mange andre brugere," siger Martin Born.
Ikke decideret performancetest
Projektteamet simulerede flere brugere ved hjælp af test-værktøjerne, men den tilgængelige båndbredde i projektlokalet satte en naturlig grænse for, hvor mange samtidige brugere, der kunne testes med.
"Vi simulerede flere hundrede brugere, men kunne ikke bruge resultatet til så meget, da vi løb ind i et båndbredde-problem for testklienterne. Vi havde 50 Mb/sekund til rådighed. Hvis hver bruger trækker 500 kilobyte på en forespørgsel, så er der ikke plads til mange samtidige brugere," siger Martin Born.
50 megabit/sekund svarer til 6.250 kilobyte/sekund.
Det giver plads til 12,5 samtidige brugerforespørgsler, hvis de trækker 500 kilobyte hver især. Da Azure-løsningen halverede datamængden, kunne man have 25 samtidige brugerforespørgsler per sekund.
Trafikinformations-systemets webside sender automatisk en ny forespørgsel hvert 30. sekund for at opdatere informationen på siden. Det betyder, at der i alt kunne være 750 åbne brugerbrugersessioner (se infoboks).
Der blev derfor ikke foretaget en fuld performance-test af demo-systemet.
"Decideret stress-test kræver ordentlig båndbredde. Der vil du have test-agenter på forskellige maskiner og en test-controller på en central maskine, der anvender test-agenterne til at skabe belastning. Hver test-agent skal have en båndbredde, der gør det muligt at emulere det antal brugere, du vil emulere. Vi viste princippet og værktøjerne i form af en Release Candidate af den nye Visual Studio 2010," siger Martin Born.
Potentielt scope-creep?
Projektteamet fik i ugens løb tid nok til at vise mulighederne i den nye arkitektur ved at bygge en prototype af Landets Puls, der kørte på Azure-platformen
"Vi lavede et ekstra servicelag om tog-positioner. Vi kunne lige så godt tage det med. Vi havde alle de data, som var nødvendige om tog-positioner. Det eneste, vi manglede, var GPS-positioner. Vi udstillede dem som en webservice og så byggede vi en lille browser-applikation i Silverlight, der bruger servicen. Det var en lille prototype af Landets Puls," forklarer Martin Born og uddyber:
"Vi har vist princippet i at bruge den service. Andre kan bruge den service; eksempelvis via en iPhone. Vores mål var at vise, at vi kan implementere trafikinformations-systemet på SQL Azure og det på en måde, så det er skalerbart og anvendeligt fra forskellige typer af applikationer. Et servicelag, der kan bruges direkte fra en klient, er med til at vise, at arkitekturen er den rigtige," siger Martin Born.
10 år gammel Java-applikation
Landets Puls er et omkring 10 år gammelt Java-baseret system. Den lille prototype, som projektteamet præsenterede, gjorde indtryk på Kenneth Lau Rentius og Michael Kvistholm.
De var begge meget tilfredse med, hvad de blev præsenteret for. Nu har de blot et positivt problem med at vurdere, om en ny version af Landets Puls skal indgå i et kommende projekt.
"Den samlede løsning for trafikinformations-systemet holder. Ingen tvivl om det. Når vi kommer til Landets Puls, er der noget arbejde der skal gå forud. Jeg kan være nervøs for, at lægge så meget ind i scopet, at jeg ødelægger en succes. Det ønsker jeg ikke. Der vil jeg hellere dele det op i nogle overskuelige klumper, som bliver implementeret og så få lavet en aftale om at vi kan vokse i løsningen," siger Kenneth Lau Rentius.
Han påpeger samtidig, at hvis Landets Puls skal med i løsningen, så er der lige pludselig nogle flere interessenter, der skal tages i ed.
"Vi skal have en dialog med kommunikationsafdelingen om hvilke informationer, der skal med i Landets Puls. Samtidig skal vi også forholde os forretningsmæssigt til, hvad der skal udstilles af data. Det skal være i overensstemmelse med de aftaler, vi har med vores kunder som DSB og Arriva. Når vi udstiller data, skal det være i tråd med de aftaler vi har med dem. Der er flere spillere i det felt," siger Kenneth Lau Rentius og tilføjer:
"Man kan hurtigt blive ivrig og finde nye muligheder. Inden man får set sig om, så har man lavet scope-creeping og så bliver det en uoverkommelig opgave, der ikke bliver en succes. Det er vitalt for Banedanmark, at løsningen giver driftssikkerhed og er stabil."
Tekniske muligheder afvejes med
Rent teknisk vil det være en god idé at flytte Landets Puls over på Azure-platformen. Det giver mulighed for at konsolidere database-anvendelsen i Banedanmark.
"Vores eksisterende trafikinformations-system trækker data fra en replikeret database, der står i DMZ'en. Når Trafikinformations-systemet lægges op i Azure, kan den replikerede løsning i princippet skæres væk, men i dag hænger Landets Puls også på den database," forklarer Michael Kvistholm.
Overvågning kræver mere arbejde
Det positive problem, om hvorvidt Landets Puls skal indgå i et kommende Azure-projekt, forventer Banedanmark at afklare i løbet af de næste par uger. Men allerede nu forventer Banedanmark, at sige go for en portering af Trafikinformations-systemet til Azure.
Kenneth Lau Rentius har tidligere sat 1. juli som forventet dato for, at trafikinformations-systemet kan gå i produktion på Azure, og den tidsplan er stadig realistisk.
"Som det ser ud nu, er juli stadig målet. Med det jeg så og de estimater, der er lagt for tidsforbrug på udvikling og andet, så er jeg stadig tryg ved, at den tidsplan holder," siger Kenneth Lau Rentius.
Skal han pege på et område, som ikke blev belyst helt tilfredsstillende af demo-systemet, er det selve overvågningen af systemet.
"Der var en ting, som overraskede mig en lille smule: Mulighederne for at overvåge løsningen. Det er min oplevelse, at der skal arbejdes lidt med det. Det kommer ikke out-of-the-box. Som jeg ser det, skal Microsoft arbejde lidt med den løsning, de stiller til rådighed.
Hvad skal der måles på, hvad skal være trigger for skalering, hvordan sendes information videre til vores nuværende overvågning. Der er stadig noget arbejde, der skal laves, så man er helt skarp på, hvordan det skal være. Det er ikke sådan, at jeg tror, det ikke kan lade sig gøre, det kan det. Det var bare ikke så klart for mig, som jeg havde forventet," siger Kenneth Lau Rentius.
Næsten samtidig med at projektteamet præsenterede deres demo-løsning, fremkom DBA'en Martin Schmidt fra Miracle AS og Mark S. Rasmussen fra iPaper med kritik af SQL Azures produktionsmodenhed.
DBA-Kritik af SQL Azure
DBA-kritikken af SQL Azure får ikke Banedanmark til at ryste på hånden.
"Umiddelbart har vi ingen problemer med det. Vi har ikke behov for at database-administrere. Det er data, der ryger ud, bliver brugt, og så er det i princippet væk igen. Det store behov for at trimme og tune en database har vi ikke i denne løsning," mener Kenneth Lau Rentius, der suppleres af it-udviklingschefen, Michael Kvistholm:
"Der vil ikke rigtig være nogen datavækst i løsningen. Den første gang, vi sender en fuldt replikeret datamængde ud, vil det i princippet være niveauet for datamængden. Hvis det er 270 tog, så er det 270 tog, der vil ligge derude. Det er ikke sådan, at data bare vokser, og der er behov for at rydde op engang imellem."
