Interview med Senior Developer Thomas Brask Jørgensen
Næsten 15 års erfaring med NoSQL- og NoSQL-lignende databaser har givet Senior Developer Thomas Brask Jørgensen en dyb indsigt i arbejdet med de nye, fremadstormende databaseteknologier. Her fortæller han om sine oplevelser og deler samtidig gode råd ud til både virksomheder og kolleger.
Senior Developer Thomas Brask Jørgensen har både alderen og erfaringen til at have arbejdet med NoSQL-databaser, før de overhovedet blev kaldt NoSQL. Det var tilbage i 2000, hvor han blev koblet på Jubiis community-afdeling med ansvaret for chat-platformen. Det var i de tidlige web 2.0-tider, hvor danske brugere så småt var begyndt at få øjnene op for den offentlige instant messaging-dialog med andre brugere om alle typer af emner. Thomas Brask Jørgensen husker det som en sjov opgave, men også en opgave, der helt fra begyndelsen af præsenterede udviklerne for en række helt nye udfordringer.
“Dengang, jeg startede, var Jubii Chat et relativt lille, dansk produkt, men man kunne godt se, at det havde et stort potentiale. Dertil kom, at Jubii blev opkøbt af Lycos, og de havde ambitioner om, at produktet skulle ud i hele Europa, og så snakkede vi lige pludselig en helt anden størrelse brugerbase. Dengang brugte man ASP og SQL Server til chatten, så man kunne godt regne ud, at man ville løbe ind i problemer i forhold til skalerbarhed. Det var slet ikke hurtigt nok, og det ville blive sindssygt dyrt, hvis man skulle løse problemet med den eksisterende teknologi,” forklarer Thomas Brask Jørgensen.
“Så man valgte i stedet at lave sin egen database. Vi havde en udvikler siddende i syv år, som stort set ikke lavede andet end at udvikle på den database. Det endte faktisk med at blive et rigtig godt produkt, som stadig findes på markedet. I dag har databasen fuld SQL, men det havde den ikke dengang. Det var ren NoSQL. Udelukkende fordi det skulle kunne skalere ud over flere servere og gå så hurtigt som overhovedet muligt.”
Selv den dag i dag mener Thomas Brask Jørgensen, at det var den rigtigt beslutning at bygge sin egen database til at løse udfordringen. Men da man besluttede at bruge databasen til andre typer af opgaver i Lycos, opstod der problemer.
“Man flyttede simpelthen hele community-produkter over på platformen og udviklede også nye produkter, som brugte samme database. Det resulterede i, at vi oplevede crash engang imellem, hvor det hele røg ned, og så måtte vores tekniker sidde i halvandet døgn og genoprette systemet. Nedetid gør måske ikke så meget, når det bare er en chat og gæstebøger, men det endte alligevel med at koste i kroner og øre. For chatten levede af reklameannoncer, og når chatten var nede, kunne brugerne ikke se nogle annoncer,” fortæller han.
Online backgammon og ZYB
Da Lycos i 2005 valgte at flytte hele afdelingen til Tyskland, flyttede Thomas Brask Jørgensen ikke med. Han var stadig chefkonsulent på back-enden i et stykke tid, men foretrak at arbejde fra dansk grund.
Næste gang, han arbejdede med NoSQL-databaser, var i 2006, da han blev hyret til et projekt for en mindre dansk iværksættervirksomhed, der ville lave onlinespil. På det tidspunkt havde danskerne – med storspilleren Gus Hansen som forbillede – for alvor taget poker, onlinepoker og andre spil på nettet til sig.
“Jeg blev spurgt, om jeg ville lave back-enden til et online-backgammonspil, og det sagde jeg ja til. Vi brugte bl.a. en database, der hedder Memcached, og som er en NoSQL-lignende database, til spil og chat-funktionalitet. Det var den fin til, men det var lidt af et problem, at virksomheden også ville anvende den til de finansielle transaktioner. Der er nogle problemer med consistency og concurrency, der gør, at man ikke skal bruge NoSQL til finansielle transaktioner; der skal man bruge transaktionelle databaser,” siger Thomas Brask Jørgensen og tilføjer, at det lille iværksætterfirma aldrig nåede i luften med deres onlinespil, men lukkede projektet ned før tid.
“I 2008 kom jeg til ZYB, som var en backup-løsning til mobilen. Før jeg kom til, var ZYB blevet opkøbt af Vodafone. Vodafone havde dengang ambitioner om at opbygge et stort community. Min opgave var bl.a. at arbejde med et proof of concept på en ny version af ZYB-løsningen, og i den forbindelse kiggede vi også på NoSQL-databaser, bl.a. MongoDB og Amazons SimpleDB,” siger Thomas Brask Jørgensen og forklarer, at udviklerne arbejdede på én samlet løsning, hvor MongoDB, SimpleDB og andre databaser var “pakket ind” i et abstraktionslag, så man ikke kunne se, hvilke databaser der kørte nedenunder. Det var ikke en pakkeløsning, de ville vælge i et brugsscenario; det var udelukkende et eksperiment, der skulle teste de forskellige databasers egnethed til opgaven op imod hinanden.
“Desværre blev ZYB til sidst lukket ned, så vi nåede aldrig i land med projektet, men det var super spændende at arbejde på. Set i bakspejlet begik vi nok en fejl, da vi forsøgte at bygge et generisk SQL-interface oven på NoSQL-databaserne. Vi tog en NoSQL-database og forsøgte at lave den om til SQL. Det skulle vi nok ikke have gjort. Man kan godt få et query-sprog på den måde, men sådan noget som consistency og atomiske transaktioner, det får man ikke,” siger Thomas Brask Jørgensen og forklarer, at ønsket om SQL og query-muligheder opstod, fordi man ville bruge pakkeløsningen til dataanalyse med business intelligence- værktøjer, data mining osv.
“Men det var ikke den rigtige måde at gøre det på. Det rigtige havde nok været at flytte data og analysere på dem et andet sted, hvor man ville have haft mere avancerede query-muligheder. Den form for funktionalitet får man ikke i en NoSQL-database.”
Færdig i går
I 2012 blev Thomas Brask Jørgensen hentet ind til Atea Tele-projektet, hvor Atea gik ind på erhvervstelefonimarkedet. Da Thomas Brask Jørgensen sammen med andre konsulenter blev hentet ind, skulle projektet – som altid – have været færdigt “i går”, som han siger med et smil på læben. “Det er jo det, vi konsulenter lever af.” Atea ønskede telerating-funktionalitet – og muligheden for split billing, så brugeren og ikke mindst virksomheden kunne adskille arbejdskald fra privatkald. Oprindeligt havde Atea ønsket at foretage denne rating selv, hvilket ville betyde millioner af registreringer, hver gang der blev foretaget et opkald eller sendt en sms. Atea havde regnet på det, og den opgave passede ikke til Microsoft SQL, som de selv havde kompetencer på. Så de valgte at bruge RavenDB, som er en meget .NET-friendly NoSQL-database.
“Et åbenlyst valg, hvis det var den vej, man ville,” siger Thomas Brask Jørgensen. “Problemet var, at før vi blev hentet ind, havde man besluttet sig for, at de alligevel ikke selv skulle lave telerating. De skulle kun have en brugerdatabase med profiler, opsætning osv. Det betød en standarddatabase med ikke ret mange data, og de data, der var, ville passe godt ind i en relationel database, hvor man bl.a. kunne lave avancerede querys. Opgaven passede ikke særligt godt til RavenDB, som de havde beholdt på trods af, at de havde droppet at lave telerating. Efter et halvt år på opgaven argumenterede vi for at få RavenDB ud og en relationel database ind, og det var også sådan, det endte.”
I dag sidder Thomas Brask Jørgensen hos Saxo Bank, hvor han er ved at færdiggøre en Open API-opgave der gør det lettere for eksterne virksomheders bankapplikationer at fungere sammen med Saxo Banks interne systemer.
“Vores system registrerer store mængder logdata. Indtil videre har vi brugt logfiler, men ønsker at få det over i en database. Her vil en NoSQL-database som f.eks. MongoDB være et godt valg, pga. den store mængde af data og de relativt beskedne krav til opslag. Saxo Bank bruger i forvejen MongoDB i andre sammenhænge, så det er et oplagt valg,” siger Thomas Brask Jørgensen.
Lyt til os!
Når Thomas Brask Jørgensen i dag kommer ud på en opgave, hvor NoSQL-teknologi er på tale, oplever han oftest, at han bliver spurgt til råds, fordi han kommer med mange års erfaring på området. Og sådan skal det ifølge ham også være.
“Min erfaring er, at i 9 ud af 10 tilfælde lytter kunderne til os konsulenter, fordi vi har set lignende opgaver før. Det er meget sjældent, man får at vide, at man bare skal gøre sådan og sådan. Det oplever man dog engang imellem. Jeg har også prøvet det i et tilfælde, hvor valget stod mellem relationelle databaser og NoSQL-databaser. Men jeg plejer nu altid at sige min mening, hvis folk er på vej ud over en skrænt med deres løsninger,” siger Thomas Brask Jørgensen og understreger, at det bedste råd, han kan give virksomheder, der står over for et databaseprojekt, er at tænke sit IT-miljø og fremtidige behov meget grundigt igennem, inden de træffer de teknologiske valg.
“Det skal være det rigtige værktøj til den rigtige opgave. Det der med at skifte undervejs er smertefuldt. I en ideel verden skal man gå efter databasernes tekniske features. Men virkeligheden er nok, at folk ender med at vælge det produkt, de kender,” siger han.
Hvis Thomas Brask Jørgensen skal komme med et godt råd til de kolleger, der endnu ikke selv har stiftet bekendtskab med NoSQL-databaser, så skal de først og fremmest danne sig et overblik over myriaden af NoSQL og NoSQL-lignende teknologier.
“Der findes jo flere end 100 NoSQL-databaser på markedet. Derfor handler det i høj grad om at kunne kende forskel på de forskellige typer af databaser og ikke tro, at NoSQL bare er én ting. For det er det absolut ikke. Helt konkret vil jeg anbefale, at man kigger på RavenDB og MongoDB, hvis man har en Microsoft-baggrund. Er man web-orienteret, kan man kigge på CouchDB. Og hvis man har mulighed for cloud, kan man kigge på Microsofts Azure-platform, Amazons SimpleDB eller Google Cloud Datastore,” siger Thomas Brask Jørgensen.
Deklarativt vs. imperativt
Der er enorm forskel på at arbejde med relationelle databaser, der bygger på mere end 20 års akkumuleret viden, velafprøvede teknologier og en bred pallette af tools, og på at arbejde med de nyere og umodne NoSQL-databaser. Personligt kan Thomas Brask Jørgensen dog godt lide den udfordring, der ligger i NoSQL-teknologierne.
“At arbejde med NoSQL er lidt cowboy-agtigt. Man føler, at man er ude i et stykke pionerarbejde hver gang, fordi man ikke har den samme store værktøjskasse til rådighed, som man har, når man arbejder med relationelle databaser. Med NoSQL skal man selv gøre meget af arbejdet. Man kan godt lave nogle af de samme querys som i en relationel database, men man skal selv skrive det. De fleste NoSQL-databaser har ikke deklarative query-muligheder som SQL, hvor man skriver, hvad man vil have, og hvordan det skal præsenteres. NoSQL-databaser er oftest imperative. Her beskriver man, hvordan data skal findes frem. Det er som at skrive et program. Først gør det her, så gør det her, så gør det her osv. Det er en helt anden tankegang,” afslutter Thomas Brask Jørgensen.
