Observability: van de ene rots naar de andere: het micro-universum observeren

Steeds meer bedrijven migreren hun applicaties naar de cloud, via een private cloud of een public cloud provider. Klantgerichte services die voorheen gebaseerd waren op applicaties met een monolith-architectuur, worden opnieuw ontworpen of al gebouwd en geïmplementeerd met behulp van een microservices-architectuur.

Met de opkomst van microservices kunnen nieuwe functies sneller worden uitgerold. Naarmate het gebruik van microservices toenam, werd ook nieuwe complexiteit geïntroduceerd en werd het moeilijker om alle afhankelijkheden tussen de microservices zelf bij te houden. De grootste impact heeft de uitrol van nieuwe functies in klantgerichte services. Met de adoptie van microservices wordt tweewekelijks of dagelijks de nieuwe standaard, waardoor er geen of niet genoeg tijd meer is voor starre testprocedures.

In die zin is een fout snel gemaakt en inmiddels weten we allemaal dat prestatieverlies – bij het implementeren van nieuwe code – niet meer acceptabel is voor onze klanten.

Dus, met de opkomst van microservices en de toegenomen snelheid, verandert de noodzaak om te begrijpen wat de afhankelijkheden zijn tussen draaiende services en tegelijkertijd te weten wat de impact is op de gebruikerservaring. Hoe los je het op?

De microservices “chaos

Een fabriek die wordt gebruikt om waterstof te produceren is erg complex, met veel leidingen en kleppen enzovoort. We kunnen dit vergelijken met IT-services die gebruikmaken van een microservicesarchitectuur.

We hebben bijvoorbeeld veel redundante componenten in deze architectuur, om ons aan te passen aan storingen. Net als in een fabriek die waterstof produceert, zijn er veel redundanties en beveiligingen ingebouwd. Als je ooit een ontwerp van zo’n fabriek hebt gezien, is het erg complex. Een fabriek die waterstof produceert, brengt daarom niet tweewekelijks nieuwe functies uit zoals dat gebeurt bij IT-architecturen die microservices gebruiken. Dit betekent dat we in de microservices-architectuur een vergelijkbaar complex systeem van services hebben, maar dan één dat snel en regelmatig verandert.

Hoe bewaken we de kwaliteit van onze services terwijl we tweewekelijks of sneller implementeren?

Nou, er zijn verschillende opties. De eerste zou zijn om gewoon nieuwe code te implementeren en er het beste van te hopen. Hoogstwaarschijnlijk zullen je gebruikers gaan klagen, want ik heb nog nooit meegemaakt dat nieuwe code werd uitgerold zonder enig effect op de kwaliteit van de service. Hoewel er nog steeds bedrijven zijn die op deze manier werken, zal het uiteindelijk meer tijd kosten om opnieuw te implementeren. Veel mensen zullen geïrriteerd zijn – inclusief de DEV’s die het probleem moeten oplossen terwijl het gemakkelijk te voorkomen was voor de implementatie. Deze optie is noch snel, noch consequent in kwaliteit.

De tweede is het implementeren van code in een Quality Assurance omgeving en een testteam vragen om de vereiste tests uit te voeren om de kwaliteit van de service te valideren en wachten tot het team klaar is. Waarschijnlijk zal dit enige tijd in beslag nemen en wordt de release van nieuwe functies uitgesteld vanwege de tijd die het zal duren voordat het testteam klaar is. Vooral als ze de tests niet geautomatiseerd hebben. Deze optie verbetert de kwaliteit, maar mist snelheid

De voorkeursoptie zou zijn om observeerbaarheid op te nemen in de pijplijn wanneer nieuwe code wordt uitgerold. Bedrijven die een CI/CD-aanpak voor softwareontwikkeling hebben aangenomen, hebben de meeste pipeline-tests al opgenomen, zoals unit tests of integratietests. Dit soort tests zijn noodzakelijk, maar testen niet de volledige end-to-end ervaring voor een klant. Deze optie biedt zowel snelheid als kwaliteit.

