Als ervaren developer heeft Eonics oprichter Jan Peter Jansen op de praktijk gestoelde inzichten waar die hij graag deelt. Jan Peter: ‘Architectuur is in het algemeen gezegd de structuur van je applicaties en gaat over zaken als de call flow die door je applicatie gaat, hoe je de schaalbaarheid regelt, wat speelt er rond security en is mijn data consistent. Allemaal vragen die in je architectuur beantwoord moeten worden. Het zijn dus geen feitelijke functionaliteiten van je applicatie.’

Meestal heb je voor je applicatie te maken met veel users die door de diverse schermen heen klikken maar je kunt ook te maken hebben met bulk verstuurde berichten die een iets andere architectuur nodig heeft, al blijft de architectuur in de basis wel gelijk volgens Jan Peter. ‘Je wilt als je veel users hebt, steeds kunnen opschalen en geen data kwijtraken en de security speelt een grote rol. Tegenwoordig gebruiken we vaak single page applicatie: een call naar de back-end waarna vervolgens de hele front-end naar de user wordt toegeslingerd. Vanaf daar gaan de API-calls naar de back-end. Bij API gebaseerde applicaties kun je vanaf de back-end verschillende kanalen bedienen zoals mobiel of een traditionele website voor de desktop.’

In essentie zorgt die API applicatie voor een schone back-end en je kunt er gemakkelijk tegenaan programmeren. ‘Bij een gelaagde architectuur heb je een losse front-end en de back-end zijn je services met de database. Al je state management (waar sla ik data op) hou je (tijdelijk) in je front-end en sla je op in de browser. Daarmee is de back-end stateless dus die hoeft geen data op te slaan waardoor je die makkelijk kunt opschalen. Bij single page applicaties heb je geen last meer van schaalbaarheid want je gebruikt namelijk de computer van de gebruiker. De gebruikers logica zit daarmee in de front-end.’

Microservices vindt Jan Peter en modewoord en hij waarschuwt developers om goed na te denken wat het precies inhoudt voor je het gaat gebruiken in je architectuur. ‘Losse componenten moeten altijd goed kunnen communiceren want anders kan dit tot problemen leiden. De service moet kunnen groeien, moet losgetrokken kunnen worden maar ook los kunnen schalen. Docker is een handige tool voor een schaalbare oplossing. Ook kun je bepaalde onderdelen daarin gemakkelijk in een andere taal schrijven zoals bijvoorbeeld Go of Node.js. Java heeft altijd veel geheugen nodig. Losse componenten moet je altijd kunnen vervangen door iets anders dus gebruik altijd open standaarden zoals SAML. Mocht later blijken dat er iets niet handig werkt, dan kun je de component eruit halen. Ook de keuze van de provider is belangrijk want je wilt geen limitaties van je services of eraan vastzitten, security gaten of een feature die ermee ophoudt.’

Of je wel of niet in de cloud werkt, heeft geen impact op je architectuur want die moet altijd op verschillende plekken kunnen draaien. ‘Of je de cloud gebruikt hangt af van je budget maar ook van je schaalbaarheid behoeftes. Qua inwisselbaarheid kan werken in de cloud lastig zijn. Ik vind dat je altijd ervoor moet zorgen dat je niet super vast zit. Wat dat betreft ben ik wel ietwat conservatief. Mijn advies is om niet te veel moderne technieken en tools te gebruiken want die hebben tijd nodig om zich uit te ontwikkelen en je wilt niet op je snuit gaan. Wacht dus tot iets een standaard is voor je het in je architectuur gebruikt. Kies talen en tools die veel gebruikt worden in de open source en inwisselbaar zijn. Zo kun je altijd terugkomen op een genomen besluit of gradueel overstappen. Stel dat je in Java begonnen bent maar verder wilt met Python. Dit moet je dan gradueel kunnen implementeren in dezelfde architectuur. Denk altijd na over de facetten inwisselbaarheid (swappability), stateless, schaalbaarheid en of het niet te groot is. Hoe benader ik die zaken, hoe kan ik ze vervangen of verbeteren. Breng ook altijd een logische splitsing tussen front-end en back-end aan.’

Als laatste vertelt Jan Peter nog iets meer over de database. ‘De schaalbaarheid van de database kan soms lastig zijn, geeft problemen met synchroniseren. Tegenwoordig gebruiken we event-driven database: je omschrijft je verandering in een event queue dus een single source processor die werkt voor verschillende data en de schaalbaarheid als geheel mogelijk maakt. De database heeft ook te maken met je soort applicatie. Meestal (99%) hebben we te maken met heel veel reads en een paar writes. Je kunt dan bijvoorbeeld ook gaan splitsen op land of voornaam  dus koppelen aan een attribuut van de gebruiker  en die gebruiken om je database op te schalen. Je hebt dan geen standaard nodig en spreekt van een failover met 1 database.’

Wil je ook tips voor jouw architectuur? Laat je gegevens achter via het onderstaande formulier, dan neemt Jan Peter Jansen zo snel mogelijk contact met je op.