virtualisatie – JanWiersma.com

Nabrander – Groene software; door beïnvloeden van gedrag

Naar aanleiding van de workshop rond groene software, mijn blog en presentatie daar, zijn er nog een aantal zaken die ontbraken in mijn vorige blog of interessante zaken die voorbij kwamen in de discussie.

1. Virtualisatie.

Zoals de heren van Schuberg Philis lieten zien in hun presentatie, zijn veel systeem resources op servers onderbenut. Virtualisatie kan daarbij duidelijk een rol spelen; het zorgt voor betere uitnutting van de beschikbare hardware. Aangezien een server die niets staat te doen (idle is) toch 40-60% van zijn maximale energie consumeert, levert dit dus energie besparingen op.

2. Strippen en tunen van je server OS.

In de discussie kwam de overhead van besturingssystemen aanbod; In de afgelopen jaren zijn besturingssystemen (OS’en) zoals Windows en Linux uitgegroeid tot alleskunners. De leverancier van het OS weet uiteraard vooraf niet wat de klant er op wil draaien. De ene keer kan het een email servers zijn, de volgende keer een database server. Standaard komt een modern OS dus met een waslijst aan services of daemon’s die aan staan. Daar boven op komen vaak nieuwe services van een virusscanner, een inventory tool, monitoring tool, etc.. Al met al gaan er een hoop computer resources verloren met al deze services en deamon’s.

IT Security specialisten leren ons echter ook al jaren dat je server OS’en dient te ontdoen van al deze overhead. Dit maakt namelijk de mogelijke ingangen voor hackers kleiner. Diverse tools van IT leveranciers kunnen hierbij helpen. Ook kan men steeds meer kiezen voor zo geheten virtual appliances. Deze virtuele servers zijn door de leverancier al gestript en taak specifiek gemaakt.

Het strippen en tunen van je server OS na het installeren van zijn specifieke rol is dus een security en (energie) efficiëntie noodzaak.

3. Is energie afname van software wel te ‘zien’ ?

Er was een kritische kanttekening bij het feit of de energie afname van een query wel te zien was;

Systeembeheerders weten al enige tijd dat het systeem wat zijn in beheer gaan nemen voorzien moet worden van een baseline. Hierbij word basis gedrag van het systeem bepaald, zodat er binnen monitoring en beheer applicaties drempelwaarde gezet kunnen worden om het nieuwe systeem in de gaten te houden. Op deze manier worden de beheerders niet onnodig belast met valse meldingen.

Tijdens een goed OTAP proces met performance testen, worden dit soort baselines opgesteld voor hele applicatie ketens. Dit helpt de test&performance analist om te bepalen hoe de applicatie keten werkt en of deze goed werkt. Deze gegevens kunnen later gebruikt worden om de beheerder te voeden voor zijn baseline.

Als men een goede baseline (op een gestripte server) vast stelt, is het zeer goed mogelijk voor een applicatie ontwikkelaar om relaties te leggen tussen de handelingen die zijn code uitvoert en het gebruik van systeem resources.

4. Server energie afname.

Zoals bij 1 aangegeven gaat ook een hoop energie verloren in systemen die niets staan te doen. Tijdens de discussie gaf dit een opening tot de ontwikkeling van efficiënte hardware. Daar heb ik in vorige blogs al een hoop overgeschreven. Wat nog specifiek het vermelden waard was:

OpenCompute project heeft een OpenRack design uitgebracht waarbij o.a. met DC power gewerkt word in het rack. Servers hier voor zullen binnen kort van HP en Dell op de markt komen. Binnen kort meer…

De Schuberg Philis mannen tipte mij nog een Anandtech artikel over een test met OpenCompute server hardware; http://www.anandtech.com/show/4958/facebooks-open-compute-server-tested

5. IT Energie afname is geen focus voor vele.

Al vroeg tijdens de bijeenkomst viel het feit dat energie afname door IT, voor veel bedrijven geen primaire focus zou zijn. Dat is een punt wat ik onderschrijf, zeker voor bedrijven waarbij ICT niet hun primaire product is maar een ondersteuning. Voor veel van dit soort bedrijven zitten hun grote kosten (OPEX) niet in energie.

