Cloud Computing op maat gemaakt

Op mijn eerdere blog ‘De valkuilen in Cloud Computing’ kwamen nogal wat reacties over de verbinding, de weg er naar toe. Hierbij werd terecht opgemerkt dat dit niet een specifiek probleem is voor Cloud Computing, het kan zoals opgemerkt, ook spelen tussen remote locaties. Het netwerk, en dan met name de bandbreedte, latency en stabiliteit, is dus belangrijk maar wordt ook steeds vaker als een gegeven gezien. Het is er of het is er niet.




En als het netwerk er toch al ligt dan wordt de weg naar de cloud een stuk eenvoudiger en goedkoper. Steeds meer netwerk providers breiden daarom hun diensten uit door cloud computing als leveringsmodel te adopteren. Hoewel het misschien eerlijker is om hier te spreken over hosting 2.0 omdat deze aanbiedingen (nog) niet te vergelijken zijn met de tier-1 aanbieders als Google, Amazon en Microsoft. Maar in hun concurrentie hebben ze door hun stabiele netwerken met lage latency wel een unieke positie. Zo hoeft er bijvoorbeeld geen gebruik gemaakt te worden van publieke netwerken hetgeen de betrouwbaarheid ten goede komt. Sommige aanbieders brengen hun klanten hiervoor zelfs geen kosten in rekening en hanteren een 'fair use'-policy waardoor bij afname van cloud computing gevraagd kan worden: Netwerk bij, meneer?

 
Mix and match
Maar zoals gezegd zijn deze aanbiedingen vaak meer hosting 2.0 en is er op z'n best sprake van Platform as a Service (PaaS) waarbij de knip, de afbakening in verantwoordelijkheid ligt tussen besturingssysteem en de applicaties. Dat betekent meestal dus veel 'doe het zelf' in de transitie wat natuurlijk een grote flexibiliteit geeft maar ook voor veel vragen kan zorgen. De aanbieder kan met 'pre-defined' templates, welke op basis van best practices zijn ingericht, hier wel veel zorgen wegnemen. En dit standaardiseren is eigenlijk hetzelfde als hetgeen we met virtualisatie doen, tenminste voor wie niet alles met een Physical to Virtual (P2V) hulpmiddel overgezet heeft. Het aanbieden van een service catalog met een beperkt aantal basissmaken, die met 'toppings' zoals back-up, redundantie en schaalbaarheid uitgebreid kunnen worden, geeft een duidelijk antwoord op veel onzekerheden. Hosting 2.0 biedt hier trouwens nog een bijkomend voordeel omdat niet alles gevirtualiseerd hoeft te worden.
 
Eerlijk en onafhankelijk
Als het aanbod duidelijk is, welke door de vele aanbieders in de hosting markt steeds meer een vechtmarkt wordt dan blijft de vraag over. Want uiteindelijk gaat het niet om de systemen die fysiek, virtueel, zich op locatie of in de cloud kunnen bevinden, maar om de applicaties. De eerste stap begint dus met een inventarisatie hiervan, door eisen inzichtelijk te maken voor zowel de techniek, de functionaliteit als het beheer. Onderverdeeld naar deze drie focusgebieden zal een ‘profiler' dus de volgende informatie moeten verzamelen:

1. Techniek: systeem- en applicatie karakteristieken zoals het gebruik van resources, afhankelijkheden met andere systemen en applicaties.
2. Functionaliteit: welke bedrijfsprocessen worden ermee ondersteund, welke waarde hebben ze hiervoor en zijn er overlappingen in functies?
3. Beheer: hoe liggen de verantwoordelijkheden, welke lifecycles zijn er en welke sla's gelden per service/applicatie?

Meten is weten
Eerste punt is redelijk eenvoudig te achterhalen met bijvoorbeeld WMI of shell scripts, hierbij neem ik aan dat vooral de Intel-servers met Windows of Linux in aanmerking komen voor cloud computing. Daarmee kan zowel de configuratie als belasting vastgelegd worden en geladen worden in een database. Met voorgedefinieerde queries en stored procedures kan de juiste template gevonden worden waarbij zelfs rekening gehouden kan worden met bijvoorbeeld CPU-benchmarks. Een provider kan dit zelfs web-enablen en zo een self-service portal maken dat intelligenter omgaat met het bepalen van de behoefte dan het invullen van de vragen. Het op basis van bestaande configuratie en belasting de behoefte bepalen is tenslotte onafhankelijk. Vervolgens kunnen aan de juiste template de benodigde 'toppings' voor functionaliteit en beheer nog toegevoegd worden.
 
Vragen, vragen en nog eens vragen
De functionaliteit is misschien niet te vangen met een geautomatiseerd script maar grotendeels wel te bepalen door het stellen van de juiste vragen. Hierbij heb ik altijd een voorkeur voor de 'six honest serving men' van Rudyard Kipling die uiteindelijk de basis is van veel architectuur modellen. Omdat hierbij vooraf een rationalisatie gedaan wordt, kan dit voor een besparing zorgen als er minder resources nodig zijn. Ook niet onbelangrijk is om in deze fase te kijken waar de 'intelligentie' van de applicatie ligt. Indien deze bijvoorbeeld in de database ligt is een migratie vaak complexer waardoor rationalisatie hiervan minder eenvoudig is. Vaak zijn alleen de bekende databases ondersteund terwijl de juiste inrichting, de optimalisatie met het onderliggende platform, zoals bijvoorbeeld de opslag, medebepalend is voor de prestatie.
 
Geen kastjes, geen muren
Omdat meer zielen voor meer vreugde zorgen bij het routeren van incidenten is het belangrijk dat verantwoordelijkheden in een RA(S)CI matrix vastgelegd worden. Zodat de 'knip' in verantwoordelijkheid duidelijk is en bij wijzigingen of problemen de juiste mensen sneller gewaarschuwd en geïnformeerd kunnen worden. Natuurlijk mag hier ook de bewaking van de service, de controle dat afgesproken sla's ook inderdaad behaald worden, niet onderbelicht blijven. Dit kan gedaan worden door middel van reactieve monitoring maar beter is het om aan te sluiten op de apiI's, de beheer interfaces, zodat proactief gereageerd kan worden. Beschikbaarheid van het platform betekent tenslotte niet altijd dat ook de applicaties gebruikt kunnen worden. Systeemlogs kunnen bijvoorbeeld helpen om hierop tijdig, voordat gebruikers het merken, actie te ondernemen.