2 manieren om web applicaties te ontwerpen

Monolithisch ontwerp

• 99% van de webapplicaties is monolithisch
• Waarom?
  • Er is weinig informatie over alternatieven
  • Elk willekeurig boek over webframeworks gaat over monolithische apps

Uitdagingen bij monolithische webapplicaties

• Code complexiteit
• Latency: Goede responsetimes zijn lastig (de applicatie/applicatiemachine "doet alles")
• Tijdsintensieve operaties moeten daarom op aparte hardware
• Schalen volgens "alles of niets" (standaard manier om dit op te lossen is AMQP)

Service gebaseerd: verschillen

• Service gebaseerde applicaties zijn opgebouwd uit meerdere, kleine, onafhankelijke "diensten" (denk: www, api, accounts, portal)
• Elke dienst praat via HTTP met andere diensten en/of met de browser
• Elke dienst heeft (de mogelijkheid tot) zijn eigen resources (webserver, database).
• Elke dienst bestaat uit minder code (want ze doen minder). Dit vereenvoudigd het onderhoud en de mentale belasting voor developers en sysadmins

Verschil 1: Onderhoud

• Stel, je hebt een 'accounts' webservice gebouwd. Die is verantwoordelijk voor de CRUD van gebruikersaccounts
• Als developer weet je precies waar je moet zijn
• Niet zoeken door één massieve codebase, want alle applicatie logica zit in die ene applicatie op die ene plek, met zijn eigen repository et cetera

Verschil 2: Schaalbaarheid

"Service-gebaseerd heeft een passief positief effect op schaalbaarheid"

• Per service eigen resources geeft flexibiliteit bij schalen en upgrades
• Downtime geldt minder vaak voor de hele applicatie

Verschil 2: Schaalbaarheid, cont'd'

Stel, je hebt de volgende services:

• lizard-api, de publiekelijke API voor developers
• lizard-www, de publiekelijke website-service
• lizard-accounts, de interne API voor het beheer van gebruikersaccounts

→ Telkens als een developer een request doet naar lizard-api, moet hij eerst worden geauthenticeerd bij lizard-accounts. Elke keer als een bezoeker inlogt op de site, moet hij ook authenticeren bij lizard-accounts

→ Lizard-accounts krijgt het dus veel drukker dan lizard-api en lizard-www

Verschil 2: Schaalbaarheid, cont'd'

Door onafhankelijkheid snel schalen:

• Meer webservers
• Grotere database
• Message queues toevoegen

...zonder de andere diensten te beinvloeden.

Vergelijk dit met monolithisch design, waar je alleen de hele applicatie kan schalen. (in feite doen we dit al met PostgreSQL op aparte servers)

Verschil 3: Simpliciteit

Stel, je bent een bank, en hebt een monolithische applicatie die via een message queue taken afvuurt welke geld van accounts afhalen.

Dit doe je via een queue omdat het veel tijd kost en je de applicatie niet wil belasten

Wat als je in plaats van:

• Een queue draaien
• Een backup queue draaien
• Meerdere worker machines

...simpelweg een HTTP POST kon doen naar een interne transactions API die het in realtime doet?

Verschil 3: Simpliciteit, cont'd'

...dat kan:

• De transactie API server kan onafhankelijk worden geschaald (horizontaal of verticaal)
• De codebase blijft simpel en onderhoudbaar

In plaats van een MQ kun je een kleine onafhankelijke "transactie" API bouwen waar je op kan focussen.

Uitdagingen bij service-gebaseerde webapplicaties

Typische problemen gerelateerd aan service-gebaseerde applicaties

Langere tijd tot een minimum-viable-product

Vaak gehoord probleem: bij het bouwen van Service-gebaseerde applicaties duurt het vaak langer om tot een werkende basisversie te komen

De reden is dat er voor een Service-gebaseerde applicatie meer werk vooraf moet worden gedaan.

Voorbeeld

Stel je voor dat je Tumblr gaat nabouwen. Je begint als volgt:

• Een tumblr-accounts service met een CRUD API voor gebruikersaccounts en authenticatie
• Een tumblr-api service met een CRUD API voor publicatie van blogposts van gebruikers
• Een publiekelijke tumblr-www service die gebruik maakt van de accounts en www api's

• ...tijdens het bouwen kom je een ander obstakel tegen: het bouwen van een duidelijke en eenduidige API. Dit kun je niet laten liggen, stubben of faken.
• In geval van een monolithische applicatie kun je makkelijker dingen faken of uitstellen: ipv een database per service kun je nog wegkomen met een grote database voor alles. Daardoor kun je bijvoorbeeld ook de ORM van je framework gebruiken.

Lange vs korte termijn

Naarmate de applicatie groeit qua features en complexiteit, blijft een modulaire applicatie die bestaat uit losse diensten eenvoudiger te onderhouden.

Echter, op korte termijn is een monolithisch project veel sneller in elkaar te zetten.

Authenticatie

Eén van de meest voorkomende design problemen is authenticatie

Ter illustratie: Django

• Telkens als een user een HTTP request doet, kijkt Django via de ORM of het account bestaat en geauthenticeerd is

Voorbeeld, Service based:

• Geen ORM
• Bij elk HTTP request moet je nu een HTTP request doen naar de interne accounts service om de gebruiker te authenticeren

Kosten

Afhankelijk van budget en wensen kan dit een limiterende factor zijn.

Om daadwerkelijk voordeel te hebben van service-gebaseerde architectuur, moet elke service onafhankelijk van elkaar opereren.

Voor kleine applicaties kan dit overkill zijn.