In 2009-2010 concludeerde diverse mensen en organisaties al dat de adoptie van energie efficiëntie daar door maar lastig op gang komt. Zolang er voor een bedrijf geen grote financiële motivator onder zit, zal het lastig blijven om hier focus op te krijgen.

De opkomst van Cloud computing en met name bedrijven in de IAAS / PAAS sfeer, helpt om holistisch gezien deze efficiëntie slag wel te maken;

Voor de bedrijven die de IAAS/PAAS dienst leveren is het datacenter en zijn energie afname wel een grote kosten post, zeker gezien de schaal grote waar veel van dit soort infrastructuren op worden gebouwd. Het verhuizen en consolideren van IT services uit de bezemkast van niet-IT-bedrijven naar een Cloud computing provider levert op dit vlak dus een juiste prikkel.

Zoals in mijn vorige blog vermeld, krijgen de gebruikers van de IAAS/PAAS diensten ook een goede prikkel om efficiëntie programmeer code te gebruiken. De pay-per-use modellen in veel Cloud computing aanbiedingen zorgen daar voor;

“the art of efficiënt programming is lost… Cloud will bring it back… “

En nu samen; de opkomst van DevOps..

Met grote interesse volg ik al enige tijd de beweging die DevOps heet in ICT land. Deze interesse komt vooral voort uit mijn ervaring met virtualisatie en de veranderende dynamiek die dit bracht binnen beheer teams.

De meeste organisaties hebben hun beheer teams netjes op geknipt in diverse teams, zeker als het wat grotere IT organisaties zijn. Dit levert voor managers en teamleiders lekker behapbare stukjes op om sturing op te geven. We treffen hier dan Windows beheer teams, Unix beheer teams, Linux teams, Netwerk teams, Storage teams, etc.. aan. Bij voorkeur kruipen de mensen uit die teams bij elkaar op de kamer. De Linux mannen met een grote Tux op de kamer, de Windows mannen met een foto van Bill, de netwerk mannen met lastige tekeningen aan de muur met veel streepjes, blokjes en Cisco logo’s. En vervolgens allemaal de deur dicht. Zodra er een probleem optreed, kijken de mensen in de teams naar hun eigen monitor schermpje; “alle lampjes op groen? Mooi! Bij mij niets aan de hand dus”. Voor de Windows beheerder betekend dit dat zijn verantwoordelijkheid ophoud bij de netwerk poort van zijn server, en voor de netwerk beheerder start hij op de netwerk switch. Lekkere duidelijke verantwoordelijkheden en afbakening zou je denken..

Ik zet bovenstaande een beetje zwart/wit neer, maar dit is wel gedrag wat je terug ziet in veel organisaties. Dit geheel gaat voorbij aan het feit dat ICT als hoofd doel heeft om de bedrijfsprocessen te ondersteunen en verbeteren. Dit doel uit zich vaak in een applicatie. Veel applicaties bestaan uit meerdere lagen en elementen. Bijvoorbeeld een Windows server (web & applicatie), een unix server (database), storage en netwerk. Dit leid tot de volgende situatie:

De applicatie van de klant werkt niet. Hij belt. De helpdesk zet op basis van hun beste analyse het probleem door naar de 2e lijn. De vraag komt bij het Windows beheerteam. Hun conclusie “mijn lampjes zijn groen, dus niet ons probleem”. Zo gaat het probleem langs alle teams en iedereen roept dat er bij hun niets aan de hand is. De storing word afgesloten, maar de klant zit nog steeds met het probleem.

Conclusie: de silo benadering werkt dus niet altijd.

