IT dienstverleners zijn het er wel over eens. Cloud computing heeft de toekomst. En die toekomst is inmiddels gearriveerd.  Veel consumenten en bedrijven gebruiken al producten “Uit de Cloud”. Ook overwegen ze bestaande IT diensten naar een Cloud omgeving te migreren. Hierbij spelen nog wel issues als “Safe Harbor“, maar uiteindelijk lijken ook deze bezwaren overkomelijk. Cloud computing belooft dat we “los” komen van de infrastructuur. Dat we ons eindelijk kunnen richten op de kern van de (IT) zaak, namelijk functionaliteit. Tegelijkertijd is het risico dat we verder in infrastructuur verzeilen. De Cloud computing leugen.

Big change

Cloud computing brengt ons vele voordelen. Natuurlijk begrijpen we dat we voor daadwerkelijk gebruik betalen (van Capex naar Opex), dat capaciteit schaalbaar is (scale out en scale in) en dat deployment en management van servers geautomatiseerd is (Puppet of Ansible). Echter achter al deze details gaat de werkelijke verandering schuil. We besteden minder energie aan de infrastructuur. Infrastructuur wordt een gegeven. Het is er en het doet het. Geen disks wisselen, systemen in racks schroeven en netwerkkabels aansluiten. Geen gedoe met ijzer, dat regelt de Cloud provider. Eindelijk kunnen we ons richten op  functionaliteit. Dat is namelijk waar bedrijven en consumenten het voor doen. Niemand draait een operating systeem “just for the fun of it”.

Containers en microservices

Als de nadruk op functionaliteit komt te liggen en de steeds sneller ontwikkelen noodzaak is, dan ligt het voor de hand steeds kleinere stukjes functionaliteit te maken. Dit verklaart de populariteit van de microservices. Maar als gevolg hiervan wordt de overhead van het (gevirtualiseerde) operating systeem relatief wel steeds groter. Container technologie zoals Docker verlaagt deze overhead weer. De onderliggende hardware wordt zo beter benut. Amazon gaat nog een stap verder met de AWS Lambda Model (hier mee lijkt het overigens op Red Hat’s Open Shift). De applicatie draait met nog minder overhead op het onderliggende cloud platform.

DevOps en agile

Het is dan ook niet verwonderlijk dat deze technologische ontwikkelingen een andere manier van werken vereisen. Met het verdwijnen van de infrastructuur en het bijbehorende beheer, komt de DevOps discussie in een ander licht te staan. Het wordt noodzakelijk (maar nu ook  mogelijk) om agile te gaan werken. Microservices worden sneller ontwikkeld en traditionele constructies zoals OTAP verlaten. Spotify bijvoorbeeld, doet software ontwikkeling in tribes. Het een kan niet zonder het ander lijkt wel.

Cloud computing leugen

Sneller software ontwikkelen en minder “last” van de infrastructuur zijn goed nieuws voor bedrijven en organisaties. Kortere doorlooptijden en er efficiënter werken het gevolg. We kunnen ontwikkelen tegen lagere kosten en klanten worden slagvaardiger. Ook betekent het dat IT bedrijven zich eindelijk bezig kunnen houden met alles op, of boven, de infrastructuur. Tenzij je natuurlijk deel wil uitmaken van een steeds kleinere groep infrastructuur specialisten. En dit is de Cloud computing leugen. Veel IT bedrijven die nu bezig zijn met Cloud, zijn eigenlijk bezig met infrastructuur. Is dat nog wel zo interessant?

Puppet is hot. Ik hoor van veel organisaties dat ze bezig zijn met een implementatie van Puppet of die overwegen. Verschillende van onze klanten zijn bijvoorbeeld bezig met de voorbereiding ervan. Toch is het interessant dat het nu zo populair wordt. Mijn collega’s gebruiken het al jaren voor het beheer van onze systemen. Maar blijkbaar is de tijd er nu ‘rijp’ voor.

Maar wat is Puppet? Het is management software waarmee grote aantallen servers beheerd kunnen worden. Het gaat hierbij zowel om het beheer van configuratie files (zeg maar instellingen van de servers) als het beheer van de geïnstalleerde software (packages). Een typische use case voor Puppet is bijvoorbeeld het beheer van virtuele servers in een cloud. Het kan dan gebruikt worden om snel extra webservers te installeren. In Puppet worden recepten (classes) gemaakt waarin de server feitelijk beschreven is.

Deze recepten kunnen ook dynamisch zijn doordat ze scripts bevatten die situatie afhankelijk software installeren. Zo kan een script testen op welk type hardware de installatie plaats vindt en aan de hand daarvan bepalen welke specifieke software (ten behoeve van ILO, DRAC et cetera) geïnstalleerd moet worden. Op iedere te beheren server draait een server proces (puppet.d) dat met de server communiceert. Deze communicatie is versleuteld en er kan ingesteld worden met welk interval de configuratie van de te beheren server vergeleken wordt met de Puppet server.

