Van IJzeren tijdperk naar Infrastructure as Code

Posted on Posted in BCONN Nieuws

Zelf ben ik opgegroeid in het ‘ijzeren tijdperk’ van de ICT waar het uitrollen van een nieuwe applicatie begint met het vinden van een fysiek stuk hardware waar het op kan draaien. Eerst zal moeten worden bepaald aan welke eisen deze hardware moet voldoen, vervolgens moet het worden aangeschaft, afgeleverd, en worden ingepland om te worden geconfigureerd volgens de specificaties van de applicatie, in het netwerk worden opgenomen en tot slot kan de applicatie op de hardware worden geïnstalleerd. Kortom een langdurig, tijdrovend en omslachtig proces.

Vandaag de dag leven we in het ‘cloud tijdperk’ en, hoera, het gebruiksklaar maken van een server is een kwestie van seconden waarbij je alleen een creditcard en een internetverbinding nodig hebt. De schroevendraaier kan achterwege blijven!
De infrastructuur die ons nu ter beschikking staat is volledig dynamisch en kan volledig worden opgebouwd met software commando’s.

Dit jaar bezocht ik een seminar van Platform Outsourcing Nederland (PON) dat in het teken stond van Cloud en Regie. Hier vertelde een grote zuivelfabrikant hoe zij grote delen van hun infrastructuur aan het migreren zijn naar Amazon Web Services (AWS). En zij deden dit aan de hand van Infrastructuur as Code, of te wel IaC, één van die nieuwe ontwikkelingen, methodologie, die op dit moment een hot item is, dan wel wordt.

Waarom Infrastructure as Code?
Het hele idee achter IaC is dat ICT-apparatuur, die normaal gesproken is bedoeld om software op te draaien, zelf uit software is opgebouwd, programmeerbare infrastructuur dus. Al enige jaren is al duidelijk een trend zichtbaar dat er steeds meer geautomatiseerd wordt en steeds minder menselijke interactie nodig is. Virtualisatie heeft dit alles mogelijk gemaakt. Een VMware omgeving voor ontwikkelaars opbouwen is een kwestie van 15 tot 20 minuten.

IaC is een infrastructuur provisioning proces waarbij systemen automatisch worden opgebouwd, beheerd en aangeboden (provisioned) als code. Een volledig programmeerbare infrastructuur dus. Voordelen: snelheid en het voorkomen van menselijke fouten… mits de code eenmaal goed is!

 

IaC is een typisch delivery model voor het beheren van IT-infrastructuren in de cloud. Infrastructurele componenten worden behandeld als software wat als voordeel heeft dat het, naast veilig en betrouwbaar, snel en gemakkelijk te wijzigen is.

Omdat er code wordt gebruikt voor het automatisch laten aanmaken en configureren van virtuele machines heb je een snelle en herhaalbare methode om dat proces te repliceren.
IaC dicteert welke infrastructuur wordt geproduceerd, dus in plaats van handmatig een aantal servers te configureren doet de IaC code dat.

Welke voordelen zijn er nog meer?
Naast alle efficiency voordelen en de herhaalbaarheid biedt IaC nog meer. Bijkomend voordeel is dat de ontwikkelde scripts ook gelijk de documentatie voor de applicatie infrastructuur vormen, het leest als een netwerkdiagram. Ook zorgen de scripts voor een consistent vertrekpunt voor deployments. Een ander groot voordeel is dat configuratie code het doorvoeren van wijzigingen veiliger maakt waardoor upgrades van applicaties en de systeemsoftware minder risicovol worden. Fouten kunnen sneller worden gevonden en opgelost en in het slechtste geval kan alles in een keer worden hersteld met de laatst werkende configuratie.

Hierbij is het wel van belang dat je iedere keer de gehele infrastructuur uitrolt en niet zaken toevoegt aan een bestaande infrastructuur. Dit creëert onderlinge afhankelijkheid en kans op fouten die later weer lastig te herstellen zijn.

Het hebben van een version-controlled infrastructuur helpt ook bij auditing en het zorgen voor compliancy.

Welke tooling heb je hiervoor nodig?
Om een volledig programmeerbare infrastructuur mogelijk te maken zijn natuurlijk de benodigde tools benodigd. Deze worden ook wel Continious Configuration Automation Tools genoemd en worden dan, zoals de naam ook wel doet vermoeden, gebruikt voor het geautomatiseerd uitrollen en configureren van settings en software voor zowel fysieke als virtuele componenten.

Binnen Continious Configuration Automation onderscheiden we globaal twee methodes, te weten de push- en de pullmethode. Het grootste verschil tussen deze twee methodes is de manier waarop de infrastructuurcomponenten worden geconfigureerd.

In een pull model halen de afzonderlijke componenten hun implementatie- en configuratietaken vanaf een centraal punt op. In een push model werkt dit juist andersom en worden de implementatie- en configuratietaken vanaf een centraal punt naar de componenten toe gedistribueerd.

Voorbeelden van tooling op dit moment zijn:

Ansible: https://www.ansible.com
CFEngine: https://cfengine.com/
Chef: https://www.chef.io/chef/
Otter: https://inedo.com/otter
Puppet: https://puppet.com
Saltstack: https://saltstack.com
en Powershell DSC (Desired State Configuration):
https://docs.microsoft.com/nl-nl/powershell/dsc/overview

En voor 2018?
Een van de voorspelde trends voor het komende jaar is dat Software Defined Networking nu echt van de grond gaat komen. Of het nu gaat om het beheer van de computing-omgeving, storage en networking, steeds meer wordt geautomatiseerd door slimme software en niet door de hardwarecomponenten. Naar verwachting maken grote ondernemingen de keuze voor technologie die zorgt voor flexibiliteit, inzicht en performance. Op deze manier ligt de weg open voor de software-defined enterprise!

Wil je hierover meer weten? Laat het ons weten!

Peter Leijdsman, consultant: peter.leijdsman@bconn.nl
Robert Verdam, technisch consultant: robert.verdam@bconn.nl