Nu gooien we virtualisatie in deze mix. Wie gaat de hypervisor en omliggende tools en lagen beheren ? Introduceren we weer een ander (nieuw) team ? Borgen we dit binnen bestaande teams ? Uiteraard is dit een beetje afhankelijk van de gebruikte hypervisor, zo weten Windows beheerders van nature iets meer van HyperV en Linux beheerder iets meer van KVM. Een mooie discussie uit het verleden ging over het beheer van de virtuele netwerk switch die door VMWare geïntroduceerd is in hun omgeving. Tot de introductie van de Cisco Nexus 1000v was dit geen Cisco device, waar door bepaalde netwerk beheer teams geen beheer wilde doen op de virtuele switch.

Als er problemen optreden in een virtuele omgeving merk je ook al snel dat je de diverse disciplines bij elkaar nodig hebt. Dit zonder grote ‘hand-overs’ of het ‘over de muur gooien’ van het probleem.

Virtualisatie in generieke zin heeft daarnaast nog iets geïntroduceerd; systemen zijn op een software matige (programmeerbare) manier te configureren en beheren. We betreden een tijd perk waarbij men steeds minder fysieke systemen hoeft te ‘stekkeren’ maar dit steeds vaker via een script of programmeer interface kan doen. Zeker waar deze beweging leid tot een groei (van 10 servers nu naar 100 virtuele servers), is de beheerder er steeds meer bij gebaat om een scriptje te hebben die standaard zaken voor hem automatisch kan afhandelen. De programmeer skills van beheerders worden derhalve ook steeds belangrijker en hun werk wijzigt op dat vlak.

Hierbij raken scripts rond virtualisatie (zeker als je self-provisioning in de mix gooit) opeens netwerk, storage en besturingssysteem.

Als management heeft men deze silo’s vaak gecreëerd door de organisatie zo in te delen. Het effect is ook duidelijk en hier mee zijn we een belangrijk doel van ICT een beetje uit het oog verloren…

Ontwikkelaars v.s. beheer

De dynamiek tussen ontwikkelaars, bouwers (Dev) en beheerders (Ops) is van een hele andere orde; Daar waar (applicatie of infrastructuur) ontwikkelaars gedreven worden door ‘change’ zijn beheerders daar nu juist helemaal niet bij gebaat omdat zij gedreven worden door stabiliteit en het handhaven van status quo. De ontwikkelaar heeft als taak om nieuwe functionaliteit toe te voegen of bestaande te wijzigen, waar de beheerder enkel bestaande services aanpast of verbeterd.

Dit alles levert een muur op tussen ontwikkelaar en beheerder die nog veel hoger is dan de muur tussen de silo’s;

Development builds an application, the new hotness which promises customers all the whizz-bang features and will make the company millions. It is built using cutting edge technology and a brand new platform and it has got to be delivered right now. Development cuts code like crazy and gets the product ready for market ahead of schedule. They throw their masterpiece over the fence to Operations to implement and dash off to the pub for the wrap party.

Operations catches the deployment and is filled with horror. The Operations team summarises their horror and says one or more of:

The wonder application won’t run on our infrastructure because {it’s too old, it doesn’t have capacity, we don’t support that version}

The architecture of the application doesn’t match our { storage, network, deployment, security } model

We weren’t consulted about the { reporting, security, monitoring, backup, provisioning } and it can’t be “productionised”.

(Credit Dev2Ops)

Om dit gat te slechten hebben we o.a. vanuit ITIL en andere methodieken inmiddels complete ‘productie gelijke’ test omgevingen ingericht, acceptatie omgevingen, beheer acceptatie omgevingen en test procedures. Dit om de hand-over maar te borgen tussen de ontwikkelaars (Dev) en de beheerders (Ops). Voor de beheer silo’s kennen we tools als HP OpenView en IBM Tivoli die als een beheer paraplu over de silo’s heen kijkt en de end-to-end keten van een applicatie in de gaten houden.

Het is dus zeker niet allemaal kommer en kwel in de IT1.0 wereld want met wat tools en procedures hebben we een soort samenwerking gevonden. In de wijzigende IT wereld behoeven we niet eens heel ver te kijken om te zien dat dit alles echter niet lang houdbaar is. De invoering van virtualisatie levert al aardige voorbeelden op. Uiteraard allemaal best op te lossen met de huidige manier van denken, maar de vraag is of dat het meest effectief is…

