Kontakt oss for et personlig FinMV-tilbud skreddersydd til dine behov.
Den tekniske direktøren for bedriften din, når den planlegger lanseringen av en finansiell plattform, må velge et alternativ for prosjektarkitektur. Hvilke arkitekturalternativer er tilgjengelige for ham, og hvilken er bedre å velge?
En monolitisk arkitektur er som en snøball. Du starter et prosjekt og har en liten snøball. Den er så liten at den kan utvikles og rulles av et lite team. Det går et par år, og nå har snøballen din blitt så stor at 20 utviklere allerede presser på den. Om et par år til vil hundrevis av utviklere rulle snøballen din med massevis av kode, men lanseringen av nye funksjoner vil gå veldig sakte.
Som et resultat begynner eierne å endre teknisk direktør, teammedlemmer, men det blir bare verre. Nye teammedlemmer kjenner ikke til de historiske detaljene, hvorfor snøballen er som den er og ikke en annen. Produktdokumentasjonen blir raskt utdatert.
Hvorfor ikke gjøre det rett fra starten av? For det første, helt i begynnelsen av en virksomhet er det alltid ressurser er begrenset, det er ikke nok utviklere, ekspertise og tid. Håndboken oppfordrer, og programmererne har det travelt med å gjøre det på raskest mulig måte.
For det andre tenker tekniske ingeniører: "Vel, la det være en monolitisk arkitektur foreløpig, men når virksomheten vokser, vil vi gjøre om alt". Dessverre, i virkeligheten, vil det å overføre et eksisterende monolittisk prosjekt til en mikrotjenestearkitektur være ti ganger vanskeligere enn å skrive alt fra bunnen av.
Vi vil lage din finansielle plattform umiddelbart basert på mikrotjenestearkitektur.
Mikrotjenestearkitektur kan sammenlignes med belegningsheller på gangstier. Etter hvert som prosjektet ditt vokser, blir flere fliser lagt til gangveien din. Hvis en komponent er utdatert, er det nok å erstatte denne flisen med en ny.
Denne arkitekturen har mange fordeler, men jeg vil nevne de viktigste:
Første eksempel. Ledelsen av en P2P-utlånsplattform med et stort antall brukere bestemte seg for å gå inn på markedene i land med en annen valuta. Plattformen hadde en monolittisk arkitektur og inkluderte bare én valuta - euroen, og for å komme inn på markedene i Sverige (svenske kroner), Polen (polske zloty), Tsjekkia (tsjekkiske krone) var det nødvendig å introdusere multivaluta.
Det tok måneder før hele teamet implementerte denne funksjonaliteten, og utviklingen av ny funksjonalitet bremset ytterligere ned. Når det gjelder en mikrotjenestearkitektur, ville alt vært mye enklere og raskere.
Andre eksempel. Opprinnelig ble nettstedbyggeren lansert på morsmålet, og ledelsen hadde ikke tenkt å utvide til andre markeder. Prosjektet hadde en monolitisk arkitektur, og funksjonaliteten vokste raskt. Opplegget til plattformen var en kompleks nett der alt var koblet til alt. En dag bestemte virksomheten seg for å gi ut en versjon av plattformen på andre språk. Først så det ut til at det ville være nok å bare legge til språkfiler, og nå vil vi få oversatt hele grensesnittet.
I praksis måtte hele prosjektet gjøres om. For eksempel bør navnene på selskaper og produkter i databasen nå lagres ikke bare på ett språk, men på hvert språk. Det var umulig å duplisere informasjon på grunn av forretningslogikken, det var nødvendig å lagre navnene for alle språk på en gang. Følgelig førte dette til endringer i grensesnittene til kabinettet og backoffice. Endringer i grensesnittet krevde å endre reglene for validering av innkommende data, brevmaler på grunn av ulike prinsipper for avslutninger på forskjellige språk, endring av tester osv.
Siden alt var koblet til alt, ble beslutningen tatt om å gå over til en mikrotjenestearkitektur sammen med lanseringen av nye språk. Prosessen med overgang fra monolittisk til mikrotjenestearkitektur tok mer enn ett år.
Tredje eksempel. Fintech-plattformen ble laget på en gammel versjon av PHP og Laravel. Oppgradering til nyere versjoner, samt endring av databasen fra MariaDB til PostgreSQL, var praktisk talt umulig, siden hele teamet bare måtte håndtere migreringsprosessen i flere måneder.
Nye versjoner av PHP og Laravel på den tiden kunne fremskynde prosjektet og videreutviklingen, men den monolittiske arkitekturen tillot ikke oppdatering av teknologistabelen
.
