zaterdag 10 november 2012

Hoe bouw je een enterprise cloud?

In veel van mijn artikelen heb ik mij gericht op het consumeren en adopteren van cloud computing vanuit een gebruikers kant. Nu wil ik wat handvatten geven voor organisaties die nu juist aan de kant van de cloud computing provider zitten en cloud (computing) diensten aan klanten willen aanbieden. Of dit nu private of public cloud is maakt in feite niet veel uit. Het gaat om het aanbieden van schaalbare rekenkracht en data met een hoge mate van zelfbediening.

OS
Waar bestaat een cloud computing dienst uit? In ieder geval uit één of meerdere (delen van) datacenters vol met servers en de aanwezigheid van veel stroom en bandbreedte. Zoals je wellicht weet is een belangrijk onderdeel van cloud computing virtualisatie. Fysieke servers hebben een tussenlaag (hypervisor) die het mogelijk maakt om een virtuele servers te ondersteunen. Om een fysieke server in de gewenste cloud omgeving te kunnen gebruiken moet er een gezagsverhouding bestaan tussen de server en een centraal punt die controle heeft over alle servers. Zo’n centraal punt -welke ook op één of meerdere servers staat- is uiteraard wel meer dan dubbel uitgevoerd om ook hier schaal mogelijk te maken en faalkansen te minimaliseren. Dit centrale systeem is in feite het operating system (OS) voor deze “farm” van fysieke servers.

Bij de dienst Windows Azure van Microsoft heet het centrale OS Windows Azure Fabric Controller (FC) en dit draait overigens op Windows Server 2008 en nu ook op Windows Server 2012. Als je als gebruiker een virtuele server aanvraagt gaat de FC kijken in welk rack er plaats is en deze controleert ook of deze virtuele server “opkomt” en klaar is voor gebruik.

OpenStack is een open-source cloud computing OS en de centrale dienst die bij Windows Azure Fabric Controller heet, wordt bij OpenStack Nova genoemd. Een ander voorbeeld is OpenNebula welke ook open-source is.

Om niet al te diep in techniek te duiken; het mag duidelijk zijn dat de kwaliteit van je cloud computing operating system van fundamenteel belang is voor de kwaliteit van de dienst die je aanbied. Aangezien je als cloud computing provider bijna niet ontkomt aan een vorm van vendor lock-in hangt er zeer veel van deze keuze af. Open source is natuurlijk een heel aantrekkelijk concept omdat dit de TCO van je dienst mogelijk laag houdt. Dit betekent wel dat je als cloud computing provider moet investeren in het beheersen van de technologie en dat de leercurve vrij steil is omdat er zeer weinig mensen met deze specifieke kennis rondlopen en zeer gewild zijn. Ook is er veel minder over te vinden op het internet. Als software ontwikkelaar die programmeert in PHP of .NET is er zeer veel te vinden, maar probeer eens goede informatie te verkrijgen over cloud computing operating systems. Zowel Nova als OpenNebula zijn overigens wel goed gedocumenteerd.

Provisioning
Als je de hardware op orde hebt en het juiste OS gevonden hebt om al dat ijzer (slang voor servers) aan te sturen komen de volgende uitdagingen op je pad. Het provisionen (is dat een Nederlands werkwoord?) is daar één van. Het beschikbaar stellen van rekenkracht aan derden moet op basis van zelfbediening. Dat is nagenoeg een eis van een cloud computing dienst. Maar daar houdt de uitdaging niet op. Je zult ook moeten voorzien in firewalls/multi tenancy/veiligheid en bijvoorbeeld zaken als load balancers en technieken in resilience welke niet out-of-the-box zomaar werken.

