Kontakt os for et personligt FinMV-tilbud, der er skræddersyet til dine behov.
Den tekniske direktør for din virksomhed skal, når den planlægger lanceringen af en finansiel platform, vælge en projektarkitektur. Hvilke arkitekturmuligheder er tilgængelige for ham, og hvilken er bedre at vælge?
En monolitisk arkitektur er som en snebold. Du starter et projekt, og du har en lille snebold. Den er så lille, at den kan udvikles og rulles af et lille hold. Der går et par år, og nu er din snebold blevet så stor, at 20 udviklere allerede presser på den. Om et par år mere vil hundrede af udviklere rulle din snebold med et væld af kode, men lanceringen af nye funktioner vil blive meget langsom.
Som et resultat begynder ejerne at skifte teknisk direktør, teammedlemmer, men det bliver kun værre. Nye teammedlemmer kender ikke de historiske detaljer, hvorfor snebolden er, som den er, og ikke en anden. Produktdokumentation bliver hurtigt forældet.
Hvorfor ikke gøre det lige fra starten? For det første er der i begyndelsen af en virksomhed altid ressourcer er begrænsede, der er ikke nok udviklere, ekspertise og tid. Manualen opfordrer, og programmørerne har travlt med at gøre det på den hurtigst mulige måde.
For det andet tænker tekniske ingeniører: "Nå, lad det være en monolitisk arkitektur for nu, men når virksomheden vokser, så vil vi lave alt om". Desværre vil det i virkeligheden være ti gange sværere at overføre et eksisterende monolitisk projekt til en mikroservicearkitektur end at skrive alt fra bunden.
Vi vil gøre din finansielle platform med det samme baseret på mikroservicearkitektur.
Mikroservicearkitektur kan sammenlignes med belægningsplader på gangstier. Efterhånden som dit projekt vokser, føjes flere fliser til din gangbro. Hvis en komponent er forældet, er det nok at erstatte denne flise med en ny.
Denne arkitektur har mange fordele, men jeg vil nævne de vigtigste:
Første eksempel. Ledelsen af en P2P-udlånsplatform med et stort antal brugere besluttede at gå ind på markederne i lande med en anden valuta. Platformen havde en monolitisk arkitektur og omfattede kun én valuta - euroen, og for at komme ind på markederne i Sverige (svenske kroner), Polen (polske zloty), Tjekkiet (tjekkisk krone) var det nødvendigt at indføre multivaluta.
Det tog måneder for hele teamet at implementere denne funktionalitet, og udviklingen af ny funktionalitet bremsede endnu mere. I tilfælde af en mikroservicearkitektur ville alt være meget nemmere og hurtigere.
Andet eksempel. Oprindeligt blev webstedsbyggeren lanceret på modersmålet, og ledelsen ville ikke udvide til andre markeder. Projektet havde en monolitisk arkitektur, og funktionaliteten voksede hurtigt. Platformens skema var et komplekst web, hvor alt var forbundet med alt. En dag besluttede virksomheden at frigive en version af platformen på andre sprog. Først så det ud til, at det ville være nok kun at tilføje sprogfiler, og nu vil vi have hele grænsefladen oversat.
I praksis skulle hele projektet laves om. For eksempel bør navnene på virksomheder og produkter i databasen nu gemmes ikke kun på ét sprog, men på hvert sprog. Det var umuligt at duplikere information på grund af forretningslogikken, det var nødvendigt at gemme navnene for alle sprog på én gang. Dette førte derfor til ændringer i grænsefladen i kabinettet og backoffice. Ændringer i grænsefladen krævede ændring af reglerne for validering af indgående data, brevskabeloner på grund af forskellige principper for slutninger på forskellige sprog, ændring af prøver osv.
Da alt var forbundet med alting, blev beslutningen taget om at flytte til en mikroservicearkitektur sammen med lanceringen af nye sprog. Processen med overgangen fra monolitisk til mikroservicearkitektur tog mere end et år.
Tredje eksempel. Fintech-platformen blev lavet på en gammel version af PHP og Laravel. Opgradering til nyere versioner samt ændring af databasen fra MariaDB til PostgreSQL var praktisk talt umulig, da hele teamet kun skulle håndtere migreringsprocessen i flere måneder.
Nye versioner af PHP og Laravel på det tidspunkt kunne fremskynde projektet og videreudviklingen, men den monolitiske arkitektur tillod ikke opdatering af teknologistakken
.
