Cloud – Page 4 – JanWiersma.com

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

En dan… die applicatie naar de Cloud toe…

Cloud Applicatie Migratie

Na het doen van de nodige research, lezen van blogs en whitepapers, bezoeken van seminars en praten met leveranciers… heb je nu besloten dat Cloud de stip aan de horizon moet worden voor je organisatie. Maar hoe ga je daar komen ? Hoe hervorm je de huidige IT spaghetti naar deze utopische Cloud wereld ?

De eerder gepubliceerde whitepaper rond cloud strategie geeft aan:

De migratie naar externe Cloud computing heeft een significante impact op een IT organisatie, de leveranciers rol van de IT organisatie en de manier waar op applicaties ontwikkeld worden en gebruikt.
Omdat men groeit vanuit een interne IT omgeving naar meer verbruik van externe Cloud computing omgevingen, moet men rekening houden in de architectuur met samengestelde applicaties.

De whitepaper geeft ook aan dat er verschillende verschijningsvormen van Cloud zijn zoals SaaS, PaaS en IaaS. De stap vanuit de huidige enterpise IT omgeving naar elk van deze verschijningsvormen kent zijn eigen karakteristieken. Een van de beste benaderingen voor cloud migratie is de huidige IT omgeving te bekijken van de applicatie of dienst zijde;

Niet alle applicaties zijn op dit moment geschikt voor een migratie naar een externe Cloud omgeving. Goede kandidaten zijn applicaties die niet missie kritiek zijn, matige tot geen integratie kennen met andere belangrijke applicaties en niet van strategische (competitieve) waarde zijn voor de organisatie. Om beveiligingsrisico’s te verminderen, zou de applicatie ook geen sensitieve informatie moeten bevatten. Naar mate de volwassenheid van externe Cloud omgevingen toeneemt, zullen meer applicaties de stap kunnen maken naar deze omgeving.

Waar de whitepaper vrij snel in gaat op applicaties die potentieel gemakkelijk te migreren zijn, wilde ik dat even in wat bredere context zetten en verkennen: “Cloud Applicatie Migratie, hoe doe ik dat ?”

Een applicatie op een cloud platform is iets anders dan een applicatie in de traditionele IT omgeving. In de recente afscheidsblog van Ray Ozzie ((ex-)Microsoft) schrijft hij over de toekomstige uitdagingen van de nieuwe naadloos schaalbare computing modellen. Het idee dat men ‘zo maar’ bestaande applicaties kan overzetten op dit soort modellen werkt niet. Software vandaag de dag is daar meestal gewoon niet voor gemaakt. Veranderingen rond de user interface (zoals touch screens), data management (zoals niet-relationele data modellen), horizontaal kunnen schalen en zelfs programmeer stijlen (zoals ‘fail-ready’ software) zorgen er voor dat bestaande code meestal niet direct geschikt is voor echte cloud computing omgevingen.

Om te beginnen is een Applicatie Portfolio Analyse de belangrijkste actie. Deze kan echter snel uit de hand lopen als het doel er van niet helder beschreven of begrepen is. Of een applicatie of dienst geschikt is voor een cloud computing omgeving zal getoetst moeten worden door rationalisatie van de portfolio. Deze rationalisatie kent meerdere dimensies, die de applicatie toetsen tegen de karakteristieken van een ‘cloud applicatie omgeving’ en de geschikte migratie optie (private of public cloud) en het geschikte migratie pad (IaaS, PaaS of SaaS) selecteren. Daarnaast dient een kosten analyse de impact op TCO & ROI te bepalen en te helpen om een business case te bouwen.

Bij de rationalisatie van een applicatie voor cloud computing kan men de volgende 4 aandachts gebieden bekijken

(Vrij naar sys-con.com )

Hierbij kan men de volgende indicatieve richtlijnen volgen om te bepalen of een applicatie of dienst klaar is voor cloud;

Elasticiteit kan gemeten worden langs drie parameters: workload, storage, utilization. Het is belangrijk om een dergelijke karakteristiek van de applicatie te hebben zodat bepaald kan worden of en hoe deze op een cloud platform kan landen. Deze gegevens zijn vaak te halen uit monitoring tools of log files in de bestaande omgeving.
Bij een negatieve impact op Governance (SLA, beveiliging, wet en regelgeving, etc..), levert dit meteen een ‘veto’ op om een applicatie of dienst niet naar de public cloud te verhuizen.
De technische haalbaarheid; de impact op de architectuur van de applicatie en de impact op de kwaliteit van de dienst verlening moeten goed overwogen worden.
Functionele toekomstvastheid van de applicatie.

