Een stabiele it-infrastructuur onderhouden is een ingewikkelde klus. Het is lastig grip te krijgen op de alsmaar wijzigende configuraties die – handmatig – worden aangebracht, zowel in dagelijkse werkzaamheden als projecten.
Door een gebrek aan inzicht in die wijzigingen ben je bovendien een aanzienlijk deel van de tijd bezig met het corrigeren en bijstellen van de technische configuratie binnen je it-omgeving. Daarnaast is het bijhouden van identieke configuraties tussen ontwikkeling, test, acceptatie en productie, de otap-straat, een arbeidsintensieve klus. Met als gevolg en lange doorlooptijd die complex is om te beheren en ook nog eens foutgevoelig is.
Gelukkig zijn er technologieën beschikbaar die het makkelijker maken de it-infrastructuur te bouwen en beheren: automatisering van de it. Infra-as-code en tools voor het geautomatiseerd testen en deployen helpen bij het omzetten van handmatig werken naar een meer geautomatiseerde manier.
In de ontwikkel-pipeline worden code en een automatische flow gebruikt om nieuwe bouwblokken, zoals een RHEL6 OS of een Oracle 10-database, te ontwikkelen. Specificaties van deze bouwblokken worden uitgeschreven in code, als een recept. Deze zijn vervolgens geautomatiseerd vanuit een catalogus uit te rollen. Hierdoor is de configuratie altijd overal hetzelfde.
De test-pipeline voert geautomatiseerd een groot aantal testen uit op de bouwblokken, testen die voorheen handmatig plaatsgrepen. Vervolgens zorgt de deployment-pipeline ervoor dat elke uitrol zich automatisch uitstrekt over de gehele otap-straat.
Fabriekslijn
Code-recepten besturen dus de it-systemen, net zoals een fabriekslijn bestuurd wordt door een robot. Met een operator die op zijn beurt de robot weer bestuurt. Een andere werkwijze dan we gewend zijn in de reguliere it-operatie. De robot neemt het traditionele onderhoudswerk binnen het platform over. Hierdoor heeft de operator de tijd en mogelijkheid om te innoveren, om de it-omgeving nog slimmer te maken.
It-operations wordt hiermee software-gestuurd. De operator werkt met code en gebruikt nieuwe tools zoals Ansible, Git en Buildkite. Deze software-minded engineer werkt in een devops-team waarin hij zowel de development als operations op de it-infrastructuur uitvoert. Hij gebruikt code om enerzijds het operationele werk te automatiseren, anderzijds om nog meer bij configuratiemanagement onder te brengen zodat wijzigingen via de (ci/cd-)pipeline foutloos in productie komen. Hij kan snel ontwikkelen en door zo vroeg mogelijk in het bouwtraject tegen fouten aan te lopen zijn de herstelkosten laag. Hierbij zorgen de geautomatiseerde testen dat de kwaliteit hoog blijft. Met hands-off it is er dus sneller te leveren op een robuust geautomatiseerd platform, wordt agile werken in een devops-team mogelijk en komt er meer tijd vrij voor innovatie.
Auteur Marianne Faro is managing director bij Itility.
(Deze bijdrage verscheen eerder in Computable-magazine #01/2019)
Dat er vandaag de dag legio tools zijn om genoemde problematiek te automatiseren en vergemakkelijken is absoluut waar.
Maar ik zie hier ook het gevaar van “a fool with a tool is still a fool” …. als je nu al geen grip hebt op wie, wat, wanneer en waarom wijzigt, waarom zou je dat dan wel hebben met deze tools?
Het wordt weliswaar wat inzichtelijker wie wat gedaan heeft, maar als je de processen rondom configuration- en change-management niet goed ingericht hebt, blijft het ook met zulke tools een uitdaging controle te houden over je omgeving.
Nieuwe tools als Ansible bieden automatiseringsmogelijkheden zoals het up-to-date houden van images, templates en onderliggende infrastructurele firmware, maar er zit nog een proces voor de uitrol. De maintenance orchestration in de vorm van change management binnen het stackbeheer gaat namelijk om de regie waarin uiteindelijk nog altijd veel handwerk zit.
CI/CD pijplijnen van DevOps zijn geen stack. Vaak ontbreekt binnen een SDDC concept een inzichtelijkheid aangaande de afhankelijkheid van fysieke componenten. De abstractie van virtualisatie is nog wel te herleiden tot de resource belasting van een server, maar betreffende het netwerk en de storage wordt het al wat lastiger. En een QA-proces binnen DevOps levert dan ook geen voorspelling op aangaande resource belastingen. De rode innovatie van kostenbesparing in de vorm van efficiëntie verbeteringen mist dan ook bij het agile werken.
Pa vindt dat SCM-tools de regie en bedrijfsprocessen niet automatiseren.
Ewout vindt dat software-defined juist inzicht in hardware-afhankelijkheden vertroebelt.
En dan de auteur met RHEL6 en Oracle 10. Tja, het gaat er ook nog om welke software je wilt automatiseren.
Automatisch de verkeerde ouwe meuk om verkeerde redenen foutief configureren en dan wordt het ook nog allemaal trager.
In korte iteraties azijnzeiken.
Heerlijk.
@Dino
Ewout vindt dus ook dat de auteur te weinig aandacht geeft aan automatisering van de regie, lees nog maar eens goed mijn eerste alinea in voorgaande reactie. Daarnaast vind ik het nieuwe paradigma van Agile dus als dezelfde fouten in korte iteraties blijven herhalen, het blijft kleuteren in de zandbak. Automatiseren gaat vooral om het behalen van een efficiëntie verbetering door een bezuiniging op conjuctuurgevoelig arbeid. Dus als je twee keer handmatig hetzelfde doet dan doe je het één keer verkeerd. Vul zelf maar in hoe vaak hetzelfde gedaan wordt binnen DevOps als je 6 verschillende versies van 12 applicaties die functioneel min of meer hetzelfde doen gaat onderhouden.