DevOps.

DevOps draait om het voor komen van de boven genoemde problemen door slimmer samen te werken en efficiënter te zijn. Het is een framewerk van ideeën en principes die lijden tot samenwerking, coördinatie en kennis uit wisseling tussen ontwikkelaars en beheerders. In een DevOps omgeving bouwen ontwikkelaars en systeembeheerders gezamenlijk aan processen en tools die hun in staat stelt om beter samen te werken en uiteindelijk het ICT product beter en sneller de deur uit te krijgen.

DevOps gaat ook verder dan alleen de uitrol van software; het draait om een nieuwe manier van denken rond samenwerking en coördinatie tussen de mensen die de software bouwen en zij die het moeten beheren. Zaken als automation, monitoring, capacity planning & performance, backup & recovery, security, networking en provisioning hebben allemaal baat bij het DevOps model door de manier waar op ontwikkel en beheer teams samen om gaan met deze gebieden.

Er is dus geen eenduidige definitie voor DevOps, maar in de basis draait het om cultuur verandering en het afbreken van muren die kwaliteits verlies en doorlooptijd veroorzaken.

Veel gebruikte referentie frameworks binnen DevOps zijn Agile en Scrum. De invoering van dit soort methodes die uit de software hoek komen vereisen ook wel een bepaalde cultuur wijziging; het veelvuldig uit brengen van kleine releases voor software (zoals gepredikt word door deze technieken) levert automatisch spanning op bij de beheerders, die dit moeten ontvangen. Nu infrastructuur ook steeds meer te ‘programmeren’ is (o.a. dankzij virtualisatie), zijn beheerders ook programmeurs. Het schrijven van scripts om zaken te automatiseren is al lang niet vreemd meer voor deze groep ICT-ers. Denk aan perl, bash, python en de opkomst van Windows Powershell. De ontwikkeling van Cloud neemt dit nog een stap verder met zaken als Puppet en Chef die de automatisering van de te beheren omgeving naar een volgend niveau brengen. Hierbij zijn beheerders dus ook gebaat bij de inzet van Agile en Scrum.

Beheerder zullen roepen; en wat moeten we dan met ITIL? ITIL en DevOps (en overigens ook Agile, Scrum en andere LEAN adepten) lijken elkaar af en toe in de weg te zitten. Dat is echter maar gedeeltelijk waar en draait vooral om de manier waarop er met ITIL word omgegaan in de organisatie. Daar over in een later blog meer… of Google eens op DevOps & ITIL..

En dan ?

Nu is het altijd mooi om te zeggen dat we beter willen samen werken, maar hoe doe je dat nou ? Enkele voor beelden en tips:

1. Bekijk samen de non-functionals, waar beheerders vaak mee worstelen;

Security
High availibility
Configuration mngt
Monitoring
…

2. Deel de infrastructuur; door elkaar in de keuken te laten kijken kun je werken aan een beter product. Dit betekend bijvoorbeeld ontwikkelaars (read-only?) toegang te geven tot de monitoring van de productie omgeving. Door gezamenlijk te kunnen kijken wat er gebeurd in de productie omgeving start je de communicatie en conversatie.

3. Werk met hoog frequente, kleine wijzigingen; door het uitvoeren van kleine afgebakende wijzigingen kun je probleem gebieden gemakkelijk identificeren en verlaag je de kans op uitval. Daar naast is het makkelijker communiceren en evalueren door alle betrokken partijen uit ontwikkel en beheer teams. Dit alles forceert een goede samenwerking tussen deze teams.

4. Deel verantwoordelijkheid; het afsluiten van SLA’s en OLA’s met als doel naar elkaar te kunnen wijzen als er iets fout is gegaan is contra productief voor de eind-gebruiker. Die is niet geholpen met de kloof tussen ontwikkelaar en beheer en de onderlinge beheer silo’s. Alleen als je de verantwoordelijkheid voor de programmeer code van de applicatie en het uiteindelijke beheer deelt met elkaar kom je tot een voor de klant productieve oplossing.

