Toen Martin McCann en Mathias Born besloten om Trade Ledger, een Australisch leenplatform, op te richten, was hun plan om leendiensten te vereenvoudigen en te stroomlijnen door middel van cloudgebaseerde software voor geldschieters. Hun reis biedt CIO’s inzichten in hun eigen ontwikkelingsinspanningen.
Toen Trade Ledger zijn software als een service begon te ontwikkelen, was het team van Born gefocust op het bouwen en ontwerpen van een systeem dat over een paar jaar niet verouderd zou zijn. Afgezien van de technische keuzes, moest Born overwegen of het hele team onafhankelijk werkte aan elk stuk functionaliteit en hun delen van die repository beheerde en onderhield.
En tot slot, in een zakelijke context, zegt Born dat het belangrijk is om te weten of de functionaliteit modulair is en op verschillende gebieden kan worden gebruikt.
“Soms is het meer een kunst dan een wetenschap. Maar het was zeker een uitdaging om die componenten in de juiste context op te splitsen”, zegt hij.
De uitdagingen van het bouwen van modulaire functies en het adopteren van een microservices-architectuur
Er waren meerdere uitdagingen bij de aanpak van het adopteren van een microservices-architectuur.
Voor organisaties die een soortgelijk systeem bouwen, zegt Born dat het belangrijk is om uit te zoeken of bepaalde delen van het systeem veel worden gebruikt en deze te ontkoppelen, zodat de functie vervolgens onafhankelijk kan worden geschaald.
Een technische uitdaging was dat veel van de technici van Trade Ledger meer vertrouwd waren met traditionele SQL, traditionele relationele databases en een traditionele manier om gegevensmodellen te construeren. “Dat samenvoegen in de documentgeoriënteerde database is zeker een andere manier van denken, maar desalniettemin was de documentgeoriënteerde database het juiste model voor ons”, zegt Born.
Een andere uitdaging was een vroege beslissing om het systeem monolithisch te bouwen. De eerste versie van Trade Ledger die in 2017 op de markt kwam, werd gebouwd door een team van drie ingenieurs, ondanks dat het een groter en complexer systeem was dan wat nu bestaat. Die monolithische benadering maakte het moeilijk om het platform te ontwikkelen, dus Trade Ledger moest overschakelen naar een modulaire, componentbenadering.
Als gevolg hiervan moesten ze de componenten van de modules in de volgende iteratie opsplitsen in afzonderlijke componenten. Om dat te doen, koos Trade Ledger voor een gefaseerde aanpak door bepaalde delen van het systeem te herstructureren en speciale componenten te creëren.
Trade Ledger had bijvoorbeeld aanvankelijk een functie die een koppeling mogelijk maakte met cloudgebaseerde boekhoudsystemen zoals Xero. Nu bevindt het zich in zijn eigen speciale component, in plaats van een functie binnen een monolithische toepassing te zijn. “We hebben dit stuk gepakt en naar zijn eigen connectorcomponent verplaatst, waardoor we dit konden uitbreiden, onafhankelijk van enige andere wijziging in de oorspronkelijke monoliet”, zegt Born.
De applicatie-architectuur zelf moet modulair zijn, niet alleen de gecodeerde componenten, merkt Born op. “In een op microservices gebaseerd systeem willen we ervoor zorgen dat de services onafhankelijk van elkaar werken. Anders lopen we het risico een monolithische applicatie te bouwen met behulp van een microservices-architectuur.”
In een modulaire toepassing met microservices wordt tijdelijke inconsistentie verwacht en het is belangrijk om ervoor te zorgen dat gegevens niettemin in wezen consistent zijn, omdat gegevens over de verschillende services zich op verschillende niveaus kunnen bevinden, afhankelijk van de uitvoeringstijd.
“Andere uitdagingen zijn het benutten van de kracht van documentgericht denken”, zegt Born. “In relationele databases worden gegevens doorgaans aan elkaar gekoppeld en maakt u joins om de gegevens te doorzoeken of te consolideren. In een documentgeoriënteerde database moet je anders denken en kun je veel informatie opslaan in een embedded object. Als dit echter informatie is die heel vaak verandert, is het misschien niet de beste manier om alles in één document op te slaan. Meerdere kleinere documenten kunnen efficiënter zijn.”
Born suggereert een paar dingen om op te letten:
- Als de gegevens tot hetzelfde domein behoren – domeingestuurd ontwerp – en de frequentie van wijzigingen hetzelfde is, plaats dan alles in hetzelfde model.
- Als de ene entiteit zonder de andere kan leven, plaats ze dan in twee afzonderlijke documenten.
- Als een entiteit altijd een andere specifieke entiteit nodig heeft – een een-op-veel-relatie – is de kans groot dat u ze in hetzelfde document kunt insluiten.
Hoe Trade Ledger de controle over gegevens overnam
Voor de gegevens zelf koos Trade Ledger voor een documentgeoriënteerde database, die de flexibiliteit zou bieden die nodig is in het gegevensmodel en de mogelijkheid om toekomstige groei en schaalbaarheid te beheren.
De volgende stap was het identificeren van de juiste componenten die in een op componenten gebaseerd systeem zouden worden geplaatst. “De manier waarop we het hebben geconstrueerd, is dat elk onderdeel zijn eigen gegevensstructuur en gegevenstabellen bezit, zodat het ene onderdeel niet rechtstreeks met de database van het andere onderdeel kan praten. Dat wordt allemaal afgehandeld door evenementen of API’s, en dit geeft ons in de toekomst flexibiliteit”, zegt Born. Deze structuur stelt Trade Ledger in staat om een duidelijke scheiding te maken tussen het eigendom van de gegevens waarvan de component de gegevens kan wijzigen.
Met MongoDB Atlas, de door de cloud gehoste databaseservice van MongoDB, kon Trade Ledger zijn database configureren om zijn klanten een hoge veerkracht en hoge beschikbaarheid te bieden, waarbij MongoDB fungeerde als een gegevenslaag.
“MongoDB is de operationele database die achter de microservices zit en het gaf ons de flexibiliteit om de overstap te maken. Hoewel niet elke service zijn eigen cluster heeft, geeft dit model ons de flexibiliteit, als het ooit nodig zou zijn, om de services of componenten die de microservices aandrijven – inclusief de database – te wijzigen om verschillende gebruiksscenario’s te ondersteunen”, zegt Born.
De database hielp Trade Ledger ook aan de operationele kant, omdat de organisatie veel van de operationele activiteiten kon ontlasten om zich vervolgens te concentreren op de domeinspecifieke problemen. Nu kan Trade Ledger bepalen waar de gegevens worden gehost, deze repliceren, de beschikbaarheid instellen en tests uitvoeren. Born zegt dat hij 10 jaar geleden een team van 10 tot 20 mensen nodig had om dat werk te doen.
De juiste tools en programmeertalen selecteren
Over hoe MongoDB de uiteindelijke keuze werd, zegt Born dat hij aanbiedingen zoals ArangoDB en DynamoDB heeft onderzocht, evenals een paar kleinere opties. Een van de belangrijkste onderscheidende factoren was dat MongoDB Atlas een volledig beheerd gehost platform biedt. “Het stelde ons in staat om het databasesysteem veel efficiënter te beheren, met een klein team”, zegt hij.
Toen Trade Ledger tools en programmeertalen aan het selecteren was, begon het door te kijken naar de kerncapaciteiten van zijn engineeringteam, dat voornamelijk op Java was gebaseerd, en zo begon het met het bouwen van de eerste componenten in Java.
Voor zijn evenementenserver koos Trade Ledger NATS als een van de kerncomponenten voor de evenementenbus, in plaats van Apache Kafka. “Destijds was er geen geweldige gehoste Kafka-oplossing op de markt, en we hadden niet genoeg capaciteit om meerdere technici alleen aan Kafka te laten werken. NATS was een geweldige oplossing die Docker heeft geoptimaliseerd en ons snel aan de slag heeft gebracht, terwijl het nog steeds een zeer robuuste oplossing voor event-messaging biedt.”
Hoe Trade Ledger zijn systeem wil vereenvoudigen
Next for Trade Ledger is een complete verandering van de gebruikerservaring. Born zegt dat er een grote verandering nodig is om ervoor te zorgen dat het systeem kan blijven groeien. Zoals het team zelf heeft ervaren toen ze een grote schaalfase doormaakten, werd het steeds moeilijker om alle bewegende stukken te coördineren.
Het engineeringteam bekijkt principes van ontwerpsystemen, die ze twee jaar geleden begonnen uit te werken, maar de aanpak was te complex. Het doel is nu om het eenvoudiger te maken.
“Mijn sterke overtuiging is dat de beste code die je kunt hebben geen code is, omdat je ze niet hoeft te onderhouden en er niets mis kan gaan. Het is duidelijk dat het tot het uiterste gaat, maar het gaat om het nemen van slimme beslissingen over wat je codeert. Dat is een van de grote lessen die er soms liever op letten dat het waarschijnlijk veel minder tijd kost om een systeem met minder code te maken in plaats van het alleen te coderen en veel informatie te creëren”, zegt Born.
Trade Ledger bouwt nu een no-code-oplossing voor klanten waar ze hun eigen regels kunnen implementeren zonder codering. Born zegt dat er interessante bewegingen zijn rond no-code UI-platforms met krachtige concepten, maar dat het nog moet worden bewezen of ze ook werken in complexere systemen.
