Ota yhteyttä ja pyydä tarpeisiisi räätälöity FinMV-tarjous.
Yrityksesi teknisen johtajan on valittava projektiarkkitehtuurivaihtoehto suunnitellessaan rahoitusalustan lanseerausta. Mitä arkkitehtuurivaihtoehtoja hänellä on tarjolla ja mikä on parempi valita?
Monoliittinen arkkitehtuuri on kuin lumipallo. Aloitat projektin ja sinulla on pieni lumipallo. Se on niin pieni, että pieni tiimi voi kehittää ja rullata sitä. Pari vuotta kuluu, ja nyt lumipallostasi on tullut niin valtava, että 20 kehittäjää ajaa sitä jo. Muutaman vuoden kuluttua sadat kehittäjät pyörittävät lumipalloasi kooditonnilla, mutta uusien ominaisuuksien julkaisu hidastuu.
Tämän seurauksena omistajat alkavat vaihtaa teknistä johtajaa ja tiimin jäseniä, mutta se vain pahenee. Uudet tiimin jäsenet eivät tiedä historiallisia yksityiskohtia, miksi lumipallo on sellainen kuin se on eikä toinen. Tuotedokumentaatio vanhenee nopeasti.
Miksi et tekisi sitä heti alusta alkaen? Ensinnäkin heti yrityksen alussa on aina resurssit rajalliset, kehittäjiä, asiantuntemusta ja aikaa ei ole tarpeeksi. Käsikirja vaatii, ja ohjelmoijat kiirehtivät tekemään sen nopeimmalla mahdollisella tavalla.
Toiseksi tekniset insinöörit ajattelevat: "No, olkoon se toistaiseksi monoliittinen arkkitehtuuri, mutta kun yritys kasvaa, teemme kaiken uudelleen". Valitettavasti todellisuudessa olemassa olevan monoliittisen projektin siirtäminen mikropalveluarkkitehtuuriin on kymmeniä kertaa vaikeampaa kuin kirjoittaa kaiken alusta.
Teemme taloudellisesta alustastasi välittömästi mikropalveluarkkitehtuuriin perustuvan.
Mikropalveluarkkitehtuuria voidaan verrata päällystyslaattoihin kävelyteillä. Kun projektisi kasvaa, käytävällesi lisätään lisää laattoja. Jos komponentti on vanhentunut, tämä ruutu riittää vaihtamaan uuteen.
Tällä arkkitehtuurilla on monia etuja, mutta mainitsen niistä tärkeimmät:
Ensimmäinen esimerkki. P2P-lainaalustan hallinta, jolla on suuri määrä käyttäjiä, päätti tulla maiden markkinoille, joissa on eri valuutta. Alustalla oli monoliittinen arkkitehtuuri ja se sisälsi vain yhden valuutan - euron, ja päästäkseen Ruotsin (Ruotsin kruunu), Puolan (Puolan zloty), Tšekin tasavallan (Tšekin kruunu) markkinoille oli tarpeen ottaa käyttöön monivaluutta.
Tämän toiminnon käyttöönotto koko tiimillä kesti kuukausia, ja uusien toimintojen kehitys hidastui entisestään. Mikropalveluarkkitehtuurin tapauksessa kaikki olisi paljon helpompaa ja nopeampaa.
Toinen esimerkki. Aluksi sivuston rakentaja lanseerattiin äidinkielellä, eikä hallinta aikonut laajentua muille markkinoille. Projekti oli arkkitehtuuriltaan monoliittinen ja toiminnallisuus kasvoi nopeasti. Alustan rakenne oli monimutkainen verkko, jossa kaikki oli yhteydessä kaikkeen. Eräänä päivänä yritys päätti julkaista alustan version muilla kielillä. Aluksi näytti siltä, että pelkkien kielitiedostojen lisääminen riittäisi ja nyt käännetään koko käyttöliittymä.
Käytännössä koko projekti piti tehdä uudelleen. Esimerkiksi yritysten ja tuotteiden nimet tietokannassa tulisi nyt tallentaa ei vain yhdellä kielellä, vaan jokaisella kielellä. Tietojen kopioiminen oli mahdotonta liiketoimintalogiikan vuoksi, oli tarpeen tallentaa kaikkien kielten nimet kerralla. Vastaavasti tämä johti muutoksiin kabinetin ja taustatoimiston rajapinnoissa. Käyttöliittymämuutokset vaativat saapuvien tietojen validointisääntöjen muuttamista, kirjepohjia eri kielten päätteiden eri periaatteiden vuoksi, testien vaihtamista jne.
Koska kaikki oli yhteydessä kaikkeen, päätettiin siirtyä mikropalveluarkkitehtuuriin uusien kielten lanseerauksen myötä. Siirtyminen monoliittisesta mikropalveluarkkitehtuuriin kesti yli vuoden.
Kolmas esimerkki. Fintech-alusta tehtiin PHP:n ja Laravelin vanhalle versiolle. Päivitys uudempiin versioihin sekä tietokannan vaihtaminen MariaDB:stä PostgreSQL:ksi oli käytännössä mahdotonta, koska koko tiimi joutui käsittelemään vain siirtoprosessia useiden kuukausien ajan.
Uudet PHP- ja Laravel-versiot saattoivat nopeuttaa projektia ja jatkokehitystä, mutta monoliittinen arkkitehtuuri ei sallinut teknologiapinon päivittämistä
.
