Marco Rijkers

Software architectuur

In de eerste helft van deze blog zal ik proberen uit te leggen wat software architectuur is. De tweede helft gaat over de software architectuur van Mobile Runway. Hoewel ik probeer om het verhaal zo eenvoudig mogelijk te houden, ontkom ik er niet aan om het soms toch wat technisch te maken. Software architectuur blijft tenslotte iets voor de techneuten. Maar gebruikers plukken er uiteindelijk de vruchten van doordat ze een goed reagerende applicatie krijgen. Ook valt er natuurlijk veel uitgebreider te vertellen over software architectuur, maar dan wordt deze blog een boekwerk.

Wat is een software architect en wat doet die? Een software architect is te vergelijken met een architect van een huis. Maar ook met een stedenbouwkundig architect of binnenhuis architect. Laat ik het daarom eerst maar eens over deze groep van architecten hebben.

Stedenbouw

Bij het ontwerpen van steden worden de laatste 3 genoemde architecten aan het werk gezet. Het begint met een stedenbouwkundig architect. Deze heeft bepaald wat de globale bouwstenen van een nieuwe wijk worden:

  • Welk type huizen moeten er komen (flats, rijtjes woningen, half vrijstaand, vrijstaand)?
  • Welke huizenblokken komen er en waar komen deze te liggen?
  • Waar komen publieke gebouwen zoals scholen, winkels, sporthallen e.d.
  • Waar komen parken, recreatieplassen en speeltuinen?
  • Waar komen de wegen, rotondes en bruggen, m.a.w. hoe lopen de verbindingen tussen al de bovengenoemde onderdelen?

Als de stedenbouwkundig architect klaar is, gaan meerdere huizenarchitecten verschillende huizenblokken ontwerpen. En als de huizenarchitecten klaar zijn, kan de tuinarchitect en binnenhuis architect aan de slag. En de bouwvakkers moeten de ideeën van al die architecten zien te realiseren.

Applicaties Wat is nu de invloed die een stedenbouwkundig architect heeft op een binnenhuis architect? Als een stedenbouwkundig architect een blok rijtjeshuizen wil hebben in een straat die 1 lange bocht is, dan zal de architect huizen ontwerpen waarbij de voorkant van de huizen breder is dan de achterkant van de huizen. Dat kan er van buiten mooi uitzien. Maar voor de binnenhuisarchitect is dat frustrerend. Die krijgt met allemaal rare hoeken te maken. Keukenkastjes kunnen dan bijvoorbeeld niet meer open. Hij zal dus erg creatief moeten zijn en meer tijd moeten besteden om er toch nog iets van te maken dat niet alleen mooi, maar ook functioneel en efficiënt is.

Moraal van het steden ontwerpen is, dat als de eerste architect - die nog globaal te werk gaat - iets bedenkt, dan kan de laatste architect daar erg last van hebben. Om het totale proces zo efficiënt mogelijk te laten verlopen, zal de globale architect dus ook functioneel moeten denken en niet alleen maar of het er leuk uit komt te zien.

Software architectuur

Zoals bij stedenbouw, zijn er in de software ontwikkeling ook diverse nivo’s van architecten te onderscheiden. Ook hier begint het met een globale architectuur:

  • On premise (lokaal geinstalleerd) of cloud applicatie?
  • Welke database?
  • Welke programmeertaal/-talen gaan we gebruiken?
  • ...

Als antwoorden op de bovenstaande vragen zijn gegeven, dan gaat de globale architect verder. Omdat tegenwoordig steeds meer applicaties voor in de cloud worden ontworpen, gaan we bij de volgende punten uit van een cloud applicatie. De browser wordt gebruikt voor de user interface en servers op het internet worden gebruikt om de applicatie aan te bieden. Nu moeten de volgende vragen worden beantwoord:

  • Wordt de applicatie als single page-website gebouwd, of voor iedere view (= scherm) een nieuwe web page?
  • Wordt er op de server bepaald wat de volgende te tonen view is of wordt dat in de browser bepaald?
  • Uit bovenstaande punt volgt ook de vraag hoe de browser precies gaat worden gebruikt. Gaat de applicatie in de browser draaien en wordt er alleen op de server teruggegrepen om data te bewaren en op te halen? Of worden de diverse views dynamisch door programma’s op de server gegenereerd en vervolgens naar de browser gestuurd?
  • Gaat één programma op de server al het werk doen, of wordt het werk verdeeld over verschillende losstaande programma’s? En als het in verschillende programma’s wordt opgedeeld, moet het dan mogelijk zijn om deze programma’s tegelijk op verschillende servers te laten draaien, of worden ze altijd op maar 1 server gedraaid?
  • Welke frameworks gaan we gebruiken voor het werk dat op de servers moet worden gedaan?
  • Welke frameworks gaan we gebruiken voor het werk dat in de browser wordt gedaan?
  • Welke tools hebben we verder nodig om alle functionaliteit te kunnen bouwen?
  • ...

