Du har använt dig utav Docker förut inom företaget?
Ja, jag använder Docker för att få en utvecklingsmiljö för vår databas. Just för att det är ett problem som jag har haft många andra problem, så när jag sätter upp en Oracle insats så är det jobbigt, kostar pengar och sätter man upp en databas någonstans så vill Oracle ha betalt.
Licensen är så att om man använder den för personlig utveckling så kan man bara ladda ner den, så det var ett väldigt bra use case för Docker och Oracle själva har laddat upp en version för Docker, så då kunde jag använda den konfigurationen som de lagt upp.
Det är just jättebra att kunna ha en lokal utvecklarversion så att säga, det är det jag använder det till. Om det blir något konfigurations problem eller om man har en missat något, så är det bara att ta bort allt och så köra allt igen, så installeras allt om igen som en bas.
Vad var det som fick dig att välja Docker jämfört med andra?
De är största på marknaden och just den här färdiga konfigurationen uppe också. De hade ju också kunnat haft någon Vagrant konfiguration, som det finns VirtualBox versioner av också, men allt blir ju mycket tyngre. Allt blir lätt viktigare med Docker känns det som. Plus att jag har också konfigurerat Flyway vilket gör att man har koll på vad som är installerat i databasen.
Gör man konfigurationer med Flyway skrift så får man en slags versionshantering utav dess kod. Så då kan jag integrerat det med en Flyway Docker instans också. Då kollar den om databasen har den senaste versionen, har den inte den så uppdaterar den versionen i databasen. Vilket gör det jätteskönt, då man innan inte kunde veta riktigt vad som var installerat på databasen, vilken gör så att om man följer processen så har man koll på vad som gjorts. Detta går ju också att göra utan Docker, men Docker gjorde det lättare då man kunde köra dessa två olika instanser. Så då kan man bara ladda ner Docker avbilden och sen automatiskt använda sig utav Flyway för att kontrollera att versionen den senaste.
Jag var även inne på att använda Kubernetes där med Flyway och Docker, men det övergav jag då jag inte kände att det kändes riktigt nödvändigt i det här fallet. Det gör att man blir lite mer avslappnad då man vet att det man har på live miljön har man kört själv på
utvecklingsmiljön.
Har du märkt några nackdelar med det här systemet?
Det man gärna hade velat gjort är att köra hela proceduren med Docker hela vägen ut, så att man bara kunde pusha ut de man gjort när man är klar. Men det går inte riktigt här då det är mycket som fortfarande är beroende utav hårdvaran under, för en databas. Jag har ju läst lite om det där, det verkar vara svårt för Docker att ha disk systemet under som utvecklas i samma takt. Om man har Docker images så vet man inte riktigt vad som finns under. Just databasmiljöer är väldigt beroende utav att ha bra tillgång till diskaccess. Den leverantören ser till att man inte har noisy neighbors, i moln är det lätt hänt att om man tar den billigaste, så delar man med flera andra men sen så när man skalar så kanske det är en spik precis då, och då kan det ta ett tag innan man får det man sökte om. Men det är många som erbjuder bare-metal, dvs man erbjuder direkt hårdvara. Det är sånt man måste tänka på då databasen är en trottel. Det är många som med Kubernetes just sätter upp allt förutom databasen. Det går ju med DB också, men jag är osäker på om det är riktigt moget där än att använda det. Så vi använder det endast lokalt för utvecklingsmiljön. Det hade ju varit kul och tagit miljön, för drömmen vore, att ha exakt samma produktionsmiljö som utvecklar så man bara kan pusha de direkt. Men där känner jag inte att Docker är riktigt än.
När tycker du är det ideala scenariot att använda virtuella maskiner?
Det är ju just det att jag var ju osäker när ni frågade tidigare om vi hade virtuella maskiner idag. Grejen med virtuella maskiner är ju att man inte riktigt man har de. Som vi har det idag
så loggar vi ju in som vanligt, och då märker man inte riktigt om det är virtuella maskiner eller om det är fysiska servrar. Det är ju det som är bra med VMs, med Docker märker man ju att man använder de. Det som är den stora skillnaden, med Docker så sitter man inte och hackar direkt i miljön, utan det bygger ju på att skriva dessa Dockerfiles som sätter upp hela miljön.
Så det är ju ett helt annat sätt att jobba, på virtuella maskiner så sitter man ju och konfigurerar som på en vanlig maskin, det är en mer komplett miljö. Mer likt hur man brukar göra.
När ni valde de deployment techniques som ni har, vad för faktorer ni tänkte på?
Vi är ju så pass små, så att det här med Docker kunde jag ju bara välja att använda själv. Vi har ju vissa grejer i Amazon, så vår front-end som samlar in vad folk klickar på och så, den går ju via Amazon. Där är fördelen att det är geografiskt spritt, så vi har vår front-end cache runt om hela världen så att folk kan vara var som helst när de klickar utan att märka någon skillnad. Det är just vår back-end som vi har hos Evry, i Kista. Vi hade planer för några år sen att lokalisera ut delar av vår back-end till Amazon också, men det blev inte riktigt av då vi valde mer att fokusera på vår core business som är här i Europa. Det är ju mer komplext med en global back-end, för det man vill undvika är ju att det finns olika versioner av sanningen.
För de finns ju en del bolag där de haft problem med att folk ser olika versioner utav data.
Men i fall som företag som Twitter och liknande så spelar det ju ingen större roll om folk ser exakt samma sak samtidigt eller om någon kanske får ett tweet någon sekund senare. Men i fallet för oss om folk så skulle se olika siffror i back-end:en är ju inte bra, för de har ju hand om betalningar och liknande. Där vill man att allt ska ske samtidigt. I ett globaliserings scenario blir det svårare att lösa. Det finns arkitekturer där man skriver till en centraliserad databas och sen replikerar ut till flera andra databaser, så att man har en master som replikerar ut data till de andra, via något replikerings verktyg och sen om man behöver någon omvandling så kan man ha en transportprocess som gör det. Men allt det där måste ju göras och det är ju dyr. Så vi ändrade strategi då att fokusera på vår centrala core business här i Europa istället. Docker osv är ju jättekul men det är ju en startupprocess, och det händer ju saker där hela tiden just nu. Ändå ganska mycket som var instabila som man inte ville gå ut i produktion med. Som utvecklare så är det ju jättekul att testa, men som driftare känns det skönt att veta att man har stabilitet.
Känner du att det är något som kan bli bättre med tiden?
Ja absolut det är ju en mognadsprocess i alla produkter. Det som är skönt när man vet att det är stora företag bakom, när en open sourceprodukt backas upp av stora spelare som Google, Facebook m.fl., det blir det en helt annan trygghet. Då man vet att det finns stora spelare som har intresse utav att hålla produkten vid liv, se till att den mognar och som lägger ner de resurser som behövs. Risken annars med många open sourceprojekt är att det sitter en eldsjäl som driver projektet framåt. Sen när den slutar för att den inte orkar eller vill göra något annat, för det är ju oftast gratis arbete, så sitter man där med en produkt som inte utvecklas längre. Så kommer något säkerhetshål och det är ingen som patchar produkten, så då måste man själv fixa det, vilket kan bli lite mycket om man har ett annat jobb själv. Med en produkt som har support och liknande så blir det oftast inte alls samma bekymmer. Det är därför det oftast är sådana här open sourceprojekt som backas upp av de stora spelarna.
T.ex. React och Angular, då de är dessa stora företag bakom, så blir det de som folk vågar satsa på och därmed blir de mest populära. Så det är ju lite samma med Docker, så det är ju väldigt väl känt nu. Men nu känns det som det har börjat nått en ganska mogen nivå, för bara några år sedan så funkade inte grejor riktigt som man förväntade sig och var lite buggigt. Men nu så verkar det mesta funka bra.
Hur tycker du att deployment delen utav era projekt påverkar det som ni gör?
Det blir ju mer och mer tid som går åt till DevOps och liknande. Sätta upp Jenkins och sätta upp våra automatiska tester. Det är ju väldigt bra för att det gör produkten mer stabil, men det
gör ju även så att mer tid går åt till underhåll. När man gör något nytt så kanske testerna blir utdaterade och då måste man utveckla nya och liknande. I slutändan så tjänar man ändå tid, tror jag, men det finns ju nackdelar med allt. Men förhoppningsvis så leder det till en bättre slutprodukt. Det är ju väldigt bra om någon checkar in någonting och helt plötsligt så kraschar bygget direkt, och man kan lätt åtgärda. På vissa företag jag jobbat tidigare så är det någon sån där kod apa som passerat och helt plötsligt så kraschar allt senare och det är ganska svårt att veta vad som hänt. Ju tidigare man upptäcker felen, desto billigare blir det för alla.
Som utvecklare så blir man ju mer och mer inblandad i de här som varit på driftsidan tidigare.
Där det tidigare var så att driftpersonerna kanske var lite utanför ens egen process så man visste inte vad de gjorde riktigt, utan det verkade vara ganska komplext. Men nuförtiden så kan man sätta upp en driftmiljö själv, så utvecklarna får mer koll på driftmiljön och
driftpersonerna mer på själva bryggan eller produkten. Vi har ingen egen driftgrupp här utan det är Evry som har våra servrar som sköter den biten. Men på tidigare jobb så hade man kommit väldigt långt med DevOps, så där var det automatiserat nästan hela vägen ut till produktion, förutom att man hade en review innan det gick ut. Men jag tyckte även att konfigurations verktygen är väldigt bra, men även där är det ju skript som måste underhållas.
Det låter ju magiskt med DevOps där allt bara rullas ut men allt det måste ju också skapas och underhållas. Man uppdaterar någon miljö och så pajar något skript som man måste fixa osv.
Hur känner du inför att utvecklare själva börjar ta en större del i driftprocessen?
Jag tycker att det är bra för att det ökar helhets förståelsen för miljön, det ger också större trygghet om man har skript och liknande att andelen manuella misstag blir färre. Som när jag använder Flyway så kan jag ändå känna trygghet i att det här jag har gjort kommer funka även i produktionsmiljön då det är exakt samma som det jag testat i testmiljön och det är inget som kommer emellan. Det gör ändå att man känner en helt annan trygghet än tidigare då man kunde oroa sig för om det var en annorlunda konfiguration eller liknande. Det är främst det jag tycker de här DevOps verktygen gör, att det gör att allt blir mer konsekvent så att man kan vara mer säker på att det är samma procedur som tillämpas varje gång, så att den sortens misstag minskar.
Ser du några nackdelar med att utvecklarna tar med ansvar med DevOps?
Underhållsbiten nämnde jag tidigare, det blir mer underhåll och mer tid som går till det. Man kan ju sitta och scripta upp allting men det tar ju tid att skriva alla skript och sen ska de underhållas. Så slutar personen som skrivit skripten, så “jaha vad gjorde det här?” så är det ingen som vet. Men o andra sidan så innan DevOps var ett begrepp, så var det ju så att om någon utav driftpersonerna blev sjuka eller slutade så var det ingen som hade någon aning om vad som gjordes. Men görs det med DevOps skript så blir det lite mer öppet vilket är positivt såklart. Det gäller också att inte glömma bort hårdvaran när man håller på med DevOps, det är något som annars är väldigt lätt att glömma. Det är ju ändå den tillslut som ska göra allt jobbet och då gäller det att komma ihåg den. DevOps är så pass mjukvara fokuserat att det kan vara lätt att glömma den delen. Sen är det lätt att “hypen” blir för stor med DevOps så man sitter och utvecklar massor med nya saker hela tiden och fokuserar inte på att få en mogen produkt. Så blir det någon drift-stackare som får sitta där sen och fixa alla buggar och liknande. Så det gäller att ha en klar strategi när man börjar utveckla, så att man sen väl är redo när man kommer till driften, även om den inte alltid är lika sexig och rolig att prata om på konferenser och liknande. Då det ändå är driften som sker dagligen hela tiden.
Vilken teknik föredrar du?
Jo Docker var ju väldigt rolig med att man får en redo miljö direkt. När man själv sitter hemma och ska installera Oracle DB t.ex. så känner man sig trött redan innan man börjar med alla
installations skärmar och konfigurationer. Med Docker så är det bara att hämta direkt, vilken för mig iallafall är en revolution. Drömmen med Docker och Kubernetes är ju att man bara kan utveckla det och sen bara ta hela paketet och lägga ut där man vill ha det direkt. Allt sådant har känts väldigt krångligt tidigare, men det känns lättare nu. I alla fall i drömmen, vi har ju inte riktigt det här än.
Hur lång tid brukar era processer ta när ni har bestämt er för att byta teknik(er)?
Jag började här för 1,5 år sen, och då såg jag möjligheten att använda Flyway för att få ut releaser mer pålitligt mm, traditionellt annars så har det ju varit skript och då är det lätt med misstag där man skrivit något fel, kopierat en extra fil eller bara testat i någon annan miljö etc.
etc. Att få in det i den här processen är fortfarande inte riktigt klart, det har varit något man har tagit in steg för steg. Så nu har vi så att vi kör alla våra releaser med det här migrations verktyget, Flyway. Men vi har ju fortfarande inte uppdaterat alla våra procedurer i Git, vilken Flyway hämtar ifrån. Nackdelen med databas procedurer är att det är så himla lätt, man ser källkoden i databasen, och sen är det bara att trycka compile och så kan man göra det på en gång. Så att när jag började så var koden som fanns i Git inte pålitlig helt enkelt, utan man fick hämta koden direkt ifrån produktionsdatabasen istället, för annars fanns det en jätterisk att man kanske skrev över någonting. Det känns mycket tryggare nu med vårt
produktionsverktyg är att jag vet att det som finns i Git, det är det som gäller. Det blir en process på ett annat sätt som gör att det blir lättare att inte göra misstag. Men då gäller det också att man håller på de här processerna, annars är man ju tillbaka där man började eller ännu värre. Så nu när någon ny börjar så måste man lära de alla de här nya reglerna. Det bästa är helt enkelt att man bestämmer sig för någonting och sen följer det. Så ska man köra DevOps eller liknande så gäller det att man följer den process man hittar på, annars kan det göra mer skada än gott.
Hur stor del tycker du att du haft när ni bestämmer er för dessa tekniker?
Just de här databasbitarna har jag haft stor del, vi är ju bara ett team på två personer så det har ju blivit lätt då. I de andra teamen däremot har jag inte varit särskilt inblandad alls.
Något du vill nämna innan vi avslutar?
Överlag så känns det som en mycket bättre värld, att ha alla de här verktygen tillgängliga. Så jag tycker det mesta bättre, och jag vill inte tillbaka till hur det var tidigare.
TRITA EECS-EX-2018:130