Meten is weten wat je moet doorberekenen
Een ander aspect van een cloud computing provider is dat deze een vorm van elasticiteit aanbied. Een klant of gebruiker neemt niet een constante hoeveelheid van iets af. Er is geen punt in het bouwen van een enterprise cloud als je niet weet wie wat afneemt en hoeveel. Het betalen of doorberekenen naar gebruik is een fundamenteel onderdeel van het aanbieden van data en rekenkracht. Ook hier geldt dat een cloud OS hier standaard niet (volledig) in faciliteert. Het betalen met bijvoorbeeld een credit card is dus iets wat momenteel vaak door de cloud provider op maat wordt gemaakt bovenop het cloud computing OS. Bij een private cloud wordt dit wellicht vertaald naar kostenplaats of afdeling. Wat moet er gemeten worden? Dat verschilt per geval. In het ene scenario is betalen per processor-uur genoeg, bij veel andere gevallen neem je ook facetten mee zoals licenties, bandbreedte, data opslag, transacties en dergelijke. Het maken van een goed werkend systeem is verrassend complex. Als de enterprise cloud intern gebruikt wordt kan dit doorbereken principe een zeer mooie verandering betekenen in het verdelen van IT kosten.    

Services
Uiteindelijk wil je klanten diensten aanbieden. Voor het gemak kennen we drie levermodellen van cloud computing; infrastructure as a service, platform as a service en software as a service. Als aanbieder van cloud computing zul je merken dat je eigenlijk alle drie moet aanbieden om een zinvolle service te zijn. Een basis vereiste is namelijk een dashboard voor zelfbediening en dat schaar ik onder software as a service  Dit is ook één van de eerste dingen die je bouwt en aanbied naar klanten. Zonder goede zelfbediening tool heb je praktisch gezien geen service. Daarnaast biedt de kwaliteit van dit dashboard (of portal) in hoge mate de adoptie van je dienst als geheel. Ik kan geen cijfers geven omdat ik ze niet voorhanden heb, maar gebruik hiervoor een simpel voorbeeld die we allemaal wel kennen. App Store van Apple nam een enorme vlucht omdat je eenmalige een manier van betalen instelt en daarna met 1 klik en een wachtwoord een applicatie kunt installeren. Wat voor de App Store geldt, gaat ook voor een cloud computing dienst op. Maak het makkelijk en het wordt omarmt.

Daarnaast zul je  rekenkracht aan willen bieden en dat gaat door middel van virtualisatie van servers. Samen met een virtueel netwerk vormt dit de basis voor Infrastructure as a service.

Als laatste is ook het aanbieden van data opslag noodzakelijk, op de eerste plaats omdat een virtuele server zelf ook gewoon een file is. Maar ook data voor bijvoorbeeld websites en bestanden is iets waar een cloud dienst nu eenmaal niet zonder kan. Storage vormt onderdeel van infrastructure-as-a-service, maar vaak kun je data opvragen en schaalbaar opslaan middels een Aplication Programming Interface (API) en dan valt het al snel in het domein van platform-as-a-service aangezien de eindgebruiker zelf niet snel een API aanroept.

Kijk naar de voorbeelden
Zo zie je dus dat als je een cloud computing provider wilt worden je bijna direct een aanbieder wordt van zowel IaaS, PaaS als SaaS. Merk ook op dat er feitelijk niet veel verschil zit tussen public en private. In beide gevallen wil je een schaalbare dienst opzetten op basis van zelfservice. Ook als je onderdeel bent van de interne organisatie.

Om een goede cloud computing provider te worden hoef je alleen maar te kijken naar bestaande succesvolle diensten zoals Amazon AWS, Rackspace, Microsoft Azure, Google App Engine, Force.com et cetera. Maak een (gratis) account, log in op hun zelfbediening dashboard, probeer de dienst uit en zie waarin zij uitblinken.

Waarin Amazon AWS in uitblinkt is bijvoorbeeld hun application programming interface (API) om diensten te consumeren. Consistent, multi platform, eenvoudig te begrijpen (REST), goed gedocumenteerd en voor *alles* is een methode zodat alles met alles kan praten. Daarnaast hebben ze complexe zaken klikbaar eenvoudig gemaakt voor een snelle adoptie.

Windows Azure gaat in bepaalde facetten zelfs nog een stapje verder dan Amazon. Zij bieden bijvoorbeeld al een grote mate van resilience (veerkracht) aan die extreem veel denkwerk uit handen neemt en geografische redundantie zeer eenvoudig maakt, al is het wel weer ingewikkeld om dit in de praktijk te testen.

