Bij langetermijnwerk winnen bedrijfssystemen vertrouwen of verliezen het. Een betaling kan even wachten. Een voorbereidingsworkflow kan dat niet. Het moet reboots, gedeeltelijke mislukkingen, langzame afhankelijkheden en de rommelige realiteit overleven van operators die proberen te begrijpen wat er is gebeurd terwijl de klok nog loopt. Dit is het moeilijke deel van gedistribueerde applicaties, niet het gelukkige pad. De teams die het goed doen, beschouwen orkestratie niet als achtergrondloodsen. Ze behandelen het als een product met expliciet gedrag, vooral als er iets misgaat.
Anant Agarwal is hoofdingenieur en hoofdtechnisch staflid bij een wereldwijde cloudbedrijfssoftwareleverancier, evenals een IEEE Senior-lid. Zijn werkingsprincipe is eenvoudig en betekenisvol: een workflow-engine moet mislukkingen saai maken, omdat herstel moet worden ontworpen en niet midden in een incident moet worden onderhandeld.
Een herstel dat deterministisch is en niet heroïsch
Als een workflowframework echt werk doet, zal het ook echte resultaten opleveren. Onderzoek uit de sector toont consequent aan dat aanzienlijke storingen veel meer kunnen kosten $ 100.000met ongeveer $ 1 miljoen. Dat is de reden waarom logica voor opnieuw proberen en herstelsemantiek niet kunnen worden overgelaten aan wat elke service ook implementeert. U wilt één plek waar ‘wat er daarna gebeurt’ bekend is, zelfs als het cluster zich niet gedraagt.
Agarwal leidde het ontwerp en de ontwikkeling van een Dynamic Workflow en Distributed Task Orchestration Framework voor een toonaangevend cloud-microservicesbedrijf, gebouwd om langlopende workflows betrouwbaar uit te voeren in Kubernetes. Het ondersteunde dynamische workflowdefinities, opnieuw proberen, opschorten en hervatten, en herstel met efficiënte garanties van precies één keer uitvoering, en ondersteunde bedrijfskritische SDDC-componenten, waaronder NSX, vSAN en VCF. Het platform behaalde een beschikbaarheid van 99,999%, orkestreerde dagelijks tienduizenden gelijktijdige workflows, verbeterde de doorvoer met 30% en verlaagde de operationele kosten door middel van automatisering en deterministisch herstel. Hij komt steeds op dezelfde lat terug: als een operator niet kan voorspellen wat het systeem gaat doen na een storing, is het systeem niet compleet.
“Precies één keer is geen slogan; het is een belofte die je kunt testen”, zegt hij. “Wanneer een knooppunt halverwege de fase sterft, moet de motor opnieuw opstarten en moet de operator kunnen uitleggen waarom.”
Van zichtbaarheid tot snelle diagnose in complexe systemen
Gebaseerd op het idee dat herstel routine moet zijn, is de volgende mislukkingsmodus langzamer en duurder: teams verliezen tijd omdat ze het niet eens kunnen worden over wat ze zien. Gereedschapsspreiding is reëel. In een groot onderzoek uit 2024 89% van de groepen meldde dat ze tussen de twee en tien observatietechnologieën gebruiken, en 15% zei dat ze er zelfs meer dan tien in hun hele onderneming gebruiken. Wanneer signalen over meerdere locaties worden gedeeld, wordt het eerste uur van een incident het zoeken naar logboeken en het wisselen van schermafbeeldingen, en niet het stellen van een diagnose.
In zijn huidige rol bij een grote cloudbedrijfssoftwareleverancier drong Agarwal aan op een gestandaardiseerd observatieplatform gebouwd op AWS CloudWatch, zodat teams konden stoppen met het opnieuw uitvinden van dashboards en hetzelfde operationele beeld konden delen. Hij concentreerde zich eerst op de dekking en breidde de monitoringdekking met 80% uit, zodat het platform zich consistent gedroeg in alle services. Hij werkte ook samen met multifunctionele architecten om veerkrachtige, testbare patronen gemakkelijker toepasbaar te maken in de dagelijkse constructie. Het resultaat was een snellere probleemoplossing, omdat ingenieurs hun onderzoek vanuit dezelfde basislijn begonnen zonder te discussiëren over welk dashboard gelijk had.
“Waarneembaarheid helpt alleen als het consistent genoeg is om minder ruzie te maken. Als elk team op een andere manier instrumenteert, besteed je je incidentbudget aan verwarring in plaats van aan oplossingen.”
Test de Orchestrator alsof het een product is en geen bibliotheek
Zodra u workflows kunt uitvoeren en observeren, is de volgende vraag of u zonder angst wijzigingen kunt doorsturen. In moderne CI- en CD-omgevingen bedraagt de gemiddelde werkstroomduur voor alle vestigingen 2 minuten en 50 seconden, en de gemiddelde hersteltijd na een softwarewijziging minder dan 60 minuten. Deze cijfers klinken snel totdat je je herinnert hoe vaak teams per dag de lus herhalen. Wanneer orkestratielogica centraal staat, is een regressie niet lokaal. Het golven.
In een eerdere rol bouwde Agarwal een Docker-gebaseerd testsysteem voor microservices dat de testcyclustijd met 40% verkortte en de releasebetrouwbaarheid verbeterde. Vervolgens definieerde hij platformonafhankelijke functionele teststandaarden die de consistentie van releases verbeterden en het aantal incidenten verminderden. Dit ging niet over het najagen van perfecte dekking. Het ging over het opbouwen van een gewoonte waarbij elke wijziging in de semantiek van planning, nieuwe pogingen en herstel een manier had om zichzelf te bewijzen voordat deze in productie kwam. Zijn impact op deze kernsystemen werd ook erkend met een promotie van Senior Engineer naar Staff Engineer, een signaal dat betrouwbaarheidswerk werd behandeld als bedrijfskritische engineering en niet als onderhoud.
“Sneltesten zijn geen luxe, het is de manier waarop je het platform eerlijk houdt”, zegt hij. “Als je herstelgedrag niet op een herhaalbare manier kunt valideren, zul je het uiteindelijk op de dure manier leren.”
Workflowdefinities die stabiel blijven naarmate de vereisten veranderen
Zodra de test- en releasediscipline eenmaal aanwezig is, wordt het volgende knelpunt meestal niet berekend; het is de coördinatie tussen systemen die het niet eens zijn over de manier waarop het werk moet verlopen. Handmatig lijmwerk telt op. Uit een onderzoek naar bedrijfssystemen uit 2024 bleek dat organisaties 25 uur per week besteden aan handmatige gegevensinvoer of het afstemmen van gegevens tussen apps en gemiddeld tien verschillende digitale bedrijfsoplossingen gebruiken om hun activiteiten uit te voeren. Het is de omgeving waarin workflowdefinities een product worden, omdat elke overdracht en uitzondering een extra menselijke inspanning wordt.
Eerder in zijn carrière bouwde Agarwal een BPMN 2.0-automatiseringsengine om handmatige workflow-afhankelijkheden weg te nemen en de uitvoering voorspelbaar te maken naarmate processen evolueerden. Hij verminderde de ontwerpoverhead met 60% door repetitieve workflows om te zetten in herbruikbare definities in plaats van eenmalige implementaties. Tegelijkertijd leidde hij de architectuur en ontwikkeling van een configureerbaar, op metadata gebaseerd platform dat door de hele onderneming wordt gebruikt voor alle SAP HCM-producten, waardoor teams hun gedrag kunnen uitbreiden zonder de kernsystemen te herschrijven. Deze keuzes waren belangrijk omdat de HR-modules miljoenen wereldwijde gebruikers bedienden en veranderingen veilig, herhaalbaar en begrijpelijk moesten zijn voor de volgende ingenieur die deze erfde.
“Workflows mislukken in de naden, niet op de goede weg. Als je de definitie expliciet en reproduceerbaar maakt, kunnen teams de vereisten veranderen zonder de bedrijfsvoering te onderbreken.”
Vooruitkijken: workflowmotoren als grens voor kosten en vertrouwen
Vanaf dat moment gaat economie net zo belangrijk worden als mechanica. Verwacht wordt dat de wereldwijde uitgaven voor eindgebruikers in de publieke cloud tegen 2025 723,4 miljard dollar zullen bedragen, dat de verkoop van cloud computing tegen het einde van het decennium naar verwachting zal stijgen tot 2 biljoen dollar, en dat de uitgaven voor datacenters tegen 2030 6,7 biljoen dollar zouden kunnen bereiken. Naarmate een groter deel van deze uitgaven naar complexe, gedistribueerde operaties vloeit, wordt orkestratie zowel duur als grensoverschrijdend. Effectieve planning en deterministisch herstel zijn niet alleen technische voorkeuren; zij bepalen hoeveel capaciteit u nodig heeft en hoe veilig u de productie kunt wijzigen.
Het werk van Agarwal staat stevig in die toekomst. Hij is mede-uitvinder van het Amerikaanse patent “Modelleringskader voor evenementenservices voor computersystemen”en zijn carrière heeft zich herhaaldelijk gericht op het omzetten van gedistribueerde complexiteit in voorspelbare uitvoering, zodat teams kunnen functioneren en evolueren.
“Het doel is niet om de slimste motor te bouwen”, zegt hij. “Het doel is om de uitvoering zo voorspelbaar te maken dat teams snel kunnen handelen zonder de productie te onderbreken.”
