iaas – JanWiersma.com

Mestvork&knuppels uit de stal… de ‘cloud’ is down!

Gisteren ging een deel van de Amazon AWS dienst verlening plat. Amazon melde het volgende:

“A networking event early this morning triggered a large amount of re-mirroring of EBS volumes in US-EAST-1,” Amazon said in a status update just before 9 am Pacific time. “This re-mirroring created a shortage of capacity in one of the US-EAST-1 Availability Zones, which impacted new EBS volume creation as well as the pace with which we could re-mirror and recover affected EBS volumes. Additionally, one of our internal control planes for EBS has become inundated such that it’s difficult to create new EBS volumes and EBS backed instances.

De verstoring kwam kort gezegd neer op de uitval van 1 van de Amerikaanse beschikbaarheids zones. De overige zones draaide wel gewoon door. Als gevolg hier van waren ook enkele andere ‘cloud’ services (voornamelijk SAAS), die boven op AWS gebouwd zijn, uitgevallen. Een lijst hier van werd gepubliceerd op http://ec2disabled.com/

Al snel zagen we dat de cloud tegenstanders de mestvorken en knuppels uit de stal hadden gehaald… want ‘de cloud’ had eindelijk zijn ware aard laten zien… en had gefaald.

Dit gebeurde al eerder, zoals mijn DatacenterPulse collega Tim Crawford in zijn blog aanhaalt:

Oct 14, 2009 Microsoft Sidekick Data Loss
Jun 29, 2009 Rackspace Data Center Outage
May 14, 2009 Google Outage
Mar 21, 2009 Carbonite Storage Failure

Ook bij deze uitval stonden mensen op de barricade te schreeuwen dat cloud niet betrouwbaar was. Voor leveranciers (en ICT-ers) waar voor de cloud ontwikkeling een bedreiging is (reëel of niet..), is dit een uitstekende gelegenheid om weer wat FUD rond te strooien. Deze tactiek haalde ik al eerder aan in mijn blog: Controle en Vertrouwen; sleutels voor cloud. Hierbij gaf ik ook aan dat het vertrouwen gemakkelijk geschaad word:

Het vertrouwen in cloud computing is iets wat gemakkelijk te schenden is. Het traditionele datacenter leeft redelijk ‘onder de radar’ als het gaat om uitval. Meestal raakt uitval daar slechts enkele applicaties of een deel van de business. Deze uitval kan wel degelijk een grote impact hebben op de productiviteit van een organisatie maar het zal nooit de mate van negatieve publiciteit krijgen die cloud providers ontvangen.

Een vliegtuig crash komt wel in het nieuws, maar de 1000-en auto ongelukken die zelfde dag meestal niet.

Opvallend was echter ook dat een aantal andere cloud services, waar van bekend is dat ze op AWS draaien, gewoon in de lucht waren. Grootste voorbeelden waren Netflix en Twilio.

Referentie architectuur…

In voorgaande blogs gaf ik ook al aan, dat cloud adoptie en migratie draait om de adoptie van een referentie architectuur van iemand ander. Je gaat aan de slag op een IAAS of PAAS omgeving die door iemand anders ontworpen en gebouwd is. Dit men hun visie en gedachte goed. Je moet je dus aan hun regels houden;

Het begrijpen van de referentie architectuur en ontwerp principes van je cloud leverancier is bijzonder belangrijk. Zowel bij IAAS, als bij PAAS geld dat je applicatie of omgeving ontworpen moet zijn voor deel-systeem uitval. Zoals in de PAAS serie aangegeven: ‘Cloud applications assume failure.’ Soms word dit ondervangen door de aangeboden frameworks, maar je moet dan wel begrijpen hoe deze werken.

Organisaties die niet geraakt werden door de AWS uitval begrepen de architectuur optimaal en hadden hun diensten bij ontwerp en bouw al verdeeld over meerdere geografische beschikbaarheids zones, zoals NetFlix in een presentatie (slide 32-35) eerder liet zien:

Verder zijn er diverse andere mogelijkheden om redundantie in te bouwen in een AWS omgeving. Zie diverse blogs met tips:

Systeem uitval is een dagelijkse realiteit. Rond cloud computing word vaak geroepen dat ‘cloud omgevingen niet kunnen uitvallen’. De realiteit is echter dat cloud infrastructuren ook kunnen uitvallen. Het verschil tussen cloud en traditionele infrastructuur is echter dat cloud nieuwe (technologische) mogelijkheden biedt voor redundantie en het herstarten van de dienstverlening als deze uitval plaats vind.

We moeten dus blijkbaar nog wel leren om gaan met deze nieuwe vormen van beschikbaarheid en disaster recovery (DR) 🙂

De nieuwe overheid i-Strategie… & Cloud

De afgelopen week was er de aankondiging van de nieuwe i-Strategie voor de rijksoverheid, gevolgd door de mededeling dat de overheids-CIO’s dit plan hadden goed gekeurd:

De ict- en informatiestrategie (I-Strategie) van de Rijksoverheid is definitief goedgekeurd door de Interdepartementale Commissie van cio’s (ICCIO). Dat maakte Rijks-cio Maarten Hillenaar bekend op het Digitaal Bestuur Congres 2011. Als laatste stap wordt de I-Strategie nu aan de Tweede Kamer aangeboden. De strategie heeft betrekking op alle ict-voorzieningen voor de bedrijfsvoering van de Rijksoverheid en op een aantal generieke ict-voorzieningen in het primaire proces.

