Fail fast!
23/05/17 00:42
Combineren
Een ongeluk zit vaak in de combinatie van (kleine) dingen. En die combinaties zien we meestal niet aankomen. Eén oorzaak kunnen we makkelijk aan, daar wapenen we ons tegen. Maar worden het twee of meer, dan haken we vaak af. Fukushima was voorbereid op een aardschok, en op een tsunami. Maar niet op de combinatie van tsunami én aardschok[1]. Geldt hetzelfde voor IT? We koppelen steeds meer aan elkaar - componenten, oplossingen, vendoren, afdelingen en organisaties – tot een netwerk, een netwerk van ketens. Hoe lineair zijn de oorzaken en gevolgen dan nog?
De zwakste schakel
Hoe vind je de zwakste schakels? Hoe vind je de O-ring? ... en de kou? ... en vooral hoe vind je het verband daartussen? En liefst vóórdat de zaak explodeert. Hoe vind je snél de oorzaak van problemen, of de oorzaken, de verbanden in honderden systemen, heel veel applicaties, in een cloud, of twee, of meer, virtueel, ergens in de datacenters, of daarbuiten, beheerd door meerdere partijen, met allerlei tooltjes. Waar begin je te zoeken als er iets mis dreigt te gaan? En wie moet er allemaal mee helpen zoeken?
Modelleren en zoeken
Er zijn grofweg twee manieren om verbanden te vinden: modelleren en zoeken. Combineren van die twee kan ook: zoeken in modellen. We doen dit overigens ook al heel lang. We doen ADD’s, Archimate, PSA’s... Maar er gaat iets veranderen. De wereld wordt minder lineair en het wordt dynamischer; het verandert waar je bij staat. Een ADD is al oud voordat ie wordt geschreven, volstrekt onbruikbaar om verbanden te zoeken in real life. Onze werkwijze moet ‘om’. Het moet vooral sneller.
Automatisme
Als we verbanden willen kunnen blijven gebruiken om mogelijke fouten op te sporen in een dynamische niet-lineaire wereld, dan zullen we de verbanden moeten vastleggen en vooral: dan zullen we alle wijzigingen in de verbanden moeten vastleggen[2]. Vliegt er een applicatie van de ene kant van de cloud naar de andere? ... vastleggen. Wordt er capaciteit bijgeschakeld?... vastleggen, alles. En, om dat near-realtime te kunnen doen, zullen we het vastleggen van verbanden moeten automatiseren. En alle wijzigingen in die verbanden... ook automatisch. We houden het anders niet meer bij, het gaat te snel voor handwerk.
Groot denken, klein beginnen
Alle wijzigingen in relaties automatisch bijhouden... voor de relaties tussen applicaties en platform of infrastructuur betekent dit dat alle deployments, failover en elastic scaling automatisch zou moeten gaan. Dat is best een uitdaging. En te groot om in één keer aan te vliegen. We beginnen klein. Allereerst door het provisionen en deployen van platform-componenten te modelleren en te automatiseren in topologiën, patterns, templates of hoe dat ook allemaal heet in een (willekeurige) cloud. Daar zijn vele collega’s al druk mee bezig. En met het automatisch vastleggen in CMDB zijn ook al diverse initiatieven aan de gang. Een volgende stap is het automatiseren van de deployment van hele applicaties, zodanig dat alle verbanden –applicaties, libraries, middleware, operating system, databases, filetransfers, alle O-ringen, etc.- automatisch worden opgeslagen en bijgewerkt.
Nóg kleiner!?
We leven in een wereld van laaghangend fruit, no regret moves, MVP’s en sprints Dus het moet nóg kleiner. We starten met de release en deployment van een hele simpele applicatie, volautomatisch. Alle onderliggende platform componenten worden automatisch geselecteerd, geconfigureerd en gestart. Geen handmatige keuze van OS-en, middleware en andere componenten, maar het automatisch aanwijzen van een standaard set van benodigdheden.
Een lange weg te gaan
Na die eerste stap volgen nog heel veel anders stappen. Tenminste, als we het volhouden. Het vergt namelijk discipline: standaardisatie en eraf blijven! Het vergt veel investeren vooraf: bedenken, uitwerken, realiseren, testen. Niet makkelijk in een wereld van sprints, laaghangend fruit, MVP’s en no regret value add. We moeten het er bovendien over eens zijn dat automatische applicatie deployment de goede weg is. En we moeten het er over eens zijn dat we heel veel niet meer handmatig zouden moeten doen. Immers als we handmatig werken niet als een probleem zien, dan hoeven we ook niets op te lossen, toch?
Een andere route?
Kunnen we stoppen met (van)alles aan elkaar te knopen? Dat denk ik niet. Veel wordt namelijk bepaald door anderen. Een organisatie bedenkt en doet niet in z’n eentje hybrid cloud, blockchain en IoT (zeg maar: alles wat in de automatiseringsgdis staat). Dat komt van buiten... en je kunt het wel een tijdje negeren, maar niet lang. Vaak moét je gewoon volgen. En dan kun je er ook maar beter mee leren omgaan. Niet alleen door vallen, maar vooral door het weer opstaan. Geen ‘fail fast’, maar ‘recover fast’... en daarvoor heb je verbanden nodig.
Richard Bliek
[1] Perrow, C. (2011). Fukushima and the inevitability of accidents. Bulletin of the Atomic Scientists, 67(6), 44-52. [2] Bliek, R. (2016). Change Impact Analysis in Cloud, Universiteit Twente.
Een ongeluk zit vaak in de combinatie van (kleine) dingen. En die combinaties zien we meestal niet aankomen. Eén oorzaak kunnen we makkelijk aan, daar wapenen we ons tegen. Maar worden het twee of meer, dan haken we vaak af. Fukushima was voorbereid op een aardschok, en op een tsunami. Maar niet op de combinatie van tsunami én aardschok[1]. Geldt hetzelfde voor IT? We koppelen steeds meer aan elkaar - componenten, oplossingen, vendoren, afdelingen en organisaties – tot een netwerk, een netwerk van ketens. Hoe lineair zijn de oorzaken en gevolgen dan nog?
De zwakste schakel
Hoe vind je de zwakste schakels? Hoe vind je de O-ring? ... en de kou? ... en vooral hoe vind je het verband daartussen? En liefst vóórdat de zaak explodeert. Hoe vind je snél de oorzaak van problemen, of de oorzaken, de verbanden in honderden systemen, heel veel applicaties, in een cloud, of twee, of meer, virtueel, ergens in de datacenters, of daarbuiten, beheerd door meerdere partijen, met allerlei tooltjes. Waar begin je te zoeken als er iets mis dreigt te gaan? En wie moet er allemaal mee helpen zoeken?
Modelleren en zoeken
Er zijn grofweg twee manieren om verbanden te vinden: modelleren en zoeken. Combineren van die twee kan ook: zoeken in modellen. We doen dit overigens ook al heel lang. We doen ADD’s, Archimate, PSA’s... Maar er gaat iets veranderen. De wereld wordt minder lineair en het wordt dynamischer; het verandert waar je bij staat. Een ADD is al oud voordat ie wordt geschreven, volstrekt onbruikbaar om verbanden te zoeken in real life. Onze werkwijze moet ‘om’. Het moet vooral sneller.
Automatisme
Als we verbanden willen kunnen blijven gebruiken om mogelijke fouten op te sporen in een dynamische niet-lineaire wereld, dan zullen we de verbanden moeten vastleggen en vooral: dan zullen we alle wijzigingen in de verbanden moeten vastleggen[2]. Vliegt er een applicatie van de ene kant van de cloud naar de andere? ... vastleggen. Wordt er capaciteit bijgeschakeld?... vastleggen, alles. En, om dat near-realtime te kunnen doen, zullen we het vastleggen van verbanden moeten automatiseren. En alle wijzigingen in die verbanden... ook automatisch. We houden het anders niet meer bij, het gaat te snel voor handwerk.
Groot denken, klein beginnen
Alle wijzigingen in relaties automatisch bijhouden... voor de relaties tussen applicaties en platform of infrastructuur betekent dit dat alle deployments, failover en elastic scaling automatisch zou moeten gaan. Dat is best een uitdaging. En te groot om in één keer aan te vliegen. We beginnen klein. Allereerst door het provisionen en deployen van platform-componenten te modelleren en te automatiseren in topologiën, patterns, templates of hoe dat ook allemaal heet in een (willekeurige) cloud. Daar zijn vele collega’s al druk mee bezig. En met het automatisch vastleggen in CMDB zijn ook al diverse initiatieven aan de gang. Een volgende stap is het automatiseren van de deployment van hele applicaties, zodanig dat alle verbanden –applicaties, libraries, middleware, operating system, databases, filetransfers, alle O-ringen, etc.- automatisch worden opgeslagen en bijgewerkt.
Nóg kleiner!?
We leven in een wereld van laaghangend fruit, no regret moves, MVP’s en sprints Dus het moet nóg kleiner. We starten met de release en deployment van een hele simpele applicatie, volautomatisch. Alle onderliggende platform componenten worden automatisch geselecteerd, geconfigureerd en gestart. Geen handmatige keuze van OS-en, middleware en andere componenten, maar het automatisch aanwijzen van een standaard set van benodigdheden.
Een lange weg te gaan
Na die eerste stap volgen nog heel veel anders stappen. Tenminste, als we het volhouden. Het vergt namelijk discipline: standaardisatie en eraf blijven! Het vergt veel investeren vooraf: bedenken, uitwerken, realiseren, testen. Niet makkelijk in een wereld van sprints, laaghangend fruit, MVP’s en no regret value add. We moeten het er bovendien over eens zijn dat automatische applicatie deployment de goede weg is. En we moeten het er over eens zijn dat we heel veel niet meer handmatig zouden moeten doen. Immers als we handmatig werken niet als een probleem zien, dan hoeven we ook niets op te lossen, toch?
Een andere route?
Kunnen we stoppen met (van)alles aan elkaar te knopen? Dat denk ik niet. Veel wordt namelijk bepaald door anderen. Een organisatie bedenkt en doet niet in z’n eentje hybrid cloud, blockchain en IoT (zeg maar: alles wat in de automatiseringsgdis staat). Dat komt van buiten... en je kunt het wel een tijdje negeren, maar niet lang. Vaak moét je gewoon volgen. En dan kun je er ook maar beter mee leren omgaan. Niet alleen door vallen, maar vooral door het weer opstaan. Geen ‘fail fast’, maar ‘recover fast’... en daarvoor heb je verbanden nodig.
Richard Bliek
[1] Perrow, C. (2011). Fukushima and the inevitability of accidents. Bulletin of the Atomic Scientists, 67(6), 44-52. [2] Bliek, R. (2016). Change Impact Analysis in Cloud, Universiteit Twente.