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
- Tijd tot MVP
- Authenticatie
- Kosten
- Documentatie
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.