5. Wissel mensen uit; (zoals bij punt 2) laat een ontwikkelaar eens mee lopen met een beheerder en andersom.

Dit zijn slechts enkele handreikingen en voorbeelden. Er zijn diverse blogs die hier uitgebreid op in gaan. Daarnaast zijn er (steeds meer) bijeenkomsten waar in andere vertellen hoe ze hier handjes en voetjes aan hebben gegeven.

Zie ook:

Voor een uitstekende presentatie zie: Rise of DevOps

De Formule 1 van de ICT…

In 2008 hield ik op AFCOM’s DatacenterWorld in Las Vegas een presentatie over datacenter consolidatie. Ik had de mogelijkheid om de keynote van dit congres bij te wonen, die gegeven werd door Michael Manos (toen nog Microsoft, nu Nokia). Dit was de presentatie waar in Microsoft bekend maakte van de traditionele bouw methode af te stappen en in Chicago een container datacenter neer te zetten. Aan het eind van het congres had ik de mogelijkheid om met Manos na te praten. We bespraken de kritieken die in de pers waren verschenen door de traditionele datacenter leveranciers en de manier waar op hij aan dit out-of-the-box concept was gekomen. We zaten beide op het zelfde punt; het werd steeds slechter te verkopen aan het management dat datacenter ontwerp, bouw en oplevering soms jaren in beslag nam en veel geld kosten. Hierna was het in de lucht houden er van ook nog eens heel duur en complex. Daarnaast leverde de refesh/life-cycle en onstuimige groei van de ICT apparatuur, die gebruik moest maken van het datacenter, ook behoorlijk wat problemen op. Er was langzaam aan een onhoudbare situatie aan het ontstaan.

Er werd mij ook snel duidelijk dat Microsoft bezig was met een explosieve groei rond hun eigen ICT infrastructuur. Een infrastructuur die in hun meeste datacentra een groei van 10.000 servers per maand kende. Als ik om mij heen keek in Enterprise ICT omgevingen zag ik daar ook een behoorlijke groei, maar vooral een groei in complexiteit. Applicaties kennen veel relaties onderling, maar ook relaties met de onderliggende infrastructuur. Er zijn relaties tussen de hardware en software en ga zo maar door.

Toen ik eind 2008 een kijkje achter de schermen kreeg bij Microsoft’s San Antonio datacenter, werd ik geprikkeld door de vraag: “hoe kunnen ze zo’n massale infrastructuur met zo weinig inspanningen uitbreiden en beheren ?”

Uiteraard word er in ICT land meteen geroepen dat dit te maken heeft met het leveren van specifieke diensten; een enterprise IT omgeving dient tientallen diensten en honderden applicaties te ondersteunen, waar een web service leverancier zich kan toeleggen op 1 specifieke levering. Dat argument gaat voor sommige grote cloud leveranciers wel op, maar niet voor allemaal. Microsoft heeft in zijn omgeving Search, BPOS, Hotmail en enkele tientallen andere diensten met allemaal hun eigen IT profiel en karakteristiek. Google heeft dat ook, denk aan Google Apps maar ook Google Voice.

Het andere argument is de schaalgrote. Echter deze zou juist moeten leiden tot zalen vol met ICT beheerders om de boel in de lucht te krijgen en te houden.

Mijn contacten vanuit DatacenterPulse hebben het mogelijk gemaakt dat ik de afgelopen 2 jaar veel kijkjes ‘achter de schermen’ heb mogen nemen en met de engineers en ontwerpers heb kunnen praten van bedrijven zoals eBay, Google, Amazon, Facebook en Microsoft.

Het aardige is dat deze grote IT cloud providers op dit moment de Formule 1 van de ICT wereld vormen. Bij de Formule 1 in de autobranche rijden auto’s en techniek rond die niet betaalbaar is voor de gemiddelde man/vrouw. Uiteindelijk beland er toch technologie die ontwikkeld is in de Formule 1 in de auto’s voor dagelijks gebruik. Zo loopt het ook in de ‘Formule 1 van ICT’; technologie en innovatie die nu bij Microsoft, Google of Amazon word ontwikkeld en gebruikt voor hun eigen basis infrastructuur, is niet direct toepasbaar binnen enterprise IT omgevingen en zeker niet het MKB. We zien echter in het afgelopen jaar al wel technologie door sijpelen naar deze omgevingen.