Door het toepassen van een score model op de bovenstaande aandachtsgebieden, zou men goed inzicht moeten krijgen op de cloud geschiktheid van de applicatie of dienst.

Hoewel een public cloud infrastructuur veel voordelen kan beiden (bijvoorbeeld in schaal en kosten) die niet mogelijk zijn in een eigen (private) cloud omgeving, zullen bepaalde applicaties nooit naar de public cloud verhuizen. Dit zal vooral het geval zijn bij de kroonjuwelen van een organisatie; informatie die missie kritiek is of een hoge gevoeligheid heeft.

De business case voor cloud applicatie migratie is niet compleet zonder rekening te houden met het doel platform; private of public cloud. De migratie en overhead kosten variëren behoorlijk bij deze keuze en beïnvloeden daar mee ook de totale besparing die te behalen is. Een goede kosten analyse helpt bij de keuze om een applicatie wel of niet te verhuizen en de te verwachte TCO/ROI.

Kosten analyse zou ten minste CapEx, OpEx en Overhead moeten bevatten. Hier onder kunnen we o.a. de volgende elementen verstaan:

CapEx
- Servers
- Storage
- Backup
- Netwerk apparatuur
- Vastgoed (datacenter)
OpEx
- Energie
- Personeel
- Bandbreedte
- Onderhoud
- Licentie contracten
Overhead
- Migratie kosten
- Skills
- Governance

Applicaties en diensten die worden aangeboden op een eigen (dedicated) infrastructuur zijn goede potentiele kandidaten voor migratie naar een cloud infrastructuur. Het bepalen van de kosten voordelen voor deze applicaties zou redelijk makkelijk moeten zijn. Voor applicaties die een gedeelde infrastructuur kennen, moet er mogelijk een specifieke workload analyse gemaakt worden om de potentiele besparingen te bepalen.

Migratie strategie

Het vast stellen van een applicatie migratie strategie betekend dat men bekend moet zijn met de diverse migratie mogelijkheden, opties en organisatie doelstellingen. De uitdaging zit in de balans tussen organisatie prioriteiten en kosten. Als basis hebben (enterprise) organisaties twee keuzes voor cloud infrastructuren; public en private. Hierbij zijn de volgende migratie paden een optie; IAAS, PAAS, SAAS. De keuze word gedreven door zaken als elasticiteit, business model en information2.0/technologie2.0 strategie (zie: The New Normal). De keuzes worden beperkt door factoren als technische haalbaarheid, beveilging, migratie kosten, etc.. Het is daarom niet ongewoon dat grote organisaties kiezen voor een hybride cloud strategie waarbij men gecontroleerd kan evolueren.

Het is belangrijk om te beseffen dat het werken met een applicatie portfolio rationalisatie die leid tot 1 migratie strategie voor alle applicaties niet behulpzaam is. De migratie strategie zal per applicatie of dienst bepaald moeten worden en door ontwikkelen. Dit na een goede evaluatie van de bekeken applicaties op de eerder geschetste vlakken. De uitdaging op bijvoorbeeld hardware infrastructuur en architectuur gebied die samenhangen met een cloud migratie, moeten onderdeel worden van de totale migratie strategie. Bekijk de dienst of applicatie hierbij vanuit de totale IT stack om zo de samenhang te ontdekken en in kaart te brengen.

Migratie paden

De migratie van een applicatie waarbij men de onderliggende server infrastructuur verhuist naar een public of private IAAS omgeving levert een snelle manier om enkele voordelen van de cloud mogelijkheden te plukken. Dit soort migraties zijn ongecompliceerd door dat het slechts het verhuizen van de host betreft en geen aanpassing in de applicatie code. Het mag echter ook duidelijk zijn dat dit soort migraties slechts een klein deel van de voordelen van cloud computing oplevert. Voorbeeld van bovenstaande services zijn Amazon EC2 of Rackspace.