Als op alle bovenstaande vragen antwoorden zijn gegeven, dan kunnen vervolgens de UI designer (user interface architect – hoe komt de user interface eruit te zien en hoe kan deze worden gebruikt) en de business logic architect (voor alles wat 'onder de motorkap' plaatsvindt) voor de server programma’s aan de slag. Als er voor is gekozen dat de applicatie in de browser draait (en alleen maar gegevens ophaalt van- of wegschrijft naar de server), dan is er ook nog een architect nodig die de business logic voor in de browser gaat ontwerpen. Beiden doen dat binnen de door de globale architect opgestelde kaders. Tot slot gaan de developers (zeg maar: de bouwvakkers) aan de slag.

Ook bij software architectuur wordt het de eind-architecten en de developers makkelijker gemaakt om efficiënt te ontwerpen en bouwen als de basis van de globale architect goed is. Dat komt de onderhoudbaarheid van de software ten goede en het kost veel minder dan dat er bult op bult moet worden gebouwd. Hoe weet je nu of de basis goed is? Als nieuwe functionaliteit eenvoudig is te integreren in het grote geheel, zonder dat het aanvoelt alsof je bulten op de huidige software aan het bouwen bent. Als je het gevoel hebt dat het eenvoudiger zou moeten kunnen, dan is dat vaak ook zo.

In de praktijk worden de diverse soorten architecten meestal uitgevoerd door developers. Een senior developer zal zich vaak ook bezig houden met de globale architectuur. Medior developers beginnen zich al bezig te houden met stukken business logic architectuur. En user interface developers hebben ook vaak wel een inbreng in de UI architectuur. Wie de architectuur ook opzet, het is verstandig om er iemand voor verantwoordelijk te maken. Dat geeft meer duidelijkheid en het voorkomt dat er meerdere architectuurstijlen door elkaar heen worden gebruikt (dat worden weer bulten).

Software architectuur van Mobile Runway

Hoe is de architectuur nu bij Mobile Runway (MR) opgezet? Welke keuzes zijn er binnen MR gemaakt? Ik zal proberen heel in het kort uit te leggen hoe het in elkaar zit en waarom bepaalde keuzes zijn gemaakt. De belangrijkste doelstellingen bij het vinden van een goede architectuur waren:

  • Meerdere applicaties tegelijk kunnen draaien
  • Performance
  • Schaalbaarheid
  • Snel apps kunnen bouwen

Client (browser):

MR laat de applicaties volledig in de browser draaien als een single webpage. Programmeren gebeurt met javascript en jQuery wordt als basis framework gebruikt. Daarnaast heeft MR zelf een javascript framework ontwikkeld waarmee veelgebruikte functionaliteit maar eenmalig hoeft te worden gebouwd. De benodigde javascript sources worden aan de server opgevraagd op het moment dat een javascript class nodig is (voor php techneuten: een soortgelijk mechanisme als autoloaders in php). Voordeel is dat de gebruiker niet hoeft te wachten tot alles geladen is en er worden alleen maar javascript sources geladen die echt nodig zijn.

Doordat alles als single page in de browser draait, kan er veel in een cache van het MR framework worden gestopt. Als een bepaalde app, bijvoorbeeld een tekst editor, één keer is uitgevoerd, dan hoeft het de 2e keer niet meer te worden opgehaald van de server. En de javascript hoeft niet meer naar machinetaal (een voor de computer te begrijpen taal) te worden vertaald. Dit alles heeft een grote invloed op de performance van de applicaties zoals gebruikers dat ervaren.

De apps in de browser hebben natuurlijk wel gegevens nodig. Deze gegevens zijn opgeslagen op de servers van MR. De verbinding met de server worden alleen gebruikt om gegevens er naar toe te sturen en om de gegevens weer op te vragen. Het internet is een relatief trage factor binnen cloud applicaties. Omdat MR alleen maar gegevens van/voor een app (maar niet de app zelf) tussen client (browser) en server over stuurt, is het verkeer over het internet maar heel beperkt. Dat helpt natuurlijk ook mee aan een goede performance.