Om observeerbaarheid te implementeren, zouden we enkele tests moeten toevoegen die de prestaties van een (web)applicatie observeren, bijvoorbeeld door prestatie- en belasting- of stresstests toe te voegen aan de pijplijn. Als we de prestaties meten, weten we wat het verwachte gedrag is van onze applicatie, en als we belasting- en stresstests toevoegen, weten we wat we kunnen verwachten als onze applicatie zwaar wordt belast.

Hoe kunnen we loadtests gebruiken om de prestaties in onze CI/CD-pijplijn te observeren?

In Gitlab moeten we de test definiëren die we willen uitvoeren, bijvoorbeeld zoals hieronder:

• Gitlab CI/CD.
• JMeter.
• Observability tooling.

We will use Gitlab CI/CD to add tests when a new deployment is done, the actual tests will be executed by JMeter and an observability tool where we have our baselines and historic performance data.

In Gitlab we would need to define the test we would like to run, for example like below:

test:
stage: test
script:
- echo 'Start JMeter Test'
- /path/to/your/jmeter/bin/jmeter -n -t observability.jmx -l output.jtl

In JMeter definiëren we onze belasting en de URL’s die we gaan testen. Een test kan worden gedefinieerd als een nabootsing van onze gemiddelde gebruikers of als we willen weten hoe onze applicatie zich gedraagt onder zware belasting, kunnen we een stresstest definiëren.

Met observeerbaarheid kunnen we de prestaties van de applicatie en de onderliggende infrastructuur continu en in realtime meten. Met JMeter kunnen we testverkeer onderscheiden van normaal gebruikersverkeer op basis van een attribuut dat we vooraf definiëren. Er zijn verschillende mogelijkheden om een attribuut te definiëren. We kunnen bijvoorbeeld de onderstaande attributen gebruiken:

Verzoekgegevens zoals de HTTP-header of een Cookie enzovoort.
Metadata die wordt toegevoegd aan de nieuwe deployment.
Payload die aanwezig is in het verzoek.

• Aanvraaggegevens zoals de HTTP-header of een cookie enzovoort.
• Metagegevens die worden toegevoegd aan de nieuwe implementatie.
• Payload die aanwezig is in het verzoek.

Door zo’n attribuut te gebruiken, kunnen we meten wat de impact is van nieuwe code op de applicatie. We kunnen bijvoorbeeld meten wat de impact op de prestaties is. Of als we een stress- of belastingstest uitvoeren, kunnen we meten wat de impact is op de componenten die voor de applicatie worden gebruikt. Hieronder staat een voorbeeld van prestatieverbetering van een component in een applicatie waarvan de functionaliteit bestaat uit het verwerken van bestellingen van klanten.

Links zien we dat de prestaties van het bestellen vaak traag waren. Rechts – onze nieuwe implementatie – zien we dat de responstijd aanzienlijk is verbeterd.

Van een rots naar een veilige plaats: Observabiliteit voor microservices

Als we CI/CD-, test- en observability-tooling combineren in onze pijplijn, kunnen we zien wat de impact is als nieuwe code automatisch wordt uitgerold. Met historische prestatiegegevens kunnen we de nieuwe release binnen enkele uren en niet weken vergelijken met de huidige draaiende code om te valideren of we de verbeteringen zien die we verwachten. En als we een significante prestatieverslechtering opmerken, kunnen we onze implementatie terugdraaien. Als we moeten terugdraaien, kunnen we onze observability tooling gebruiken om snel vast te stellen welk deel van de nieuw geïmplementeerde code verantwoordelijk is voor de verslechtering van onze prestaties en dit herstellen.

Natuurlijk is deze aanpak niet beperkt tot alleen prestaties. We kunnen deze aanpak ook gebruiken om te valideren of de functionele logica van onze applicatie nog werkt, enzovoort. Door observability tooling en geautomatiseerd testen te gebruiken in ons ontwikkelproces, creëren we een directe feedback-loop voor ontwikkelaars. Als nieuwe code wordt ingezet, zijn het resultaat en de kwaliteit direct zichtbaar. Tijd die wordt gebruikt voor het oplossen van problemen of het testen van code door een ander team wordt bespaard en deze extra tijd kan worden gebruikt om te werken aan nieuwe verbeteringen en meer functies.

Dus, gebruik jij observability in je pijplijn?