In het kader van de bezuinigingen en de stap naar een kleinere en efficiëntere rijksoverheid, doet onze Rijks-cio wat hij moet doen en komt met een plan voor de noodzakelijke samenvoeging van ICT voorzieningen.

Uiteraard komt ‘cloud’ ook voorbij in de context van de nieuwe strategie. Er schuilen tenslotte veel voordelen in het gebruik van cloud. Zeker als je alle media om de hype heen mag geloven. Ook andere overheden zoals die van Japan en de USA doen aan ‘cloud’.

Nu moet ik bekennen dat ik de exacte inhoud van de i-Strategie niet ken, dus mijn conclusies moet baseren op artikelen uit de diverse (ICT)media. In deze media zie ik echter steeds het zelfde terug komen;

…De strategie grijpt in op alle ict-voorzieningen voor de bedrijfsvoering van de Rijksoverheid alsmede op een aantal generieke ict-voorzieningen in het primaire proces.

…spreekt Hillenaar over de gesloten Rijksoverheid-Cloud. Met het netwerk en de DWR zijn de voorzieningen er om een Rijks-Cloud in te richten van waaruit allerlei centrale toepassingen kunnen worden gefaciliteerd. Daarbij past ook de consolidatie van de huidige 63 datacenters waarmee het proces van vereenvoudiging en standaardisatie verder wordt doorgezet.

UK G-Cloud

In mijn vorige blog rond overheidscloud schreef ik over de Amerikaanse overheid en de manier waar op zij cloud hebben opgepakt. Een nog betere parallel voor het ICT proces dat nu start bij de Nederlandse overheid, is te vinden bij de Engelse overheid. Eind 2010 sprak ik Mike Truran over de ontwikkeling van de UK G-Cloud.

De gekozen hoofdgebieden uit de UK, komen overeen met die in Nederland:

Datacenter Strategy –> al enige tijd punt van Nederlands onderzoek
Open Source, standards –> in Nederland al enige tijd actief met beperkt succes
Public sector network strategy –> beperkt actief in Nederland, bijvoorbeeld de ‘haagse ring’
Common Desktop Strategy –> in Nederland het veel besproken DWR project

Al deze onderdelen zien we in de besproken i-Strategie ook weer terug/bij elkaar komen. Het traject in de UK rond G-Cloud is echter al gestart in 2009. De ontwikkeling van de UK strategie is zwaar beïnvloed door de manier waar op Obama dit in de USA heeft aangepakt; “The Obama effect: The US IT Revolution and the UK.” Zo zien we overheids-IT wereldwijd grof weg dezelfde kant op gaan, maar met duidelijke verschillen in de uitvoering en uitwerking er van.

Traditioneel zijn overheden goede klanten van de grote IT ‘System Integrators’ van deze wereld. Dit alles gaat gepaard met mega contracten en aanbestedingen, waar veel kleine organisaties nooit aan zouden kunnen deel nemen. Dit is ook het geval in de UK, waar veel overheids IT is ge-outsourced naar een aantal grote marktpartijen.

Het is dan ook niet vreemd dat deze staan te trappelen om de overheid een ‘cloud’ te verkopen. Zeker met de huidige economische condities lijkt een aanbesteding voor de bouw en migratie van overheids ICT een zeer welkome bron van inkomsten.

Met behoud van hun (financiële) aandeel willen deze huidige dienst verleners dus ook wel mee werken aan de consolidatie van de overheids spulletjes.

HP was er dus ook snel bij om te melden dat ze een demo omgeving hadden voor de UK overheid waarbij ze de G-Cloud konden laten zien.

Ik kan me zo ook voorstellen dat de telefoon van onze Rijks-cio niet stil staat na de aankondiging van de i-Strategie, en de grote IT leveranciers aan de poort staan te trappelen.

In Nederland lijken we dezelfde route te volgen als de UK, waarbij ‘cloud’ staat voor het bij elkaar zetten (consolidatie) van overheids datacentra en IT infrastructuur en op die manier geld te besparen. Dit is een consolidatie slag die diverse grote bedrijven in de afgelopen jaren ook al hebben afgelegd om hun ICT kosten te drukken. De vraag is echter of we dit momentum niet moeten pakken voor echte verandering en vooruitgang.

Volgende stap?

Zoals Peter Hinssen in zijn ‘New Normal’ beschrijft, geeft cloud ons de volgende stap in de IT evolutie:

[youtube=http://www.youtube.com/watch?v=3ugBwy343Ak&w=448&h=252&hd=1]

De vraag is nu welke volgende stap de overheid moet nemen in zijn IT evolutie. De i-Strategie maakt duidelijk dat er iets moet gebeuren en de Rijks-cio ziet kansen, in wat misschien wel het ‘spoetnik moment’ is voor overheids-IT. Tijd om een sprong vooruit te maken dus…

Better… for less (not: buy more servers… and more licences)

Het UK rapport “Better for Less – How to make Government IT deliver savings.” (PBA) geeft een verfrissende kijk op overheids ICT, innovatie en de juiste manier van markt stimulatie. Het evalueerde de strategie van de UK Gov en de bouw van hun G-‘Cloud’. Het keek ook naar de manier waar op de huidige IT ‘System Integrators’ hun dienst verlening inzetten en het feit dat deze bij grote contracten vooral gebaat zijn bij het handhaven van status-quo en niet bij echte innovatie. Rond het gebruik van cloud diensten beschrijft dit rapport:

Government must stop believing it is special and use commodity IT services much more widely. It must make the most of its tremendous institutional memory and experience to make IT work together across government and it must innovate at an entirely different scale and price point.

…

Government applications and services should therefore be available ‘in the cloud’. Not in a cloud, in the cloud, for the reasons discussed above. This requires a fundamental change in the way government procures its infrastructure, which is currently based on providing an inward-facing ”G Cloud”. It also promotes and encourages the development of smaller, iterative applications that can be used by different departments across government,

De door de Nederlandse Rijks-cio aangehaalde “generieke ict-voorzieningen” zijn meestal commodity ICT en derhalve uitstekend geschikt om uit de cloud als SAAS te halen.

Uiteraard laait hierbij het debat over veiligheid altijd weer op. Hier word echter volop op ingespeeld door de leveranciers van SAAS oplossingen. Vele zijn in het bezit van International Organization for Standardization (ISO) 27001, Statement on Auditing Standards (SAS) 70 Type I and Type, PCI-DSS, HIPAA, etc.. Dit zijn vaak meer audit controls dan dat menig IT afdeling van de overheid kan tonen.

Daarnaast leveren sommige SAAS leveranciers een speciale overheids versie, die aan nog meer (overheids) eisen voldoet, zoals Microsoft BPOS Federal (nu Office 365). Hierbij zijn vaak ook garanties af te geven over de locatie van data.

En de rest…

Uiteraard is niet alle ICT binnen de overheid commodity ICT en blijven we vanuit de veiligheid discussie ook data houden die niet gehuisvest kan worden in de public cloud. Hierbij zal sommige data afhankelijk zijn van wetgeving die ons op dit moment beperkt in de mogelijkheden van cloud gebruik.

Gelukkige bied het cloud model hier ook kansen in diverse smaken (IAAS, PAAS, SAAS) en soorten (Public, Private). (Zie PAAS artikel, eerste deel).

Het bouwen van een private cloud, is daarbij echt iets anders dan enkel de consolidatie van de huidige ICT voorzieningen. Gezien de schaal van ICT bij de gehele Nederlandse overheid, liggen hier kansen om een cloud omgeving te bouwen op de manier waarop de ‘big boys’ dat doen. Zoals in het eerder geschreven artikel Formule 1 van ICT beschreven moet je voor de bouw van een echte private cloud omgeving goed kijken naar de public cloud leveranciers en de manier waar op zijn in techniek en proces hun IT bedrijven. Hoe meer je daarbij cloud standaarden gebruikt, die in de public cloud ook gebruikt worden, hoe beter de overlevingskansen worden voor je ICT strategie op langere termijn. Zoals Forbes recent melde in een cloud do&don’ts:

Don’t use a private cloud without a migration plan to the public cloud. A variety of vendors have bet the farm on the fact that clouds based on proprietary hardware, meaning anything more expensive than the cheapest commodity technology, will always be more expensive than the public cloud as built by Google and Amazon that relies on the cheapest components.

…private clouds must be built on public cloud standards so that the same management systems can be used. In this way, computing workloads can move easily from your private cloud to the public cloud.

…

Don’t let the cloud happen to you. Remember, the biggest impact that the cloud in any form will have will be when it translates into business value. None of the vendors will ever be able to tell you about how to do this. Their story will always be about cost and abstract “flexibility.”

The winners will be the companies that understand how the cloud makes new offers and products possible.

Het is dus van belang om goed te weten wat er komt kijken bij het bouwen van een private cloud. Dit voorkomt te hoge kosten bij de exploitatie van de private cloud en hoge kosten bij toekomstige migratie naar public cloud.

De verdeling van de totale ICT voorziening zal namelijk constant in transitie zijn over de vlakken van public, private, IAAS, PAAS en SAAS: van de huidige ICT, naar meer gebruik van cloud (public&private). Na enige tijd zullen applicaties (en data) uit de private cloud omgeving ook geschikt worden voor een transitie naar de public cloud. Na enige jaren zal de traditionele IT omgeving verdwijnen. De meeste ICT functies zullen uiteindelijk afgenomen worden in de public cloud (80%). Enkele functies zullen nog geleverd worden vanuit de private cloud (20%):

‘Dit gaat even pijn doen’…

De overheid is nooit echt goed geweest in het uitvoeren van hele grote projecten en zeker niet op ICT vlak. Daarnaast zal het best lastig zijn om alle departementen op een lijn te krijgen. ICT hervorming op deze schaal zal ook altijd gepaard gaan met de nodige miljoenen aan investeringen.

Dit zal echter het geval zijn bij elk te kiezen scenario. Zodra we bijvoorbeeld alle departementen gebruik zouden laten maken van 1 (nieuw) datacenter als co-lo omgeving, begint daar de discussie al over niet op elkaar afgestemde beveiligingsmodellen tussen departementen. En dat is co-lo nog de ‘laagste’ vorm van consolidatie.

Ik wil dus niet beweren dat deze transitie naar een ‘overheid & IT 2.0’ makkelijk zal zijn. We bevinden ons in een complexe ICT wereld, waarbij elke migratie pijn zal doen. De vraag is echter of de overheid nu een echte stap vooruit durft te nemen;

Gebruik van public SAAS voor commodity ICT functionaliteit.
Gebruik van off-premises private PAAS/IAAS voor overige ICT functionaliteit.
Gebruik van on-premises private PAAS/IAAS voor gevoelige data en ICT functionaliteit.

Als we dit combineren met stimulatie van innovatie door de markt (zoals in het Better for Less document) en andere manier van applicatie bouw (crowdsourcing), voorzie ik een mooie toekomst voor de overheids ICT en de ‘overheids cloud’.

PAAS & de toekomst van programmeren (3)

In het laatste deel van het drieluik rond PAAS en de toekomst van programmeren enkele afrondende gedachte;

Platform As A Service (PAAS) gaat in de komende periode een belangrijke doorontwikkeling krijgen en daar door een prominentere rol in het cloud portfolio. Zelfs Amazon ziet de kansen op dit deel van de markt en lanceerde deze week de AWS Elastic Beanstalk. Werner Vogels (CTO Amazon) meld in zijn blog:

…developers who do not need control over the whole software stack often use development platforms that help them manage their application development, deployment and monitoring. There are some excellent platforms running on AWS that do precisely this; Ruby on Rails developers have Heroku and Engine Yard, Springsource users have CloudFoundry Drupal developers can use Acquia, and PHP aficionados can sign up for phpfog, just to name a few. These platforms take away much of the "muck" of software development to the extent that most RoR developers these days will choose to run on a platform instead of managing the whole stack themselves.

Gaat IAAS verdwijnen?

Infrastructure As A Service (IAAS) speelt een hele belangrijke rol; het is cruciaal voor een heleboel innovatie op het gebied van PAAS en SAAS. Veel van de huidige startups rond PAAS en SAAS maken gebruik van IAAS oplossingen zoals die van Amazon. Het feit dat deze bedrijven onbeperkte opslag en rekenkracht tot hun beschikking hebben tegen een pay-per-use model levert een belangrijke bijdrage aan hun succes. SAAS oplossingen zoals Dropbox (gebouwd op Amazon S3 storage) en PAAS oplossingen zoals Heroku (ook op Amazon IAAS), hadden bijvoorbeeld grote moeite moeten doen om het benodigde kapitaal bij elkaar te krijgen om hun groei te faciliteren. Denk hierbij aan de CAPEX die nodig is voor hardware en de OPEX voor de tientallen systeembeheerders om dit alles in de lucht te houden.

IAAS zal hierbij voor de eind gebruiker/enterprise IT naar de achtergrond verdwijnen. PAAS en SAAS zijn nu eenmaal de lucratievere modellen voor de CIO.

En SAAS dan?

Zoals eerder beschreven, zullen commodity IT producten zeer geschikt zijn voor Software As A Service. Daarnaast zullen we zien dat een golf aan nieuwe (internet) applicaties, die geleverd worden als SAAS, zullen ontstaan. Dit komt omdat IAAS en PAAS omgevingen ontwikkelaars gereedschap in handen geeft, die ze nog niet eerder hadden. Dit zal leiden tot vele nieuwe innovaties. De aanwezigheid van App Stores, om een applicatie gemakkelijk in te kunnen aan bieden, versterkt dit.

Helemaal geen programmeurs meer?

In de vorige delen werd aangenomen dat de ‘tech-savy’ eind gebruiker met zijn kennis en de nieuwe technologische mogelijkheden, zelf applicaties gaat bouwen met microfunctionaliteit. Dit betekend echter niet dat we geen programmeurs meer nodig hebben. Het werkveld van de huidige programmeurs zal zich wel verleggen.

De leveranciers van PAAS en SAAS omgevingen hebben grote behoefte aan goede programmeurs. Zeker mensen met kennis van Python, Ruby en/of Java worden veel gevraagd door dit soort bedrijven. Deze markt zal dus uitbreiden.

Voor de organisaties waar IT niet de core business is (zoals enterprise IT), zal er in eerste instantie behoefte zijn aan programmeurs voor data ontsluiting. Denk hierbij aan de bouw en onderhoud van API’s. Zeker in de eerst komende jaren zal slechts niet kritische en commodity ICT (&data) naar de public cloud verdwijnen. De bedrijf kritische data zal intern nog ontsloten moeten worden en mogelijk voorzien van een applicatie set. De organisatie zal echter wel eisen van de IT afdeling dat dit gebeurd op een interne cloud omgeving. Daarnaast wil men de mogelijkheid om de applicatie in de toekomst te transporteren naar de (public) cloud. Dit betekend dat nieuwe applicaties dus wel ‘cloud ready’ gebouwd moeten worden.

Binnen enterprise IT zal er daarnaast altijd behoefte zijn aan het in stand houden van legacy omgevingen. Er zijn nog steeds mensen met COBOL bezig en zo zullen er ook nog mensen bezig blijven met interne (legacy) Java en .NET applicaties.

Naar mate er meer mogelijkheden komen voor eind gebruikers om hun eigen (micro)functionaliteit te bouwen, zal de behoefte voor grote interne applicaties afnemen. Daarmee neemt de behoefte aan interne programmeurs ook af. De behoefte aan goede data ontsluiting, via API’s, zal hierbij toenemen. Ook bij de inzet van crowdsourcing voor applicatie bouw, zien we dat de programmeur geen onderdeel meer behoeft te zijn van de organisatie.

Welke skills worden belangrijk voor programmeurs?

Al eerder is aangegeven dat het ontwikkelen van applicaties op een cloud platform iets anders is dan de traditionele IT applicaties. Bij het ontwerpen van een cloud applicatie dient men er rekening mee te houden dat systemen zullen uitvallen in een cloud omgeving. Het ontwerpen rond ‘applicatie redundantie’ is belangrijk. Hierbij werd al eerder opgemerkt: ‘Cloud applications assume failure.’

Het bouwen van cloud applicaties vereist het ontwerpen van stateless applicaties. Zodra er iets niet meer werkt of reageert binnen een cloud omgeving, is het idee dat je deze instance verwijderd (kill) en een nieuwe start. Dat werkt niet als de state ook opgeslagen is binnen deze instance. Ook het concept van een lokale disk is niet aanwezig; er is bijvoorbeeld geen registry. Veel applicatie bouwers hebben vroeger wel geleerd om netjes met ‘state’ om te gaan, maar zijn dit een beetje verleerd omdat de huidige IT dat niet echt afstrafte. Gemakkelijke applicaties zijn vaak stateless. Pas bij de echte interessante applicaties komt een bepaalde mate van state om de hoek kijken. Hier voor zijn in de cloud wel databases en objectstores beschikbaar. Echter de applicatie onderdelen die snel moeten kunnen schalen zoals de web-front-end, moeten stateless zijn.

Daarnaast zijn veel cloud applicaties versplinterd; de applicatie presentatie laag kan bijvoorbeeld op Facebook zijn, de opslag op Amazon S3 en de applicatie logica bij een andere cloud provider. Dit betekend dat er goed nagedacht moet worden over de architectuur, met de nadruk op de schaalbaarheids mogelijkheden die deze platformen bieden.

Voor het vastleggen van de data en state, zijn diverse mogelijkheden in cloud omgevingen die echt anders zijn dan de traditionele IT. Denk hierbij aan de inzet van niet relationele databases. Zowel het Windows Azure platform als de Google App Engine, geven de ontwikkelaar een andere manier om met data om te gaan;

The uses of abstraction and statelessness also have database implications. For example, Azure presents developers with a different perspective on databases than the standard relational model, said Ben
Day, president of Benjamin Day Consulting. The Azure storage engine does not use a standard relational database, so a lot of the stuff you would do if you were developing a standard app using a standard relational database just doesn’t make a lot of sense anymore. An example: the relational database concept of stored procedures, in which query logic is close to the actual data itself. This is no longer applicable in the Azure cloud.

The problem is with Azure is there’s no guarantee that the data that you’re going for lives in any particular location or datacenter or any particular device. You end up writing basically SQL queries against the store because the stored procedures aren’t relevant anymore. Plus, the Azure storage engine is different than the SQL Data Services cloud-based version of SQL Server. As an example, Azure stores a 1MB file as a blob, unlike SQL Server, which stores it in a table.

Bij de Google App Engine, word voor opslag Google’s Big Table gebruikt. Dit is ook geen SQL database. Daarnaast zien we de opkomst van technieken zoals Hadoop voor de verwerking van grote hoeveelheden data.

Daarnaast hebben we de opkomst van diverse nieuwe/andere talen en frameworks. Hierbij zal zullen Java en .NET voorlopig nog niet uitsterven, maar is het wel verstandig voor programmeurs om zich eens te verdiepen in de leidende cloud talen op dit moment.

Op het persoonlijke ontwikkelingslijstje van de programmeur zou dus moeten staan:

Verdiepen in Ruby en/of Python.
Verdiepen in (nieuwe) frameworks i.r.t. cloud (zoals de recente ontwikkelingen rond Springsource).
Verdiepen in API’s (REST, JSON, XML), want dit word je koppelvlak met data uit diverse bronnen.
Verdiepen in andere manieren van data opslag en omgang zoals Hadoop, etc..

Dit alles zou je kunnen starten door eens mee te doen aan lopende prijsvragen voor crowdsource applicatie bouw. Leer je programmeren voor de cloud en misschien hou je er nog een zakcentje aan over 😉

Als ik dit alles zo zie, breken er gouden tijden aan voor programmeurs…

Boek tip: Cloud Application Architectures: Building Applications and Infrastructure in the Cloud (George Reese, 2009)

PAAS & de toekomst van programmeren (1)

Cloud deed het goed in 2010. Vooral rond Software As A Service (SAAS) waren een hoop aankondigen van enterprise organisaties die overstapte. Denk aan Ahold die naar Google Apps ging, diverse US overheid instellingen die naar Microsoft BPOS gingen, maar ook SalesForce zijn CRM deed het weer goed in 2010.

Op de Infrastructuur As A Service (IAAS) waren enkele kleine lichtpuntjes te zien aan de eindgebruikers kant. Zo zetten de Amerikaanse overheid een RPF in de markt voor IAAS. Aan de aanbodzijde zagen we een explosieve groei. Naast de bestaande spelers kwamen er vooral veel hosting en co-lo bedrijven bij die de cloud markt betreden met een IAAS aanbieding. Op het vlak van IAAS kunnen we ook concluderen dat er redelijk wat volwassen technologieën bestaan die het makkelijk maken om een IAAS service uit te rollen.

De inzet van IAAS levert organisaties de mogelijkheid om flexibel opslag en rekenkracht af te nemen. Dit vaak in een pay-per-use model. De eindgebruiker blijft echter nog wel verantwoordelijk voor een hele hoop technisch beheer. Denk aan het besturingssysteem, database en eventuele applicaties. Ook de licenties en onderhoudscontracten hier op zijn voor rekening van de eindgebruiker.

Zoals eerder beschreven hebben we bij de traditionele IT zelf de controle over alles inclusief de, zelf bedachte, architectuur die alle lagen in de IT stack aan elkaar bind. Als we gebruik gaan maken van cloud geven we een gedeelte van deze controle uit handen;

Hoe hoger we in de bovenstaande ‘cloud stack’ (bron: Lori MacVittie) komen; hoe minder de organisatie zelf doet aan de ICT voorziening. Hoe hoger we in de stack komen, hoe dichter we zitten bij de waarde creatie van ICT voor de business; want laten we wel wezen het gaat om de applicatie. Maar ook hoe hoger we in de stack komen, hoe minder eigen controle. Hoe hoger we in de stack komen, des temeer we ons aan standaarden en referentie architectuur van de leverancier dienen te houden.

Bepaalde applicaties, zoals een tekstverwerker, zijn commodity ICT. De functionaliteit voor de tekstverwerker is voor veel bedrijven het zelfde en het is een dus danig uitgewerkt en beschikbaar concept, dat de organisatie er geen competitief voordeel haalt uit het hebben van een tekstverwerker. Dit soort applicatie lenen zich dus uitstekend voor SAAS. Echter niet alle applicaties in een enterprise organisatie zijn commodity. Hier komt Platform As A Service (PAAS) in beeld. Het kent minder restricties (en dus meer controle) dan SAAS, maar minder beheer (en benodigde kennis van de onderliggende infra) dan IAAS. Binnen de PAAS omgeving kan een applicatie ontwikkelaar een applicatie ontwikkelen voor de organisatie zonder zich echt druk te maken over de onderliggende lagen en techniek.

The advantages of PaaS are

Complete abstraction all the way up to development environments and other middleware components, taking the operations out of the picture

Considerable cost savings and faster time to market

Better security. As Chris Hoff pointed out, one could enforce sanitary programmatic practices across the derivate works built upon PaaS

PAAS in beweging.

De markt rond de leveringen op PAAS gebied is volop in beweging. James Urquhart meld in zijn 2010 jaar overzicht;

11. Platform as a Service steps up its game
VMware announced its Cloud Application Platform. Salesforce.com introduced Database.com and its acquisition of Ruby platform Heroku. Google saw demand for developers with App Engine experience skyrocket. Platform as a Service is here, folks, and while understanding and adoption of these services by enterprise IT still lags that of the Web 2.0 community, these services are a natural evolutionary step for software development in the cloud.

We zien VMware bewegen naar PAAS met hun overname van Spring Source en later de samenwerkingen met Google App Engine en SalesForce.com. Microsoft beweegt zich op het PAAS vlak met Azure, Google met App Engine en diverse startups zijn ook erg succes vol met hun PAAS oplossing (zoals Heroku; verkocht voor $212 miljoen).

Veel leveranciers van huidige IAAS oplossingen zien de nadelen van IAAS en voordelen van PAAS… even als hun klanten, die met IAAS nog niet in het beloofde IT landschap komen wat Nick Carr in zijn boek The Big Switch schetst.

Continue with reading

Public&private cloud kosten… schaal is de sleutel…

Microsoft heeft recent een onderzoek uitgebracht genaamd The Economics of the Cloud for the EU Public Sector. Dit stuk is inmiddels uitgebreid besproken en bediscussieerd door de ‘cloud guru’s’ van deze wereld. Het stuk focust zich op de economische voordelen van Cloud computing met grof weg de volgende uitkomst:

– 80% lagere TCO. De combinatie van IT operatie op grote (massale) schaal, bundelen van gelijksoortige vraag en het bedienen van meerdere gebruikers op 1 omgeving creëren enorme schaalvoordelen in public cloud datacentra; “a 100,000-server datacenter has an 80% lower total cost of ownership (TCO) compared to a 1,000-server datacenter.”
– 40x lagere kosten voor MKB; “For organizations with a very small installed base of servers (<100), private clouds are prohibitively expensive compared to public cloud.”
– 10x lagere kosten voor grote (enterprise) organisaties; “For large agencies with an installed base of approximately 1,000 servers, private clouds are feasible but come with a significant cost premium of about 10 times the cost of a public cloud for the same unit of service.”

Deze uitkomsten zijn niet geheel nieuw. In 2009 werd dit ook al vastgesteld door o.a. AT&T. (zie een oude presentatie daar over). Over de kosten voordelen kan men lang en breed discussiëren, maar op het moment dat echte pay-per-use aan de vergelijking wordt toegevoegd slaat de balans snel uit in het voordeel van public cloud.

Als die kosten voordelen zo groot zijn, waarom stapt men dan nog niet massaal over? Dat antwoord is simpel en ligt in de woorden ‘vertrouwen’ en ‘controle’. Als we kijken naar de adoptie barrières voor public cloud zien we o.a. het volgende:

Beveiliging
Volwassenheid (o.a. SLA’s)
Governance
- Data integriteit
- Monitoring
- Audit
- Identiteit en toegang
- Financiële controls
Compliance
- PCI
- SAS70
- Etc..

Al deze bovenstaande redenen voor het niet overstappen, hebben te maken met ‘vertrouwen’ en ‘controle’. Soms is dit vanuit de organisatie zelf (zoals de ‘onvolwassenheid’ van de SLA) en soms vanuit de overheid of andere regulerende instantie (zoals PCI). Deze barrières zullen in de komende jaren steeds meer en meer geslecht worden. Omdat men echter nu al gebruik wil maken van alle geweldige voordelen van cloud, bedachten we iets anders: de private cloud. Wel cloud, maar dan binnen de eigen muur zodat we toch nog controle hebben…

Het Microsoft stuk gaat ook in op de vergelijking tussen private cloud en public cloud;

While private clouds can achieve some degree of cost savings from the scale economies we describe while addressing some governmental concerns about cloud, our analysis reveals there is a price premium associated with private clouds, as the benefits of scale do not apply equally to public clouds and private clouds. Through our analysis, we show that over time the cost of private clouds will increase to be 10x higher than public clouds, while barriers to public cloud adoption will be addressed to a greater degree

Hier is de conclusie dus ook dat de kosten van private cloud hoger uitvallen dan die van public cloud gebruik. Het stuk stelt zelfs de vraag of het bouwen van een private cloud goedkoper is dan outsourcing van bestaande IT… en dat is een interessante gedachte…

Geef me die private cloud!

Rond private cloud bestaat de nodige cloudwash. Dit komt omdat diverse traditionele IT leveranciers zich op de private cloud omgeving hebben gestort als survival strategie en al hun producten als ‘cloud’ bestempelen. Zodra je kiest voor een private cloud word je overspoelt met leveranciers die je kunnen bedienen. In de basis komt het echter op het volgende neer: zelf bouwen of uit de markt halen. Met alle variaties daar tussen.

Als we naar de grote jongens in cloud (Amazon, Google, Microsoft) kijken, zien we dat de echte cloud omgeving is gebouwd op commodity hardware (zoals de Google server) en voornamelijk opensource producten (zoals OpenStack). Dat is voornamelijk een TCO keuze.

Het hebben en beheren van een (private) cloud behelst echter meer. Simon Wardley verwoord dit (zoals altijd) uitstekend:

If you’re building an infrastructure cloud (whether public or private) then I’ll assume you’ve got multi-tenancy, APIs for creating instances, utility billing and you are probably using some form of virtualisation. Now, if this is the case then you’re part of the way there, so go check out your data centre.

IF :-

your data centre is full of racks or containers each with volumes of highly commoditised servers

you’ve stripped out almost all physical redundancy because frankly it’s too expensive and only exists because of legacy architectural principles due to the high MTTR for replacement of equipment

you’re working on the principle of volume operations and provision of standardised “good enough” components with defined sizes of virtual servers

the environment is heavily automated

you’re working hard to drive even greater standardisation and cost efficiencies

you don’t know where applications are running in your data centre and you don’t care.

you don’t care if a single server dies

… then you’re treating infrastructure like a commodity and you’re running a cloud.

Dit alles maakt het een grote uitdaging voor veel organisaties om een echte private cloud te bouwen. Een logische optie kan zijn om bepaalde bouwblokken uit de markt te halen en toch een deel van de voordelen van private cloud te genieten.

Virtualisatie alleen =! Cloud (, maar het helpt wel)

Voor het bouwen van een private cloud helpt virtualisatie. Dit is niet alleen het geval vanuit technologie oogpunt maar ook vanuit de effecten die virtualisatie met zich mee brengt voor organisatie en proces als transitie naar cloud.

Zoals de whitepaper hier over vermeld:

Virtualisatie is GEEN cloud computing, maar het forceert dezelfde wijzigingen op de organisatie. De technologie wijziging is hierbij misschien zelfs minder belangrijk; het is eigenlijk een cultuur wijziging. Virtualisatie forceert de eindgebruiker bijvoorbeeld om de fysieke implementatie van hun dienst los te laten (‘ik wil dit servertje, merk X’) en te vragen om functionele en service termen en beschrijvingen. Veel organisaties hebben geen duidelijke SLA’s beschreven en hebben in plaats daar van constant interactie met hun interne leveranciers om te zorgen voor de juiste levering en het oplossen van problemen.

Converged Infra =! Cloud (, maar helpt wel)

Converged infrastructuur is een ontwikkeling die helpt bij het kiezen van een private cloud bouwblok. Hierbij zien we de samensmelting tussen diverse hardware en infrastructuur onderdelen zoals servers, netwerk en opslag. Hierbij worden deze door de leverancier geïntegreerd geleverd.

Virtualisatie zorgt voor de ontkoppeling tussen hardware en het besturingssysteem, maar neemt het beheer en onderhoud van de hardware laag niet weg. Converged infrastructuur komt hierbij te hulp door een hoge mate van automatisering door te voeren op deze laag. Denk hierbij aan automatische firmware en bios management bijvoorbeeld.

Diverse leveranciers zoals HP, IBM, Dell en Cisco leveren oplossingen in deze richting. Een goed overzicht hier van is te vinden in een whitepaper door Forrester; Are Converged Infrastructures Good For IT?

Meer bouwblokjes…

Met virtualisatie en converged infrastuctuur zijn we er nog niet. Zaken zoals self-service websites, catalogussen en API’s zijn ook noodzakelijk om te komen tot een volledige private cloud omgeving. Een voorbeeld van de benodigde blokkendoos:

Vrij naar apps.gov (klik voor groter formaat)

Hierbij komen diverse leveranciers je te hulp met hun producten. Zowel uit de opensource hoek als uit de proprietary software hoek zijn er diverse producten beschikbaar. Zie hier voor de whitepaper van Forrester: You’re Not Ready For Internal Cloud

Al deze bovenstaande onderdelen leveren uiteindelijk een private cloud omgeving op de Infrastructure As A Service (IAAS) laag in je eigen datacenter. Op deze lAAS laag zijn nu diverse volwassen oplossingen op de markt.

Dit brengt ons bij de volgende stap in de cloud laag; PAAS.

PAAS; hoe hoger in de stack – hoe meer restricties.

Bij de traditionele IT hebben we zelf de controle over alles inclusief de, zelf bedachte, architectuur die alle lagen in de IT stack aan elkaar bind. Als we gebruik gaan maken van cloud geven we een gedeelte van deze controle uit handen;

Deze stap geeft ons dan een referentie architectuur van de cloud leverancier waar we ons aan moeten houden. Deze commitment geeft ons echter wel alle cloud voordelen, die we zo graag willen hebben. Hoe hoger in de IT stack, hoe meer toegespitst op 1 bepaald doel de omgeving word. IAAS levert o.a. generieke rekenkracht en opslag. PAAS levert een specifieke ontwikkel omgeving (bijvoorbeeld JAVA). SAAS levert een specifieke applicatie (bijvoorbeeld Salesforce CRM). Dit alles geoptimaliseerd naar gebruik, met de bijbehorende voor- en nadelen.

IT appliance =! Cloud

In een poging om mee te komen met het cloud geweld van andere leveranciers rond private cloud, gooit Oracle het over een andere boeg. Ze lanceerde recent de Oracle Exalogic. Het idee hierbij is om PAAS te bieden in je eigen omgeving. In feite hebben ze SUN hardware genomen en daar boven op de Oracle Linux en die aangevuld met Oracle middleware, database en Java (ook uit de SUN stal). Al deze bouw blokken bij elkaar kunnen ze uiteraard maximaal optimaliseren aangezien dit uit de eigen fabriek komt. Dit is een single stack benadering en deze lijkt erg op een IT appliance toepassing.

Oracle weet zelf ook wel dat het aanbieden van een IT appliance geen cloud computing is, maar een Single Stack benadering;

Ook zie je hierbij dat je flexibiliteit verliest als je kiest voor een totale geïntegreerde stack oplossing. Nu behoeft deze oplossing geen slechte keuze te zijn als de uitnutting er van voor de organisatie maar optimaal is.

Oracle en andere private cloud leveranciers roepen uiteraard dat hun oplossing schaalbaar is en elastisch. Dat is uiteraard maar ten delen waar. De vraag is bijvoorbeeld in welke eenheden het bouwblok geleverd word. Dit bepaald o.a. de kosten voor de opschaling. Als een bouwblok bijvoorbeeld 100 servers bevat en je hebt er 110 nodig… betekend dat 200 servers… en de bijkomende desinvestering voor de tijd dat deze overige 90 stuks niet gebruikt worden. Ook het afschalen lijkt een uitdaging: komt de leverancier de servers direct weer weg halen uit mijn datacenter, als ik ze niet meer nodig heb ? (echte pay-per-use?!?)

Dit alles lijkt soms opgelost te kunnen worden door lease en huur constructies, maar deze komen altijd met prijs toeslag. Ook geeft deze constructie een uitdaging rond capaciteitsmanagement en de voorspelling van de benodigde capaciteit gedurende de contract looptijd.

Op dit punt zou Microsoft dus wel eens gelijk kunnen hebben dat outsourcing goedkoper is dan een private cloud.

Schaalgrote en innovatie.

Bij alle bovenstaande oplossingen word het al snel duidelijk dat schaal de sleutel is.

Schaal gaat nog een stap verder dan kosten; innovatie is hier ook aangekoppeld. Het collectieve gebruik van public cloud levert meer feedback op en accelereert daar mee de ontwikkeling. De algemene slag kracht van public cloud leveranciers is o.a. hier door ook hoger. Voor de private cloud is het maar zeer de vraag of het opkopen van technologie zoals de huidige IT super-leveranciers nu doen (HP, Oracle, etc..) houdbaar is voor de toekomstige innovatie. Het kopen van een innovatie is een stap, maar het gaande houden van deze ontwikkeling is een hele andere. Dit is waar Gartner recent tegen ageerde;

“Acquiring innovation is one thing, maintaining it is completely different,” said Sondergaard. Integration across an entire stack by one IT provider “is impossible to maintain long term – users will not accept architectural mediocrity,” he added.

Wat dat betreft is er best wat te zeggen voor de route die Cisco, VMware en EMC hebben genomen met hun VBlock oplossing waarbij dit deel van de stack niet onder gebracht is bij 1 leverancier. Ook de route van de Amerikaanse overheid rond apps.gov en OpenStack (NASA) blijkt een valide idee.

Schaal is de sleutel…

De schaal van public cloud is groter dan die van private cloud en dus kosten effectiever. Het neerzetten van een private cloud op IAAS laag geeft meer schaal voordeel dan een PAAS oplossing omdat deze laatste (PAAS) toegespitst is op het leveren van een specifieke dienst en de eerste (IAAS) op een generieke dienst. Hier door zal al snel de schaal van de IAAS omgeving groter zijn en de uitnutting er van beter.

Hoe meer afnemers op het platform, hoe efficiënter de oplossing wordt. Hier mee is public cloud efficiënter dan private cloud en word private IAAS efficiënter dan private PAAS.

Voorlopig nog genoeg stof tot nadenken… met dank aan Microsoft…

Zie ook:

Microsoft offers a refreshing perspective on government clouds

Microsoft Reveals Its Cloud Business Strategy

Private cloud discredited, part 1

Andere mening ? Reageer hier onder of in 140 karakters via twitter @jmwiersma.

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 !