Onlangs hadden we het over hoe operations van monitoring naar observability moet evolueren, om niet in alerts te verdrinken. Maar observability is minstens even belangrijk voor de ontwikkelaars. Zo krijgt development namelijk een beter zicht op hoe applicaties zich in de productieomgeving gedragen. Hoe geef je je ontwikkelaars die inkijk op de best mogelijke manier?
Development en operations, dat zijn als het ware de bouwers en bestuurders van auto’s. Development assembleert de auto (de IT-applicatie dus, in ons geval). Operations is de chauffeur die met de wagen rijdt. Daarbij krijgt de chauffeur meteen feedback over wat hij doet. Drukt hij het gaspedaal dieper in, dan ziet hij op het dashboard welke impact dat heeft op zijn snelheid. Maar hoe de auto op dat moment reageert, is niet meteen duidelijk voor de autobouwer.
Development wil ook feedback
Operations ziet meteen wat het effect is van de ene of andere functionaliteit, of hoe de applicatie reageert op de aanpassing van een instelling. Development heeft echter ook nood aan die inkijk, om bij te leren over hoe het een ontwikkeling het beste aanpast of een volgende keer beter aanpakt. Voor development gebeurt die inkijk bovendien beter niet louter op het niveau van monitoring – het niveau van pure metrics – maar is observability minstens even belangrijk. De ontwikkelaars moeten in elke stap van het ontwikkelingsproces kunnen onderzoeken wat er fout loopt.
Het probleem is dat ontwikkelaars die inkijk vandaag vaak niet genoeg krijgen. Als ze een melding van een issue ontvangen, willen ze die snel verhelpen, maar kunnen ze niet zelf in de productieomgeving checken wat er aan de hand is. Het enige wat ze dan kunnen doen, is logs opvragen bij operations. Of ze vragen operations vooraf om dashboards over de werking van de applicatie te ontwikkelen – terwijl operations daar eigenlijk geen tijd voor heeft of zelfs niet altijd juist weet wat die dashboards moeten weergeven. Operations heeft de applicaties nu eenmaal niet zelf geschreven én bekijkt ze heel anders dan development.
Om maar te zeggen: developers ondervinden nog te vaak een technische drempel om meteen te kunnen doen wat ze moeten doen. Het hindert hen om snel tot een correcte oplossing te komen. In de praktijk zou development graag meteen elke metric, elke log te zien krijgen, om zo meteen te weten wat de gevolgen van acties en aanpassingen zijn.
Valt daar iets aan te doen?
Jazeker! Bij BRYXX doen we dat met de uitbouw van een monitoring en logging plane in het internal development platform. Die laag bevat enerzijds alle mogelijke data over de werking van de applicaties, al dan niet gestandaardiseerd, aan de hand van opensource-frameworks voor observability, zoals OpenTelemetry.
Anderzijds biedt de monitoring en logging plane moderne observability tooling zoals Grafana, Splunk en Dynatrace, waarmee developers heel makkelijk dashboards ontwikkelen. Die geven dan exact weer wat ze over de werking van hun applicaties moeten weten. Het platform reikt daarvoor trouwens de nodige bouwblokken aan. Naast security by default biedt het platform zo ook monitoring en observability by default, beheerd door een apart platformteam, dat idealiter uit medewerkers van operations en development bestaat.
Efficiëntere samenwerking
Het gebruik van een monitoring en logging plane zorgt ervoor dat de mogelijk wrijving tussen development en operations verdwijnt. Voorheen klaagde operations wel eens dat het in alerts verdronk, terwijl development net te weinig of de verkeerde meldingen ontving. Dankzij de observability tools van de monitoring en logging plane zien operations en development voortaan exact wat ze moeten zien. Zo kunnen ze allebei beter hun job doen: de eindgebruiker de best mogelijke gebruikerservaring bezorgen.