Ik zal niet zeggen dat het worden van een cloud provider eenvoudig is. Verre van dat. Maar er is al veel pionierswerk uitgevoerd en het is prachtig om te zien hoe een community van OpenStack de kennis hierover deelt. OpenStack is overigens niet de enige, maar wel één waar ik al wat langer naar kijk en in verdiept heb. Punt is dat als je een enterprise cloud wilt opzetten goed moet kijken naar wat er al is en bepaalde fundamenten moet aannemen en adopteren en beseffen dat kiezen voor een bepaalde stack of technologie niet eenvoudig teruggedraaid kan worden.

Go build your cloud!

vrijdag 9 november 2012

Cloud computing: Scale up or scale out?

Bij het ontwerpen van de database voor een cloud oplossing zijn een aantal vragen die steeds terugkomen:

> Hoe ga ik om met data van verschillende klanten?
> Hoe hou ik de database ook snel als de dienst populair wordt?
> Hoe hou ik de eigen TCO van de dienst zo laag mogelijk?
> Hoe ga ik zo slim mogelijk om met schaalbaarheid?

Wat betreft het opslaan van data van verschillende klanten is één van de belangrijkste vragen: Scale-up or scale-out?

Multi-tenant
Software voor cloud applicaties is van nature multi-tenant, ofwel, meerdere klanten maken gebruik van dezelfde dienst en leven dus naast elkaar op een dienst die je over het internet afneemt. Multitenancy speelt zich echter af op verschillende lagen en één daarvan is de database.

Bij het ontwikkelen van software diensten gaat een ontwerp vooraf. Vaak zullen deze diensten door verschillende klanten gebruikt worden, het ontwerp dient dus van de grond af aan multi-tenant te zijn. Over hoe je de architectuur voor zo’n omgeving inzet zijn de meningen verdeeld. De database staat vaak aan de basis van een ontwerp aangezien data de basis van veel (kantoor) applicaties vormt. Zo kom je al snel voor de volgende fundamentele keuze:

> maak voor iedere klant (tenant) een eigen database
> stop de data van alle klanten in één database

De 1e keuze kun je beargumenteren als niet multi-tenant. De dienst als geheel is echter wel multi-tenant en daar gaat het uiteindelijk om.

Alle data in één database stoppen is een vorm van opschalen (scale up), je maakt iets groter en zwaarder terwijl de database snel moet blijven. Voor iedere klant een database maken heet scale-out. Je houdt de database snel door de data te verspreiden. Er zijn diverse voors en tegen voor beide aanpakken, ik zal er een paar geven.

Scale up
Het voordeel van één database is dat het beheer en de schaalbaarheid in de basis goed te realiseren is, hoewel het ontwerp van het datamodel wat complexer is. Dit houdt ook de kostprijs laag. Ook het up to data houden van het model en het uitvoeren van upgrades is relatief eenvoudig omdat er maar één omgeving is. Nadelen zijn er echter ook. Upgraden kent geen uitzondering, alle klanten moeten in één keer over. Ook is de veiligheid lastiger te realiseren aangezien de data van klanten in dezelfde tabellen staan. Maar op termijn is de grootste uitdaging de schaalbaarheid. Wat als een miljoen klanten tegelijk data in de database stoppen en eruit halen? Wat als je klanten overal ter wereld zitten?
 
Scale out
Bij het maken van een database per klant begin ik bij de nadelen. Het beheren van duizenden databases is lastig. Je moet veel dingen zoals upgraden geautomatiseerd kunnen doen anders ben je exponentieel veel tijd kwijt voor het beheer. Als er zaken fout gaan, bijvoorbeeld in upgrades kan dit leiden tot een beheer nachtmerrie. Als je licenties moet betalen per database zullen deze dus ook leiden tot hogere kosten. Er zijn echter ook voordelen. Zo gebeurt het niet snel dat je data van andere klanten per ongelukt “lekt”. Ook het snel houden van een relatief kleine database is makkelijker dan van een grote database. Ook zijn er subtiele voordelen zoals een eenvoudige restore of disaster recovery. Daarnaast hoeven niet alle klanten direct mee te gaan in een update/upgrade. Maar zoals gezegd, beheer vergt veel automatisering anders zullen de kosten snel oplopen. Daarvoor krijg je wel in de basis oneindige schaalbaarheid terug. Ook heeft het voordelen als klanten over meerdere werelddelen verspreid zijn. Hoe dichter de data zich bij de klant bevindt, hoe makkelijker het is om de data snel te serveren.