Ook kan gebruik gemaakt worden van Facter. Met Facter kan informatie van verschillende servers verzameld worden. Deze informatie kan eventueel samen met variabelen gebruikt worden in de recepten. De recepten zijn overigens te nesten zodat ze hergebruikt kunnen worden. Al met al een krachtig stuk gereedschap dat steeds krachtiger wordt naar mate er meer servers beheerd moeten worden. Een andere sterke kant is dat het volledig command line gebaseerd is. Maar de leercurve van Puppet is stijl. Een (open source) alternatief voor Puppet is CFengine.

Enthousiast

Een interessante vraag is waarom de technisch specialisten er zo enthousiast over zijn. Voor een deel is dit te begrijpen omdat technische mensen niet graag dubbel werk verrichten. Wanneer de eerste server is ingesteld en een tweede geconfigureerd moet worden, begint een technisch specialist na te denken of het niet slimmer kan. Puppet is een manier om het slimmer te doen en daar houden ze van. Natuurlijk moeten de recepten gemaakt worden en zonder twijfel wordt het daar complexer van. Maar bij grote aantallen servers scheelt het veel tijd. Daarnaast is een beetje complexiteit voor een technisch specialist een intellectuele uitdaging.

Een andere reden om Puppet te willen gebruiken is dat ze daarmee controle en overzicht verkrijgen. Middels de recepten zijn de configuraties van alle servers beschreven. Dat scheelt behoorlijk als er gedocumenteerd moet worden, een werkje dat niet altijd even leuk gevonden wordt. Bovendien kan eenvoudig de configuratie van honderden servers aangepast worden. Als technisch specialist ben je daarmee ‘in control’.

Als Puppet gecombineerd wordt met GIT kan er versiebeheer uitgevoerd worden op de configuraties. Het voordeel van dit versiebeheer is dat er een roll back kan worden gedaan naar een ‘oude’ configuratie waarvan bekend is dat die werkte en dat alle wijzigingen gedocumenteerd zijn. Er is precies te zien wie, wanneer, wat, heeft veranderd.

Een nog interessantere vraag is waarom bedrijven vanuit het business perspectief gebruik zouden willen maken van Puppet. It-organisaties zien zich tegenwoordig geconfronteerd met een aantal uitdagingen waarbij Puppet mogelijk kan helpen. Om te beginnen moet alles tegen lagere kosten. Met andere woorden het moet efficiënter. Dit is bij uitstek natuurlijk een gebied waarin Puppet zinvol gereedschap is. Mits goed ingericht kan met weinig mankracht een groot aantal servers worden beheerd.

Praktisch

Doordat alle configuraties beschreven zijn kunnen servers ook snel (fysiek danwel virtueel) opnieuw geïnstalleerd worden. Dit is buitengewoon praktisch wanneer een systeem bijvoorbeeld gehacked is. De enige manier om zeker te zijn dat alle ‘achterdeurtjes’ verwijderd zijn, is een herinstallatie uit te voeren. In Puppet is het gehele systeem beschreven waardoor ook de herinstallatie kan snel worden uitgevoerd. De aangewakkerde aandacht voor security de laatste tijd maakt dit een aantrekkelijke feature.

Indien Puppet gecombineerd wordt met GIT, zoals eerder aangegeven, kan historie worden bewaard. Dit betreft een historie van alle wijzigingen die er op servers hebben plaatsgevonden. Vanuit ITIL – een beheermethodiek die veel toegepast wordt – is dit erg interessant. De gedachte achter ITIL is dat 80 procent van alle verstoringen veroorzaakt worden door wijzigingen. Goede documentatie van alle wijzigingen is een eerste stap richting het beheersen en controleren van het veranderproces. Betere beheersing van het veranderproces leidt tot minder verstoringen. Het is duidelijk wat het belang van minder verstoringen is voor de bedrijfsvoering van organisaties.

Puppet is open source software. Dit maakt de instap bijzonder laagdrempelig. Indien organisaties behoefte hebben aan commerciële support dan kan deze onder andere bij Puppetlabs verkregen worden. Er kan dan gebruikt gemaakt worden van de enterprise edition. Deze betaalde versie heeft naast support ook extra’s die het goed bruikbaar maken binnen bijvoorbeeld een VMware-omgeving. In mijn ogen is de populariteit van Puppet wederom een voorbeeld waaruit blijkt dat Linux en open source software steeds meer main stream worden. Het is gereedschap om juist grote aantallen servers te beheren en dat betekent dat er dus grote aantallen Linux servers in gebruik zijn bij steeds meer organisaties.

Al met al prima redenen om het te gaan gebruiken, maar ik vraag me af of er ook redenen zijn om Puppet juist niet te gebruiken?
Dit artikel is verschenen op de site van Computable op 20-03-2012