De migratie naar een echte SAAS architectuur en de hosting daar van op een omgeving die tientallen tot honderden klanten kan bedienen (multi-tenant) levert de grootste kosten voordelen op voor enterprise organisaties. Het helpt ook bij applicatie rationalisatie door applicaties met gelijke functionaliteit samen te brengen en deze enkele SAAS applicatie te bieden op een gedeelde infrastructuur. Migratie van een applicatie naar een volledige SAAS omgeving kan echter een ontmoedigende bezigheid zijn, omdat de meeste applicaties niet geschikt zijn voor deze nieuwe (multi-tenant) cloud architectuur. De beweging naar een SAAS omgeving zal derhalve eerder een vervanging van de bestaande applicatie door een SAAS in houden. Voorbeeld eigen enterprise CRM door Salesforce.com. De sleutel hierbij is het feit dat er gebruik gemaakt word van een basis applicatie code die voor alle honderden klanten word gebruikt en het toestaat om daar boven op specifieke uitbreidingen toe te passen (plugin, mashup of widget).

Als tussen model heeft men PAAS; Leveranciers als Google App Engine en Microsoft Azure leveren een complete cloud IT stack voor software ontwikkeling en levering. Dit levert de mogelijkheid om ‘echte’ cloud applicaties te bouwen en uitleveren op een schaalbare en elastische omgeving. Dit levert echter ook een hoop beperkingen op, op elke technologie laag van de applicatie stack. Vanwege deze beperkingen is het vaak lastig om bestaande applicaties en code over te zetten op deze nieuwe cloud omgevingen. Dit zit soms in de applicatie code en het feit dat programmeurs soms ‘vergeten’ zijn om netjes te programmeren (voorbeeld stateless/statefull). Waar dit in huidige silo IT omgevingen geen problemen oplevert zie je dat dit op gedeelde PAAS en SAAS omgevingen wel een uitdaging geeft. Om deze redenen leent PAAS zich vooral goed voor ‘Greenfield’ acties.

Planning en implementatie

Als we kijken naar een applicatie cloud strategie, word er vaak gekeken naar de technische migratie consequenties. Men moet echter niet vergeten dat de introductie van cloud technologieën ook effect heeft op de organisatie. Bij de migratie moet men rekening houden met het wijzigen van de functie en rol van beheer bijvoorbeeld.

Ook moet men rekening houden met het effect op (bestaande) SLA’s, Service management, onderhouds contracten, door belasting methodes, en skill sets. Hier over in een later blog meer.

Zodra men klaar is om de stap naar een cloud omgeving te maken dient er eerst goed naar de huidige applicatie en diensten porfolio gekeken te worden. Er dienen duidelijke landingsplaatsen gedefinieerd te worden zoals private en public cloud en routes zoals IAAS, PAAS en SAAS. Per applicatie moet bepaald worden of deze afsterft in de huidige infrastructuur en word vervangen door een applicatie in een cloud omgeving. Door het toetsen van de applicatie met behulp van enkele cloud basis elementen en het kijken naar de kosten van de applicatie kan er een route naar de toekomst worden uitgezet met een goede business case.

Dit alles kost de nodige inspanning, maar is noodzakelijk voor het slagen van de cloud transitie.

Zie ook:

‘Moving to’ versus ‘building for’ cloud computing

Hands-on migratie analyse voorbeeld: Migration steps to a private cloud

Het olifantje en zijn data honger..

Nu internet een steeds centralere rol gaat spelen in ons leven en er steeds meer dingen aan internet aangesloten worden, levert dit gigantische hoeveelheden data op. Hierbij zien we steeds meer zaken als sensoren en gps locaties (bijvoorbeeld bij een tweet) in de internet ‘cloud’ beschikbaar komen.

De afgelopen jaren kende we al een explosieve data groei in informatie die door eind gebruikers werd gegenereerd uit websites, ‘homepages’ en later blogs en wiki’s. Marissa Mayer (VP for Search Products bij Google) geeft aan een vijf tienvoudige (!) groei te zien in beschikbare data op internet t.o.v. van 3 jaar geleden.

Binnen IT enterprise omgevingen worstelt men ook al tijden met een data en informatie explosie. Binnen de meeste organisaties zijn tientallen informatie systemen beschikbaar die vaak niet gekoppeld of generiek doorzoekbaar zijn. Men probeert deze informatie te beteugelen door er een datawarehouse , enterprise search en business intelligence (BI) tegen aan te gooien. Deze systemen hanteren meestal een relationele database waar bij men probeert informatie uit diverse bronnen naar binnen te trekken. Hierna kan er analyse en rapportage plaats vinden op deze verzamelde informatie. Feitelijk probeert men 1 grote informatie bak te creëren.

