Kontakta oss för en personlig FinMV offert skräddarsydd efter dina behov.
Den tekniska chefen för ditt företag måste, när du planerar lanseringen av en finansiell plattform, välja ett alternativ för projektarkitektur. Vilka arkitekturalternativ är tillgängliga för honom och vilken är bättre att välja?
En monolitisk arkitektur är som en snöboll. Du startar ett projekt och du har en liten snöboll. Den är så liten att den kan utvecklas och rullas av ett litet team. Ett par år går och nu har din snöboll blivit så stor att 20 utvecklare redan driver på den. Om ett par år till kommer hundratals utvecklare att rulla din snöboll med massor av kod, men lanseringen av nya funktioner kommer att bli väldigt långsam.
Som ett resultat börjar ägarna att byta teknisk chef, teammedlemmar, men det blir bara värre. Nya lagmedlemmar känner inte till de historiska detaljerna, varför snöbollen är som den är och inte en annan. Produktdokumentationen blir snabbt föråldrad.
Varför inte göra det rätt från början? För det första, i början av ett företag finns det alltid resurser är begränsade, det finns inte tillräckligt med utvecklare, expertis och tid. Manualen uppmanar, och programmerarna har bråttom att göra det på snabbast möjliga sätt.
För det andra tänker tekniska ingenjörer: "Tja, låt det vara en monolitisk arkitektur för tillfället, men när verksamheten växer, då gör vi om allting". Tyvärr kommer det i verkligheten att vara tiotals gånger svårare att överföra ett befintligt monolitiskt projekt till en mikrotjänstarkitektur än att skriva allt från början.
Vi kommer att göra din finansiella plattform omedelbart baserad på mikrotjänstarkitektur.
Mikrotjänstarkitektur kan jämföras med beläggningsplattor på gångvägar. När ditt projekt växer, läggs fler brickor till på din gångväg. Om en komponent är föråldrad räcker det att byta ut den här brickan med en ny.
Denna arkitektur har många fördelar, men jag kommer att nämna de viktigaste:
Första exemplet. Ledningen för en P2P-utlåningsplattform med ett stort antal användare bestämde sig för att gå in på marknaderna i länder med en annan valuta. Plattformen hade en monolitisk arkitektur och inkluderade endast en valuta - euron, och för att komma in på marknaderna i Sverige (svenska kronor), Polen (polska zloty), Tjeckien (tjeckiska kronan) var det nödvändigt att införa multivaluta.
Det tog månader för hela teamet att implementera denna funktionalitet, och utvecklingen av ny funktionalitet saktades ner ytterligare. I fallet med en mikrotjänstarkitektur skulle allt vara mycket enklare och snabbare.
Andra exemplet. Till en början lanserades webbplatsbyggaren på modersmålet och ledningen skulle inte expandera till andra marknader. Projektet hade en monolitisk arkitektur och funktionaliteten växte snabbt. Systemet för plattformen var en komplex webb där allt var kopplat till allt. En dag beslutade företaget att släppa en version av plattformen på andra språk. Först verkade det som att det skulle räcka att bara lägga till språkfiler och nu kommer vi att översätta hela gränssnittet.
I praktiken måste hela projektet göras om. Till exempel bör namnen på företag och produkter i databasen nu lagras inte bara på ett språk, utan på varje språk. Det var omöjligt att duplicera information på grund av affärslogiken, det var nödvändigt att lagra namnen för alla språk samtidigt. Följaktligen ledde detta till förändringar i gränssnitten för skåpet och backoffice. Gränssnittsändringar krävde att reglerna för validering av inkommande data, brevmallar på grund av olika principer för ändelser på olika språk, ändrade tester osv.
Eftersom allt var kopplat till allt togs beslutet att gå över till en mikrotjänstarkitektur tillsammans med lanseringen av nya språk. Övergångsprocessen från monolitisk till mikrotjänstarkitektur tog mer än ett år.
Tredje exemplet. Fintech-plattformen gjordes på en gammal version av PHP och Laravel. Att uppgradera till nyare versioner, såväl som att ändra databasen från MariaDB till PostgreSQL, var praktiskt taget omöjligt, eftersom hela teamet bara fick hantera migreringsprocessen i flera månader.
Nya versioner av PHP och Laravel vid den tiden kunde påskynda projektet och vidareutvecklingen, men den monolitiska arkitekturen tillät inte uppdatering av teknikstacken
.