Het is dus zaak van de te voren in te schatten wie je klanten zijn en hoeveel dat er kunnen worden. Scale up is tot een bepaald niveau goedkoper en sneller te realiseren. Scale out is de winnaar als het echt op grootte aankomt.

Wat zijn de uitdagingen bij multi-tenancy?
Wat gebeurt er als een database niet goed ontworpen is? Het ergste is imagoschade die kan ontstaan als er ontdekt wordt hoe je data in kunt zien van andere klanten. Veiligheid van data is dan ook van de hoogste prioriteit. Een grote belemmering van de adoptie van internet applicaties is vertrouwen en een slecht imago zal de dienst geen goed doen. Andere bedreigingen is als de dienst populair wordt en daarmee trager. Dit zag je bijvoorbeeld bij de onstuimige groei van Hyves en Twitter. Bij applicaties die door bedrijven gebruikt worden zie je vaak dat bedrijven niet altijd direct mee willen met de nieuwste functionaliteit en het faciliteren hierin is bijzonder lastig als alles in één database zit. Net als het herstellen van data als er iets fout is gegaan bij één klant. Als laatste is het beheren van de klant omgevingen een uitdaging, vooral als klanten bepaalde vormen van vrijheid krijgen om het datamodel flexibel in te richten.

Hybride
Wat voor de database geldt, gaat ook op voor andere onderdelen van het ontwerp, de rekenkracht, load balancers, cache, et cetera. In de regel is scale out vaker een betere keuze dan scale up.
Zelf heb ik een hekel aan het woord hybride omdat dit vaak voorgesteld wordt als het beste model voor cloud computing. In dit geval is het echter wel een woord wat snel een goed beeld schetst als het gaat om scale-up of scale-out. Ik zie namelijk in de basis geen belemmering om databases multi-tenant te ontwerpen, maar deze ook te dupliceren voor iedere klant. Ook hier begin ik weer met de nadelen; het ontwerp is bevat meer complexiteit en daarnaast moet je ook nog eens het beheer en automatisering inregelen voor de scale-out. Maar deze prijs is relatief laag en de voordelen zijn groot. Je kunt het nu voor kleine klanten aanbieden of voor een gratis model. Deze zitten in één database. Als één klant te groot wordt kan deze gemigreerd worden naar een eigen database. Krijgt een klant een dochterbedrijf of neemt deze een bedrijf over? Dan kan in diens database gewoon een tenant worden toegevoegd. Ook white labelen is nu relatief makkelijk te realiseren.

Take-aways
Dan heb ik nog twee take-aways voor het ontwerpen van multi-tenant datamodellen. De eerste is om bij elke veel tabellen bijvoorbeeld een veld toe voegen met bijvoorbeeld een naam als TenantId. Elke bevraging (query) gebruik je deze TenantId om zodoende nooit data te kunnen tonen van andere tenants. De tweede take-away is het gebruik van Global Unique IDentifiers (GUIDS). Gebruik als primaire sleutel voor elke tabel een GUID. Een GUID heeft bijvoorbeeld deze vorm : FD9EDB38-864D-49F2-A8AE-B6439AB3362D . Dat lijkt een verspilling van ruimte, maar besef dat een adres veld al meer tekens bevat. De voordelen van GUID’s zijn zeer krachtig. Google maar eens op deze GUID, je zult alleen dit artikel vinden. Het voordeel in multi-tenant omgevingen is dat je heel gemakkelijk data van een klant kunt verplaatsen naar een andere database. Een GUID is volstrekt uniek over alle database ter wereld heen.

Hoe dan ook, Als je ontwerpt voor schaal moet je ook ontwerpen op basis van automatisering anders slaat die schaal keihard in je gezicht terug.