Enterpise IT wil echter ook graag gebruik gaan maken van de informatie die op internet beschikbaar is en daar via diverse bronnen word aangeboden. Analyse op deze data kan het bedrijf een competitief voordeel opleveren;

One big area could be social media analytics: When I was in Armonk in August, IBM VP of Emerging Technologies Rod Smith indicated that the appetite for social media analytics is “huge,” citing one BigInsights customer that is analyzing more than a terabyte of Twitter data per day and maintaining a 30-day archive.

Deze informatie hoeveelheden wil je niet binnen je datawarehouse omgeving trekken; het eindeloos RDBMS systemen er tegen aan gooien levert op den duur een onbetaalbare omgeving op. Zoals database guru Guy Harrison recent melde:

We’ve seen the trend of the size of the largest enterprise databases, growing steadily and exponentially, and data warehouse technology, by and large until relatively recently, kept up with that. The exponential growth has just outstripped what can be done even by the largest databases now. Oracle and Teradata are struggling, but Hadoop’s come along and provided an alternative that’s more economical.

Right at this second, there’s not a lot of our customers who are likely to adopt NoSQL, but there’s a lot of people who will, over the next year or so, adopt Hadoop. The economics for processing large amounts of log data or creating massive data warehouses on Hadoop are cost-effective compared to Oracle’s Exadata.

Hadoop?

Hier komt de ontwikkeling van Hadoop in beeld. Deze verzameling van opensource producten komt voor een groot deel uit de koker van Google, die in 2003 steeds meer moeite had om de groeiende hoeveelheden data op het web te kunnen indexeren en doorzoeken. Ook het analyseren van de index informatie werd steeds lastiger waardoor de kwaliteit van de zoek resultaten achteruit liepen. Om dit probleem te adresseren ontwikkelde enkele Google engineers MapReduce, die samen met Google’s eigen file management technologie voor een oplossing zorgde.

Google heeft de details van MapReduce nooit vrijgegeven, maar heeft wel enkele conceptuele documenten uitgebracht rond deze ontwikkeling. De informatie daar in was voldoende voor Doug Cutting om een eigen ontwikkeling te starten genaamd Hadoop. De echte door ontwikkeling kwam toen Doug Cutting werd ingehuurd door Yahoo, waar binnen 6 maanden Hadoop een van de belangrijkste onderdelen vormde binnen de Yahoo infrastructuur.

De gebruikers lijst van Hadoop is lang en bevat enkele van de grootste informatie verwerkers van deze wereld zoals Yahoo, eBay en Facebook. Deze bedrijven zijn ook volop betrokken in het door ontwikkelen van de Hadoop technologie.

Hadoop =! RDBMS

Hadoop is geen volledige vervanging van de database. Het verwerken van de data in Hadoop kost iets meer tijd, van twee minuten tot twee uur. Dit is aanzienlijk trager dan in de nu beschikbare database technologie. Hadoop kan dus niet wat een database kan, maar de database is weer veel minder schaalbaar.

Voor de analyse op Hadoop is inmiddels een speciale taal ontwikkeld, Hive, die veel lijkt op SQL. Analysten kunnen daarmee vrij snel aan de slag als ze SQL gewend zijn. Voor ontwikkelaars is Pig gemaakt, dat erg lijkt op Python. Door Hive en Pig kan er makkelijk worden gewerkt met Hadoop. Je kunt met Hadoop ook veel beter kijken naar grote hoeveelheden data en er de eigenaardigheden in isoleren. Zo is het heel geschikt voor analyse van bijvoorbeeld klimaatverandering.

Een voorbeeld van directe inzet van Hadoop in een enterprise IT omgeving, samen met bestaande RDBMS:

Meer over dit voorbeeld op: http://www.ebizq.net/blogs/enterprise/2009/09/10_ways_to_complement_the_ente.php. Deze manier word ook gehanteerd binnen Facebook.

Om de diverse tekortkomingen van Hadoop te compenseren word er op dit moment door diverse grote bedrijven hard ontwikkeld aan oplossingen die geschikt zijn om de technologie binnen enterprise omgevingen te laten landen.

IBM heeft de eerste commerciële toepassingen van Hadoop gelanceerd;

IBM on Wednesday is set to announce a new portfolio of solutions and services to help enterprises analyze large volumes of data. IBM InfoSphere BigInsights is based on Apache Hadoop, an open-source technology designed for analysis of big volumes of data.