Een hoop ICT-ers denken echter dat dit alles wel aan hun voorbij gaat. Het is een hype, dus waait wel over. Het aardige is echter dat hun traditionele leveranciers op dit moment wel volop beïnvloed worden door deze beweging.

Deze beweging word gedreven door je eigen CIO/CTO. Als deze kijken naar in-huis ICT dienst verlening rond kosten, efficiëntie van inzet, elasticiteit en schaalbaarheid en dat dan vergelijken met de aanbiedingen en beloftes van uit de cloud… dan gaan ze vanzelf roepen dat ze die cloud voordelen ook willen. Dit moet dan echter wel mogelijk zijn vanuit de interne IT omgeving (private cloud) omdat er, logischerwijs, nog wat koud water vrees is om maar alles buiten de deur in een cloud te zetten.

Dit is dus de vraag waar alle traditionele ICT leveranciers in springen. Die kijken hierbij ook naar de manier waar op de grote cloud jongens dit hebben gedaan. Daarnaast springen ook een hoop opensource leveranciers op deze private cloud trein (Ubuntu, OpenStack, etc..).

Hier mee word de private cloud omgeving een Self-fulfilling prophecy.

We hebben op dit vlak slechts het begin gezien met Oracle’s Exalogic, Cisco/EMC’s vBlock, etc.. Al deze bewegingen zijn gericht op het verkrijgen en behouden van markt aandeel in deze turbulente markt. Op het grensvlak tussen private en public cq intern/extern cloud levering zien we dit gevecht ook met API’s. Leveranciers proberen de klanten in te sluiten door een gesloten omgeving te creëren.

Dit alles maakt het lastig om goede leveranciers en technologie keuzes te maken.

Een recente investeerders blik op de ICT markt stelt zich echter de vraag of de ICT reuzen als HP, IBM en Oracle het wel gaan overleven met de huidige strategie;

In the very near term, companies will continue to invest in their own private cloud-computer systems. That will benefit the traditional tech behemoths that sell servers, storage, personal computers and business software, such as IBM (IBM); HP; Dell; Oracle and Cisco. But the markets already are starting to make longer term distinctions. With the exception of IBM, these stocks have been trading at depressed valuations because they are mature companies, says Paul Wick, technology-portfolio manager at Seligman Investments.

And the clock is ticking for the current giants. The ultimate “public-cloud” model is analogous to power utilities, where computing power would be sold based on usage and need.

Gartner worstelt ook met die vraag;

Smith noted that the companies seen today as enterprise computing leaders, such as SAP and Oracle, aren’t seen as cloud computing leaders; and cloud leaders, such as Amazon, Salesforce, and Google, aren’t seen as enterprise leaders. Over time, they say this will change.

In their view, the cloud computing continuum moves from closed private cloud implementations to full open public ones, with lots of things in between, which include managed private clouds, virtual private clouds, and community private clouds (shared by a few companies).

Het mag duidelijk zijn dat de hele cloud ‘hype’ nogal wat los heeft gemaakt in ICT land. Enterprise IT kan zich niet aan deze ontwikkeling onttrekken, hoe graag sommige dat ook zouden willen. Voor de techneuten is het zaak om goed de Formule 1 van ICT in de gaten de houden en de juiste technologie en methode te ontdekken die toepasbaar is voor de eigen organisatie. Voor het ICT management is het belangrijk om de eigen ICT organisatie voor te breiden met beleid en strategie, op de storm die komen gaat… de donkere wolken pakken zich samen; cloud storm op komst !

Meer Cloud? zie: Whitepapers voor een strategie richting.

Zie ook: Gartner: Will Microsoft and VMware Dominate the Cloud Landscape?

en:

Big companies are quickly adopting new computer networks known as “private clouds.” That may mean trouble for major tech suppliers.