Naast een connectie met de server kan de browser ook een rechtstreekse verbinding met een andere browser opbouwen. Omdat MR applicaties volledig in de browser laat draaien, was het eenvoudig om dat in het MR framework in te bouwen (gevolg van de juiste architectuur).

Server:

De software op de server wordt gebruikt om data naar de client te sturen en om data van de client te ontvangen. De server weet niet wat voor een soort client er verzoeken in dient. De client zal meestal een browser zijn, maar kan net zo goed een andere applicatie zijn van een willekeurig bedrijf aan de andere kant van de wereld. Of een user interface die niet in de browser draait. Uit dit laatste is direct af te leiden dat een applicatie niet helemaal hoeft te worden vervangen als bijvoorbeeld de user interface niet meer voldoet. De client en server software zijn volledig van elkaar gescheiden.

Omdat de client en de server volledig van elkaar zijn gescheiden, kunnen de developers voor de userinterface zich volledig concentreren op alle technieken die daarvoor nodig zijn. Ze hoeven geen kennis te hebben van de gebruikte server software of programmeertaal. Anderzijds hoeven de ontwikkelaars die zich vooral met de functionaliteit van een app (business logic) bezig houden, niet te bedenken of het voor de gebruiker wel handig is om de app te gebruiken. Bij MR zal je dus niet, zoals bij de meeste web software ontwikkelbedrijven, een servertaal zien die gebruikt wordt om html en javascript te genereren. In onze ogen is dat echt not-done. De client en de server zijn dan gewoon niet voldoende gescheiden.

Een verzoek van de client voor een bepaald soort complexe en grote hoeveelheden data kan soms lastig zijn om op te hoesten, want de gebruiker wil niet eindeloos staan te wachten. MR gebruikt services die eenvoudig zijn uit te breiden met nieuwe functionaliteiten. Een service (een soort programma die staat te wachten tot iemand zijn diensten nodig heeft) hoeft niet op dezelfde server te draaien. Daardoor worden de apps van MR zeer schaalbaar. Als op termijn de performance minder wordt vanwege een groter aantal gebruikers, dan kan de performance eenvoudig worden opgevoerd door een extra server in te zetten.

De webserver kan services zeer efficiënt aanspreken. Daarbij kan de server vast verder gaan met zijn eigen werk terwijl de service ook nog aan het werk is. Als de service klaar is dan geeft deze het resultaat terug aan de server. De server gebruikt dit dan weer om een antwoord aan de client te geven.
Omdat de service volledig zelfstandig werkt, kan de service ook volledig apart worden ontwikkeld. De techniek van de service staat daardoor ook helemaal los van de rest van de applicatie. Het enige dat bij zowel de server/applicatie als de service overeen moet komen, is de interface waarmee de service wordt aangesproken.

De communicatie tussen client en server gebeurt d.m.v. rest-interfaces. Dit is een eenvoudige, heldere en efficiënte manier van data-overdracht. De rest-interface maakt gebruik van https, waardoor data-overdracht altijd beveiligd is tegen meekijken door onbevoegden. Maar er ligt ook een verbinding met de server via een websocket verbinding (ook beveiligd). Daardoor kan de server ook berichten naar de browser/client pushen, terwijl bij de meeste web apps de client altijd initiatief neemt om gegevens op te halen.

Slot

Tot zover de globale software architectuur. Na de globale architectuur op orde te hebben, kan een architect met de volgende stap beginnen: het opdelen van de software in min of meer losstaande modules. Maar daar ga ik in deze blog niet verder over vertellen.

Zoals ik al eerder schreef, kan ik natuurlijk veel meer vertellen over software architectuur, maar dan wordt deze blog veel te lang. Toch hoop ik dat je misschien nieuwe ideeën hebt kunnen opdoen en een beetje inzicht hebt gekregen in hoe een globale architectuur tot stand komt en hoe dit in de praktijk (bij Mobile Runway) wordt gebruikt. Voor gebruikers van de MR apps is deze blog misschien niet helemaal te begrijpen of het is oninteressant, maar ze kunnen wel vertellen hoe hun beleving is van het resultaat van de MR architectuur. En ik ben er zeker van dat ze daarvan een positieve beleving hebben!