Hoe werkt Change Impact Analysis in Cloud?
12/09/16 00:42
In maart dit jaar heb ik een Master Risico Management (MRM) afgerond aan de Universiteit van Twente. Mijn afstudeeronderwerp: Cloud (heel trending). Het ging niet zomaar over Cloud, maar over één van de dingen die we doen om de Cloud onder controle en ‘heel’ te houden: Het Change Impact Assessment, CIA voor vrienden. De conclusie: de manier waarop we dat bij ABN AMRO doen werkt niet meer.
Wat is die Cloud eigenlijk?
Dat is een eeuwig punt van discussie. Ik beschouw hier ‘cloud’ als: herbruikbare diensten in de infrastructuurlaag. Niet ‘iedere z’n eigen spul’, maar een ‘one size fits all’. Vergelijk het met Service Oriented Architecture: herbruikbare bouwblokken waarmee je oneindig veel combinaties maakt. Automatisering is het sleutelwoord: je wilt handwerk vermijden.
Hoe is dat anders dan wat we nu doen?
Het grote verschil met vroeger/niet-cloud: met de hand zette je een nieuwe machine in het computercentrum en met de hand zette je die aan. Dan ging je ‘m onderdeel voor onderdeel inrichten. In de Cloud wordt automatisch zo’n nieuwe virtuele machine aangezet, met een operating system, middleware, applicaties en data. Er komt geen mens meer aan te pas. Dat is handig als er één uitvalt: je zet zo een nieuwe aan. Ook als onze machines het druk hebben en tandje moeten bijschakelen is dat fijn.
Easy, toch!?
Nou… dit is complex. Heel complex. Vergelijk het met een huis. Je begint met een fundament (dat is de machine/infrastructuur in de IT). Dan bouw je er de verdiepingen op (operating systems) en dan ga je de kamers maken (applicaties). Je zorgt dat die kamers met elkaar verbonden zijn via deuren (interfaces), gangen (netwerkverbindingen) en trappen (middleware). Dan richt je de kamers in met spullen (data). Dat doe je allemaal één voor één.
Stel je voor dat je dat huis wil hergebruiken en in één keer, meubels en al, opnieuw wilt neerzetten (en uiteraard moet alles meteen goed staan en aangesloten zijn). Dat is dus was we willen met de Cloud. Liefst willen we dan ook nog automatisch een standaard kamer, gang of trap vervangen voor een andere standaard kamer, gang of trap. Lekker snel.
Is Change Impact Assessment dan niet verouderd?
Je hebt die kant-en-klare machines en je besluit dat je iets wilt veranderen (in de applicatie, middleware, het operating system, het netwerk), ofwel je wilt de standaard kamer veranderen. Die verandering moet overal worden doorgevoerd: in het ontwerp, en in de machines die de applicatie gebruiken. En als er onderdelen buiten de applicatie moeten meeveranderen, moet dat ook geregeld worden. Dit is waar Change Impact Assessment om gaat. De vraag: wat gaat er stuk als ik ander behang gebruik, of een andere deur in de kamer zet? Dat assessment doe je aan de hand van je administratie. Daar heb je de machines, applicaties en relaties bijgehouden (je bouwtekeningen).
Die administratie doen we nu nog met de hand. Door de snelheid van opbouwen en afbreken in cloud zal dat onbegonnen werk worden. Tegen de tijd dat een verandering geadministreerd is, is de machine misschien alweer afgebroken. Je zit dus op basis van verouderde gegevens een impact te toetsen.
Oplossing: automatiseren!
Mijn voorstel: laten we het Change Impact Assessment automatiseren. We moeten iets inrichten dat automatisch de impact van een change kan toetsen in alle componenten die door die change geraakt worden. Zodat we vragen kunnen beantwoorden als: wat betekent een nieuwe versie van ons messaging-systeem voor de rest van de systemen?
Een voorbeeld: application deployment
Een activiteit die in een typische Cloud geautomatiseerd is, is application deployment. Daarmee wordt een nieuwe applicatie geconfigureerd en aangezet op de infrastructuur. Application deployment bouwt virtuele machines met daarin een operating system en middleware componenten. Dit alles werkt samen om die applicatiecode te draaien. Hoe doe je een impact assessment –eigenlijk het inschatten van het risico- voor zo’n deployment?
Cue in voor een correcte, up-to-date administratie waarin je de bouwblokken en hun relaties vastlegt (die relaties noem ik ‘topologieën). Die administratie moet automatisch bijgewerkt worden als er wat verandert. Da’s stap één.
Stap twee: standaardiseer de bouwblokken!
Automatische application deployment kan alleen als het samenspel van de componenten die nodig zijn om die applicatie te draaien standaard is; de manier waarop de componenten onderling samen passen is gestandaardiseerd. Als die applicatie immers standaard wil deployen op iets dat helemaal niet beschikbaar is, ben je snel klaar. Application deployment kan alleen geautomatiseerd worden onder twee voorwaarden:
1) we hebben standaarden voor alle componenten die applicaties nodig hebben, en
2) we hebben standaard application topologieën Een voorbeeld van een dergelijke topology zou kunnen zijn: een dubbel uitgevoerde omgeving met een web-frontend, een applicatieserver waarbij een database wordt gebruikt en een backup van alle gegevens.
Het werk verandert niet. Ook zonder cloud doen we heel veel deployments van applicaties. Echter, in een niet cloud omgeving doen we heel veel handmatig, terwijl het in een cloud omgeving geautomatiseerd plaatsvindt.
Richard Bliek.
Wat is die Cloud eigenlijk?
Dat is een eeuwig punt van discussie. Ik beschouw hier ‘cloud’ als: herbruikbare diensten in de infrastructuurlaag. Niet ‘iedere
Hoe is dat anders dan wat we nu doen?
Het grote verschil met vroeger/niet-cloud: met de hand zette je een nieuwe machine in het computercentrum en met de hand zette je die aan. Dan ging je ‘m onderdeel voor onderdeel inrichten. In de Cloud wordt automatisch zo’n nieuwe virtuele machine aangezet, met een operating system, middleware, applicaties en data. Er komt geen mens meer aan te pas. Dat is handig als er één uitvalt: je zet zo een nieuwe aan. Ook als onze machines het druk hebben en tandje moeten bijschakelen is dat fijn.
Easy, toch!?
Nou… dit is complex. Heel complex. Vergelijk het met een huis. Je begint met een fundament (dat is de machine/infrastructuur in de IT). Dan bouw je er de verdiepingen op (operating systems) en dan ga je de kamers maken (applicaties). Je zorgt dat die kamers met elkaar verbonden zijn via deuren (interfaces), gangen (netwerkverbindingen) en trappen (middleware). Dan richt je de kamers in met spullen (data). Dat doe je allemaal één voor één.
Stel je voor dat je dat huis wil hergebruiken en in één keer, meubels en al, opnieuw wilt neerzetten (en uiteraard moet alles meteen goed staan en aangesloten zijn). Dat is dus was we willen met de Cloud. Liefst willen we dan ook nog automatisch een standaard kamer, gang of trap vervangen voor een andere standaard kamer, gang of trap. Lekker snel.
Is Change Impact Assessment dan niet verouderd?
Je hebt die kant-en-klare machines en je besluit dat je iets wilt veranderen (in de applicatie, middleware, het operating system, het netwerk), ofwel je wilt de standaard kamer veranderen. Die verandering moet overal worden doorgevoerd: in het ontwerp, en in de machines die de applicatie gebruiken. En als er onderdelen buiten de applicatie moeten meeveranderen, moet dat ook geregeld worden. Dit is waar Change Impact Assessment om gaat. De vraag: wat gaat er stuk als ik ander behang gebruik, of een andere deur in de kamer zet? Dat assessment doe je aan de hand van je administratie. Daar heb je de machines, applicaties en relaties bijgehouden (je bouwtekeningen).
Die administratie doen we nu nog met de hand. Door de snelheid van opbouwen en afbreken in cloud zal dat onbegonnen werk worden. Tegen de tijd dat een verandering geadministreerd is, is de machine misschien alweer afgebroken. Je zit dus op basis van verouderde gegevens een impact te toetsen.
Oplossing: automatiseren!
Mijn voorstel: laten we het Change Impact Assessment automatiseren. We moeten iets inrichten dat automatisch de impact van een change kan toetsen in alle componenten die door die change geraakt worden. Zodat we vragen kunnen beantwoorden als: wat betekent een nieuwe versie van ons messaging-systeem voor de rest van de systemen?
Een voorbeeld: application deployment
Een activiteit die in een typische Cloud geautomatiseerd is, is application deployment. Daarmee wordt een nieuwe applicatie geconfigureerd en aangezet op de infrastructuur. Application deployment bouwt virtuele machines met daarin een operating system en middleware componenten. Dit alles werkt samen om die applicatiecode te draaien. Hoe doe je een impact assessment –eigenlijk het inschatten van het risico- voor zo’n deployment?
Cue in voor een correcte, up-to-date administratie waarin je de bouwblokken en hun relaties vastlegt (die relaties noem ik ‘topologieën). Die administratie moet automatisch bijgewerkt worden als er wat verandert. Da’s stap één.
Stap twee: standaardiseer de bouwblokken!
Automatische application deployment kan alleen als het samenspel van de componenten die nodig zijn om die applicatie te draaien standaard is; de manier waarop de componenten onderling samen passen is gestandaardiseerd. Als die applicatie immers standaard wil deployen op iets dat helemaal niet beschikbaar is, ben je snel klaar. Application deployment kan alleen geautomatiseerd worden onder twee voorwaarden:
1) we hebben standaarden voor alle componenten die applicaties nodig hebben, en
2) we hebben standaard application topologieën Een voorbeeld van een dergelijke topology zou kunnen zijn: een dubbel uitgevoerde omgeving met een web-frontend, een applicatieserver waarbij een database wordt gebruikt en een backup van alle gegevens.
Het werk verandert niet. Ook zonder cloud doen we heel veel deployments van applicaties. Echter, in een niet cloud omgeving doen we heel veel handmatig, terwijl het in een cloud omgeving geautomatiseerd plaatsvindt.
Richard Bliek.