IBM InfoSphere BigInsights is made up of a package of Hadoop software and services, BigSheets, a beta product designed to help business professionals extract, annotate, and visually uncover insights from vast amounts of information quickly and easily through a Web browser, and industry-specific frameworks to help clients get started.

Ook het bedrijf Cloudera werkt hard aan de commerciële toepassing van Hadoop.

En zo zien we weer een product uit de ‘Formule 1 van de ICT’ in enterprise IT omgevingen terecht komen.

Het mag duidelijk zijn dat er veel ontwikkelingen gaande zijn rond het verzamelen en analyseren van grote hoeveelheden data en dat dit 1 van de grootste uitdagingen voor de volgende generatie van (enterprise) ICT is. Hadoop kan hier een grote rol in spelen; op dit moment als onderdeel van een bestaand RDBMS concept maar op korte termijn zeker breder dan dat.

ICT techneuten tip: houd deze ontwikkeling in de gaten, zorg voor een POC om ervaring op te doen en (her)evalueer eventuele lopende datawarehouse projecten om te kijken of de inzet van Hadoop meer waarde kan leveren.

Goed om verder te lezen:

De volgende generatie aangekondigd?!?:

Beyond Hadoop: Next-Generation Big Data Architectures

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.

Overheidsinnovatie bij NASA

Met lichte afgunst en jalousie volg ik al enige tijd het NASA Nebula project voor Cloud computing.

Nebula is een open-source cloud computing project die een alternatief moet bieden voor de kostbare constructie van datacentra en IT infrastructuur bij de NASA. Nebula levert high performance en direct beschikbare rekenkracht, opslag en netwerk faciliteiten. Dit alles op basis van enkele bestaande en nieuw ontwikkelde open-source componenten.

NASA heeft goed begrepen welke ingrediënten er zo al nodig zijn om deze flexibele infrastructuur en platform te kunnen bieden:

Het fysieke datacenter voor deze oplossing is modulair gebouwd. Hierbij is voor een container gekozen.
De onderliggende hardware bestaat voornamelijk uit het Cisco UCS systeem, welke de rekenkracht en netwerk omgeving dynamisch levert.

Een container bevat ongeveer 15.000 CPU cores of 15 petabyte aan data en het geheel is hierbij tot 50% energie zuiniger dan de bestaande IT omgevingen.

De lagen die boven op de hardware zijn gebouwd, bestaan voornamelijk uit open-source producten. Deze zijn voor een deel uit de markt gehaald en voor een deel zelf ontwikkeld. Voor al op dit laatste vlak word het interessant voor een overheids organisatie zoals NASA;

Het gene ontwikkeld is heeft een hoog innovatief karakter.
De ontwikkelde componenten zijn open-source en worden derhalve ook gepubliceerd en beschikbaar gesteld aan de gemeenschap.
Een deel van de componenten zijn gedoneerd aan de OpenStack (het open-source, open-standaarden Cloud project)
Men gebruikt voornamelijk open standaarden.

Het bovenstaande zijn allemaal karakteristieken die meestal slecht passen bij de bureaucratische en behoudende mentaliteit van overheidsorganisaties.

Ray O’Brien (Nebula Program Manager) schrijft daar over in zijn blog:

Innovation doesn’t always come easily… especially in a large federal government agency. True, rules and regulations are needed to manage behemoth organizations and protect taxpayers, but this always has to be balanced so that creativity and innovation are nurtured, not stifled. The senior NASA managers responsible for the oversight of Nebula understand this key point.

How does Nebula do it? The answer is that Nebula functions more like a tech start-up and less like a legacy organization. Critical to making it work: a phenomenal team of talented professionals and the effective use of modern day communications.

Ik mag een groot deel van mijn werkzame leven al door brengen in overheidsorganisaties.. dus ik herken waar hij het over heeft. Het succes van dit project (onderschreven door de landelijk CIO Vivek Kundra) dwingt dan ook groot respect af. De ontwikkelde Nebula omgeving is ook nog eens de motor onder een groot deel van de Apps.gov omgeving voor diverse overheidsinstellingen.

Een project dat innovatie combineert met groen, flexibel, cloud, open-source, open-standaarden, dynamische infrastructuur en een modulair datacenter… binnen de overheid ?!? Ik meld me meteen aan !