Ved at køre alt i skyen har Public.com ikke en driftsafdeling i gængs forstand, men beror på Amazon i forhold til vedligehold, udskiftning og opgradering af hardware og software til serverne samt andre driftsopgaver. Foto: Magnus Møller
– Jeg ynder at sige, vi har en meget stor driftsafdeling med tusindvis af mennesker, der sidder i Seattle.
Sådan lyder det fra Tobias Tobiasen, der er CTO i virksomheden Public.com.
Prosabladet har mødt ham i virksomhedens nye udviklingsafdeling i Carlsberg Byen på Vesterbro i København til en snak om deres kompromisløse brug af containere og cloud i udviklings- og produktionsmiljøet.
Virksomheden faciliterer handel med værdipapirer og kryptovaluta på det amerikanske marked, og i den forbindelse har Public.com koblet en SoMe-dimension på handlen, hvor medlemmer kan følge og blive inspireret af hinanden. Siden Public.com startede for fire år siden, har stort set alt – bortset fra medarbejdernes laptops – kørt i skyen hos Amazon. Og det er dette setup, Tobias Tobiasen henviser til, når han taler om flere tusinde driftsfolk på den amerikanske vestkyst.
Ved at køre alt i skyen har Public.com nemlig ikke en driftsafdeling i gængs forstand, men beror på Amazon i forhold til vedligehold, udskiftning og opgradering af hardware og software til serverne samt andre driftsopgaver.
– Vi startede som cloud native. Det var et helt bevidst valg. Vi kører devops, hvor udviklerne også er ansvarlige for driftssystemet. Det kan lade sig gøre, fordi vi har så mange fully managed services, fortæller Tobias Tobiasen.
Vi kører devops, hvor udviklerne også er ansvarlige for driftssystemet
Devops lader sig blandt andet gøre, fordi udviklerne rent programmeringsmæssigt kan sætte eksempelvis en ny kø-struktur op i Amazons systemer uden først at skulle omkring en driftsafdeling.
Midt i al cloud-snakken spørger Prosabladets udsendte, om han ikke er nervøs for på den måde at deponere alle æggene i en kurv?
– Altså vendor-lock-in, lyder det opklarende fra Tobias Tobiasen.
Vendor-lock-in er situationen, hvor en virksomhed i så høj grad baserer sig på en anden virksomheds unikke tjenester og produkter, at det bliver svært – måske grænsende til det umulige – at skifte til en anden leverandør.
Det er dog ikke noget, der bekymrer Tobias Tobiasen synderligt.
Det er der to grunde til. Public.com gør i stor grad brug af containerteknologi – nærmere bestemt den fra Docker. Containerteknologi vil kort fortalt sige, at kode proppes i en beholder (container), hvor runtime-miljøet er specificeret og dermed kendt.
Det fungerer ifølge Tobias Tobiasen nogenlunde plug-and-play med Public.coms Docker-containere. Og samtidig ligger al forretningslogikken – altså det, der udgør Public.coms produkt – i containerne og altså ikke i et eller andet specifikt Amazon-miljø.
Så hvis virksomheden af en eller anden grund skulle få lyst til at flytte til en ikke-Amazon sky, ja, så burde det være en opgave, der kan løses ved at plugge containerne ind i et andet cloud-miljø.
– Det at køre dine Docker-containere on-premise eller i en anden sky kræver selvfølgelig noget arbejde, men det er ikke uoverstigeligt, siger Tobias Tobiasen.
Public.com anvender også services og databaser, som ligger hos Amazon og udgør miljøet, som containerne kører i. Eksempelvis bliver Public.com’s containere administreret via en tjeneste kaldet Elastic Container Service (ECS), som Amazon også står bag. ECS kan bruges til at starte, stoppe og skalere containere på tværs af et cluster.
Dermed kan Public.com med ECS opgradere og skalere op og ned i forhold til antallet af brugere. Det foregår konkret ved at skrue på antallet af Docker-instanser for en given tjeneste.
Sådan en fleksibilitet kan eksempelvis være smart, når man beskæftiger sig med aktiehandel. Nogle gange kommer der nemlig ekstra fart på handlen på en specifik aktie, og det betyder mange nye eller samtidige købere.
Det skete blandt andet hos Public.com i januar 2021, hvor prisen på aktierne bag computerspilsforretningen Gamestop skød voldsomt i vejret. En begivenhed, der ifølge flere medier primært tilskrives brugere af onlineforummet på /r/wallstreetbets/. Ved at kaste deres kollektive sparepengene ind i Gamestop pressede de aktiekursen så voldsomt op, at det skabte finansielle problemer for nogle af de store investeringsfonde, der omvendt havde shortet Gamestop-aktien i troen på, at den ville falde i værdi.
Det store fokus på Gamestop-aktier i starten af 2021 fik brugerne til at vælte ind på Public.coms investeringsplatform, og det gav en udfordring. De mange nye brugere betød nemlig, at de sms’er, virksomheden udsendte i forbindelse med tofaktor-autentifikation, ikke længere nåede ud til brugerne.
Det havde været en meget ubehagelig beslutning at skulle tage, hvis vi havde været nødt til at slukke vores system i fem minutter
Forklaringen var, at det ene nummer, som Public.com på daværende tidspunkt udsendte koder fra, blev blokeret af teleudbyderne, fordi der kom for mange sms’er fra nummeret. Public.com reagerede prompte ved at købe flere afsendernumre og sætte dem ind i koden, som blev rullet ud i live-miljøet i form af Docker-instanser.
– Her var vi jo glade for, vi rent faktisk kunne deploye i primetime. Det havde været en meget ubehagelig beslutning at skulle tage, hvis vi havde været nødt til at slukke vores system i fem minutter, siger Tobias Tobiasen.
Hvis Public.com skal nedtage systemerne helt, så folk ikke længere kan købe og sælge aktier, så kan det i sidste instans give problemer med det amerikanske finanstilsyn, forklarer Tobias Tobiasen.
Der findes andre systemer end Amazon ECS, der kan bruges til at jonglere med Docker-containere i en presset situation – eksempelvis Kubernetes.
I den forbindelse fortæller Tobias Tobiasen, at Public.com bevidst undgår visse, unikke Amazon-tjenester, hvor der ikke findes en pendant andetsteds. Netop for at undgå vendor-lock-in.
– Dem holder vi os ude fra, så hvis vi får lyst til at skifte nogle andre steder hen, så kan vi godt gøre det, siger Tobias Tobiasen.
Containere og Docker er ikke bare noget, Public.com anvender for at kunne skifte cloud-leverandør eller med skalering for øje. Det er også et spørgsmål om maintainability og forudsigelighed i forhold til driftsmiljøet.
Tobias Tobiasen kommer med en analogi med pets og cattle, altså kæledyr og kvæg, hvor pets henviser til den måde, softwaremiljøer var skruet sammen på i gamle dage. Det vil sige, hvor kode kørte direkte på en server. I helt gamle dage en fysisk server, lidt senere en virtuel.
– Det, man plejede at gøre, var, at man havde nogle servere, man loggede ind på, konfigurerede og lagde filer over på og så videre. I denne analogi er det pets. Det er nogle, man går og nurser om, og hver af dem har et bestemt navn, fortæller Tobias Tobiasen.
Netop fordi hver enkelt server skal passes og plejes individuelt, så kan der også ende med at være stor forskel på serverne. En server har måske fået installeret noget software eller en opdatering, som ikke lige er blevet installeret på en anden server og så fremdeles.
For eksempel kan der ende med at være forskel på det installerede styresystem, eller der kan være forskel på versionen af det installerede styresystem. Der kan også være forskel på versionen af installerede biblioteker (OpenSSL), og der kan selvfølgelig også være forskel på versionen af det installerede runtime – eksempelvis Java-versioner. Og så kan en udvikler stå med lidt af en udfordring, når kode, der kører på en server, skal bringes til at køre på en anden.
Det kan være i en hel almindelig situation, hvor en server udgør udviklingsmiljøet, mens en anden udgør produktionsmiljøet. Det er selvsagt vigtigt, at begge miljøer ligner hinanden, så kode, der kører under udvikling, faktisk også kører på produktions-serveren.
– Jeg kan love dig for, at der findes mange mennesker, som har haft de her pets, som så har deployet noget, og så virkede det ikke, fordi det underliggende system manglede en eller anden fil, eller måske var firewallen sat lidt anderledes op, siger Tobias Tobiasen.
Hvilket bringer os til det andet dyr i analogien – kvæg. De henviser til Docker-containere, og pointen med kvæg i denne sammenhæng er, at de alle er ens og har et nummer i stedet for et navn – og det er positivt i denne sammenhæng.
– Når du har de her Docker-images, så har du et forudsigeligt miljø til din applikation, så der er den rigtige version af Java og det rigtige SSL-bibliotek. Alting er der, siger Tobias Tobiasen.
Forklaringen er, at Java-versionen, SSL-biblioteket og alt muligt andet nu ligger i selve containeren, hvor programkoden også befinder sig. Det betyder også, at når Public.com og andre container-brugende virksomheder skal deploye kode i et kørende produktionsmiljø, så kan det ske uden alt for meget sved på panden, fordi testmiljøet og produktionsmiljøet ligner hinanden, da det hele ligger indkapslet i en container.
Ud over den indbyggede forudsigelighed og ensartethed, som containere kan tilbyde, så giver Docker også Public.com en enkelthed i forhold til, hvem der har foretaget sig hvad i koden.
– Vi arbejder med folks penge og identitet. Vi beder om personlig information, når folk signer op. Og vi skal vide, hvem folk er, ellers kommer finanstilsynet (i USA, red.) efter os, siger Tobias Tobiasen og fortsætter:
– Og det betyder, at vi bliver nødt til at vide, hvad der foregår i vores produktionsmiljø. Og her er audit trailet i Docker meget simpelt.
I udgangspunktet er det nemlig slet ikke muligt at logge ind i Public.coms produktionssystem, og det forenkler sporbarheden, når der ikke kan rodes med produktionsmiljøet, forklarer Tobias Tobiasen.
– Hvis du havde mulighed for at logge ind i produktionssystemet, så er det meget mere omstændeligt at lave et audit trail af, hvem der har gjort hvad, siger Tobias Tobiasen.
Vi har truffet et helt bevidst valg om at være cloud-native fra begyndelsen
At det ikke er nødvendigt at logge på produktionsmiljøet, hænger sammen med, at containerne hver især kommer med deres eget kørselsmiljø. Så der er altså ingen grund til lige at logge på produktionen og konfigurere eksempelvis et Java-miljø, da miljøet ligger i containeren sammen med koden.
Når Java er brugt som eksempel, skyldes det, at det er det primære sprog, der bliver brugt hos Public.com. Og det hænger blandt andet sammen med, at den knowhow, der findes inden for Public.coms forretningsområde, kender Java.
– Det talent, der er i Danmark, og som ved noget om penge og pengeflytninger, de kender Java og bruger formentlig Java i deres nuværende job, siger han.
Og når Public.coms primære udviklingsafdeling overhovedet ligger i Danmark, så hænger det ifølge Tobias Tobiasen sammen med, at Danmark er langt fremme, når det kommer til digitalisering af selvbetjeningsløsninger i banker.
– De mennesker, der har været med til at bygge de her selvbetjeningsløsninger, de går jo rundt på gaderne derude. Og dem skal vi have hjulpet til at forstå, at de skal arbejde her, siger han med et grin.
En af dem, der for nyligt har ladet sig overbevise om, at Public.com er det rette sted at være, er Anselmo Alves, der er medlem af PROSA. Han har siden oprettelsen af udviklingsafdelingen i Carlsberg Byen blandt andet arbejdet med udvikling af Java-kode til Public.coms containere.
– Jeg besluttede mig for at arbejde hos Public.com, fordi jeg tænkte, jeg ville vokse mere som udvikler, hvis jeg valgte et andet område efter at have tilbragt fire år ved mit foregående firma, forklarer Anselmo Alves.
Anselmo Alves fortæller, at han for øjeblikket beskæftiger sig med at integrere systemerne med en tredjepartsleverandør. Formålet er at forkorte den tid, det tager at lave en banktransaktion i USA.
Og også i forhold til den form for integrationer spiller Docker-containere en rolle. Tredjepartsleverandøren har nemlig leveret et Docker-image til test. Og det gør det muligt at teste op imod et miljø, der så godt som en-til-en ligner the real deal, men altså uden faktisk at være det. Og dermed uden risiko for, at noget for alvor går galt i forbindelse med test.
– Set fra et test-synspunkt, kan vi bygge vores test-suite og integration op mod markedsinstanser fra leverandørerne, fortæller Anselmo Alves.
Det er et fantastisk set-up
Han forklarer, at hvis Public.com ikke brugte Docker på denne måde i test-sammenhæng, ville udviklerne skulle nøjes med unit-test. Det vil sige test af enkelte kode-elementer i stedet for integrationstest, hvor kodeelementerne bliver testet samlet.
Alternativt ville det være nødvendigt at bygge og vedligeholde en mock-server til at simulere interaktioner med den rigtige tredjeparts-tjeneste.
Men det ville ifølge Anselmo Alves være tidskrævende at vedligeholde sådan en server, ligesom ændringer i serverens miljø vil kunne forårsage, at den ikke længere fungerede efter hensigten.
– Docker giver et fornuftigt lag af isolation. Det er et fantastisk set-up, siger han.
Hvordan er det nu lige med sammenhængen mellem containere, Docker og Kubernetes? Prosabladet har allieret sig med Zander Havgaard, der er devops-konsulent ved Eficode, for at besvare spørgsmålet.
Docker er navnet på en virksomhed, der har skabt værktøjer, som via kendte Linux-teknologier gør det relativt let at putte apps i containere. App-containere adskiller sig fra traditionelle virtuelle maskiner ved ikke at indeholde et komplet styresystem. Containere deles derimod om kernen i det underliggende host-styresystem. Det betyder, at containere er mere lightweight og hurtigere til at starte op end en virtuel maskine.
– Der er som sådan ikke noget nyt i containerteknologi. Det, Docker har gjort, er at gøre containerteknologier tilgængelige og nemme at bruge, uden at man er ekspert, forklarer Zander Havgaard.
Han fortæller, at softwarecontainere er smarte, fordi de løser tre svære problemer med at levere software: Dependency Management, Portability og Isolation.
Det er ofte også nødvendigt med et værktøj til at håndtere kørslen af containere, i hvert fald når setuppet involverer meget mere end en enkelt container og eksempelvis skal køre i et cluster. Den slags værktøjer hører under kategorien container-orkestrering. Her er Kubernetes et af de mest kendte. Andre er Docker Swarm og Docker Compose. Zander Havgaard forklarer, at værktøjerne spænder bredt i features og kompleksitet, og man skal selvfølgelig vælge det rigtige værktøj.
– For eksempel er Docker Compose fantastisk til at køre containere på en maskine som Raspberry Pi eller et lokalt udviklingsmiljø. Når man så har brug for at køre sine containere i produktion og gerne vil have redundans og skalering ved hjælp af replikering over flere maskiner, er det her Kubernetes kommer ind, siger han.
Zander Havgaard peger på, at Kubernetes også kan være overkill, hvis container-setuppet alene skal køre på en enkelt host. Men ved man, at man på et tidspunkt skal skalere op fra en enkelt host til et cloud-cluster, så anbefaler Zander Havgaard, at man starter med Kubernetes, fordi det gør opskaleringen lettere senere.
Dependency Management
Applikationer kan pakkes sammen med deres afhængigheder i et miljø, der er konfigureret til at køre applikationen. Det vil for eksempel sige, at Java-koden i containere kommer med den version af Java-runtime, koden er skrevet til. På den måde behøver man ikke stresse over, hvorvidt host-miljøet nu også understøtter ens app.
Portability
Docker-containere er et standard-interface, og det betyder, at kode pakket i en dockercontainer kan køre alle steder, hvor man kan afvikle containere. Containeren med appen kan altså uden for mange dikkedarer flyttes fra eksempelvis Amazons cloud-miljø til Googles.
Isolation
Kode i containere har i udgangspunktet ikke adgang til andet end deres eget miljø. Det giver sikkerhed, både hvad cyberangreb og driftsstabilitet angår. Skulle koden i en container for eksempel crashe, så hiver den ikke andre containere med sig i faldet. Der kan åbnes op for isolationen, så en container kan kommunikere med andre containere. Et setup, der blandt andet bruges i en microservice-arkitektur.
