Neem contact met ons op voor een gepersonaliseerde FinMV-offerte op maat van uw behoeften.
De technisch directeur van uw bedrijf zal bij het plannen van de lancering van een financieel platform een projectarchitectuuroptie moeten kiezen. Welke architectuuropties zijn voor hem beschikbaar en welke kan hij beter kiezen?
Een monolithische architectuur is als een sneeuwbal. Je start een project en je hebt een kleine sneeuwbal. Het is zo klein dat het door een klein team kan worden ontwikkeld en gerold. Er gaan een paar jaar voorbij en nu is je sneeuwbal zo groot geworden dat 20 ontwikkelaars er al mee bezig zijn. Over een paar jaar zullen honderden ontwikkelaars uw sneeuwbal rollen met een hoop code, maar de lancering van nieuwe functies zal erg traag verlopen.
Als gevolg hiervan beginnen de eigenaren de technisch directeur, teamleden te veranderen, maar het wordt alleen maar erger. Nieuwe teamleden kennen de historische details niet, waarom de sneeuwbal is zoals hij is en niet een andere. Productdocumentatie raakt snel verouderd.
Waarom zou je het niet meteen vanaf het begin doen? Ten eerste zijn er aan het begin van een bedrijf altijd middelen zijn beperkt, er zijn niet genoeg ontwikkelaars, expertise en tijd. De handleiding dringt aan en de programmeurs hebben haast om het op de snelst mogelijke manier te doen.
Ten tweede denken technische ingenieurs: "Nou, laat het voorlopig een monolithische architectuur zijn, maar als het bedrijf groeit, zullen we alles opnieuw doen". Helaas is het in werkelijkheid om een bestaand monolithisch project over te zetten naar een microservice-architectuur tientallen keer moeilijker dan alles helemaal opnieuw te schrijven.
We maken uw financieel platform onmiddellijk gebaseerd op microservice-architectuur.
Microservice-architectuur kan worden vergeleken met straatstenen op voetpaden. Naarmate je project groeit, worden er meer tegels aan je loopbrug toegevoegd. Als een onderdeel verouderd is, volstaat het om deze tegel te vervangen door een nieuwe.
Deze architectuur heeft veel voordelen, maar ik zal de belangrijkste noemen:
Eerste voorbeeld. Het management van een P2P-leenplatform met een groot aantal gebruikers besloot de markten te betreden van landen met een andere valuta. Het platform had een monolithische architectuur en omvatte slechts één valuta - de euro, en om de markten van Zweden (Zweedse kronen), Polen (Poolse zloty), Tsjechië (Tsjechische kroon) te betreden, was het noodzakelijk om meerdere valuta's in te voeren.
Het kostte het hele team maanden om deze functionaliteit te implementeren, en de ontwikkeling van nieuwe functionaliteit vertraagde nog verder. In het geval van een microservice-architectuur zou alles veel eenvoudiger en sneller zijn.
Tweede voorbeeld. Aanvankelijk werd de sitebuilder gelanceerd in de moedertaal en het management zou niet uitbreiden naar andere markten. Het project had een monolithische architectuur en de functionaliteit groeide snel. Het schema van het platform was een complex web waarin alles met alles was verbonden. Op een dag besloot het bedrijf een versie van het platform in andere talen uit te brengen. In eerste instantie leek het voldoende om alleen taalbestanden toe te voegen en nu zullen we de hele interface laten vertalen.
In de praktijk moest het hele project opnieuw worden gedaan. Zo moeten de namen van bedrijven en producten in de database nu niet alleen in één taal, maar in elke taal worden opgeslagen. Het was onmogelijk om informatie te dupliceren vanwege de bedrijfslogica, het was noodzakelijk om de namen voor alle talen tegelijk op te slaan. Dit leidde dan ook tot veranderingen in de interfaces van de kast en de backoffice. Interfacewijzigingen vereisten het wijzigen van de regels voor het valideren van inkomende gegevens, briefsjablonen vanwege verschillende principes van eindes in verschillende talen, veranderende tests, enz.
Omdat alles met alles verbonden was, werd besloten om samen met de lancering van nieuwe talen naar een microservice-architectuur te gaan. Het proces van overgang van monolithische naar microservice-architectuur duurde meer dan een jaar.
Derde voorbeeld. Het fintech-platform is gemaakt op een oude versie van PHP en Laravel. Upgraden naar nieuwere versies, evenals het wijzigen van de database van MariaDB naar PostgreSQL, was vrijwel onmogelijk, omdat het hele team zich slechts enkele maanden bezighield met het migratieproces.
Nieuwe versies van PHP en Laravel in die tijd konden het project en de verdere ontwikkeling versnellen, maar de monolithische architectuur stond het updaten van de technologiestack niet toe
.
