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:
- Techniek: systeem- en applicatie karakteristieken zoals het gebruik van resources, afhankelijkheden met andere systemen en applicaties.
- Functionaliteit: welke bedrijfsprocessen worden ermee ondersteund, welke waarde hebben ze hiervoor en zijn er overlappingen in functies?
- 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.
In samenwerking met Interoute organiseert Unisys een seminar waarin een deel van bovenstaande vragen en problematiek ter sprake zal komen. Zie voor meer informatie het programma.
Met dit artikel besteedt je terecht veel aandacht aan de voorbereiding en transitefase naar Cloud. Veel klanten zijn zeker niet bewust van dit deel en zoals Peter van Eijk vandaag in zijn artikel aangegeven heeft gaan ze op de golfbaan samen met andere CIO`s de weg naar Cloud in een dag bewandelen.
Het veranderen van je ICT in ICT in/uit de Cloud kent nog meer aspecten, een aantal van deze aspecten heb je ook in je vorige artikelen benoemd maar we zijn er nog niet.
Ik heb al eerder gezegd dat Cloud een oplossing is die verder ontwikkeld en volwassen dient te worden, hij is nog niet klaar. Dan heb ik het niet alleen over Cloud zelf maar ook de processen en de benodigdheden die aan de Cloud gerelateerd zijn.
@Reza
Uiteraard zijn er 100 en 1 dingen waar je aan moet denken maar dat is eigenlijk gebruikelijk bij elke wijziging. Het is dan ook makkelijk om een stok te vinden waarmee de hond geslagen kan worden.
Natuurlijk zullen er bij verhuizing van applicaties naar buiten – in de cloud – nieuwe spelers en factoren bij komen. Maar vaak zijn dat factoren die ook intern speelden maar dan minder belangrijk waren omdat ze informeel opgelost konden worden.
Het identificeren van die factoren op de drie assen die ik schets helpt om de transitie naar de Cloud te maken maar is geen verplichting. Het kan zelfs een onderbouwing geven om bepaalde applicaties juist niet te verplaatsen maar deze te vervangen of ongewijzigd te laten. Tenslotte moet ook de CIO van de juiste informatie voorzien worden om het goede besluit te kunnen nemen.
Meestal is het beheer, de beheer interface, de monitoring en ook het life cycle management beter geregeld in de cloud dan bij de gemiddelde onderneming. Dat is dus aanpassen, vreemde ogen dwingen en je zult je moeten richten naar de aanbieder.
Dat het netwerk belangrijk is dat is een gegeven en naast het is er wel of het is er niet zijn er ook tussenvormen, het is er wel maar met mindere capaciteit of groter vertraging. Daar moet je je op instellen.
Het meest belangrijke is dat als je applicaties naar de cloud gaat brengen in de vorm van PAAS of IAAS aanbiedingen, dat je dan heel goed gaat testen hoe je uit de cloud migreert naar je eigen organisatie of naar een andere aanbieder. Als je dat niet voor elkaar hebt dan ben je lost en heb je een verdor lockin. Zorg ook dat je eigen security normen en authenticatie en autorisatie modellen en systemen werken.
Anders dan hierboven gesteld hoef je volgens mij maar naar 2 zaken te kijken:
1. Functionaliteit: Bereik ik wat de gebruiker wil, binnen de met de gebruiker overeengekomen SLA;
2. Hoe ga ik regie voeren over de cloud aanbieder zodat zij het beheer en de techniek goed regelen.
In het geval van een SAAS aanbod hoef je alleen maar over het laatste zorgen te maken, ervan uitgaande dat je het eerst bij de intake hebt geregeld.
Je moet dus als organisatie loslaten hoe de techniek en het beheer is geregeld, je moet de dienst naar de eindgebruiker gaan beheren en dat is voor heel veel organisaties iets heel nieuws en iets dat ze niet gewend zijn.
Zoals bij alles wat nieuw is: start met iets kleins, zorg voor een goede pilot, breid langzaam uit, kijk naar verdeling over verschillende cloud leveranciers, etc. Zorg dat je een goed contract sluit, je bent overgeleverd aan een diensten leverancier en daar zou ik mijn primaire processen nog niet zo gauw aan overdragen, totdat betrouwbaarheid, integriteit en veiligheid zijn bewezen.
Zorg in ieder geval dat je maar 1 taak gaat regelen in de cloud, hang niet jaren van achterstallig onderhoud in een cloudproject en start met iest dat smart is. Bijvoorbeeld een e-mail dienst of een applicatie zoals CRM.
@Willem
SaaS is de optima forma van Cloud Computing waarbij inderdaad veel zorgen rond beheer, regie en inrichting weg genomen worden. Helaas is het ook voor veel services/applicaties vaak nog één of meerdere bruggen te ver. Bijvoorbeeld door het door jouw genoemde achterstallig onderhoud. Vraag is of er gekozen wordt om daarmee door te modderen of juist een inhaalslag te maken?
Ik geloof in cloud computing om de simpele reden dat het uiteindelijk gaat om functionaliteit, de rest is bijzaak (netwerk, beschikbaarheid, veiligheid, et cetera).
Het zelf doen en beheren van een IT omgeving is dus een noodzakelijk kwaad, net als een CD een noodzakelijk kwaad was om muziek te luisteren. En foto rolletjes om foto’s op te zetten.
Op het moment dat er een goed alternatief komt (en dat is onvermijdelijk), hetzij in veiligheid, bereikbaarheid, prijs of wat dan ook, dan is de overstap snel gemaakt.
Het is overduidelijk dat niet alles op dit moment geschikt is voor cloud computing. Dat zijn misschien de onderdelen die Reza bedoeld met onderdelen die nog volwassen moeten worden. Maar cloud computing is al wel erg geschikt voor bepaalde zaken zoals samenwerken, e-mailen, agenda’s beheren en afnemen van bepaalde online diensten.
De migratie/adoptie kan geholpen worden met deze artikelen en artikel schrijvers
“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”
web-enablen en self-service zouden focus moeten zijn voor IT bedrijven die diensten aanbieden.
Dus mooi artikel Ewout.
Leuke discussie. Interessant ook dat alles ondergeschikt is aan “functionaliteit”
Ter aanvulling, het is niet alleen belangrijk te kijken wat je zelf graag wil, maar ook de verplichtingen waar een cloud provider je toe dwingt.
Met name bij SaaS (sterk gestandaardiseerde diensten) verplicht de provider de klant vaak tot bijv. minimale systeemvereisten voor clients. De meer incrementele, snellere lifecycle die (SaaS) cloud diensten zo mooi maken kunnen hierdoor er plotseling voor zorgen dat een klant binnen een x periode al haar systemen moet updaten.
Nog even los van het onvoorspelbare effect op een onderliggende business case…reken op een gefrustreerde klant als dit niet tijdig gesignaleerd is.
@Andre
Als je niet weet wat je wilt, wat je nodig hebt is het moeilijk kiezen. Functionaliteiten voor gebruiker en beheerder bepalen in grote mate de werkbaarheid van een oplossing.
Cloud Computing is een keus, een aanvulling op andere delivery modellen die zowel voor- als nadelen heeft. Het inzichtelijk maken hiervan zorgt ervoor dat er objectief gekozen kan worden voor zowel provider als oplossing. Nu kan er in een business case eenzijdig nadruk gelegd worden op de voordelen waardoor de klant gefrusteerd raakt als de nadelen later proefondervindelijk naar boven komen. Dat is echter niet exclusief gebonden aan Cloud Computing maar komt ook voor bij andere wijzigingen, aanbesteding en vervangingen.
Natuurlijk wordt keuzevrijheid ook beperkt door de mogelijkheden die provider biedt en geeft bijvoorbeeld SaaS vaak minder vrijheid. Maar het kan ook interessant zijn om juist te kiezen voor SaaS omdat zoals al aangegeven in andere reacties toevoeging van nieuwe functionaliteiten zoals mobiliteit of modernisatie door achterstallig onderhoud daarmee goedkoper gedaan kan worden. Ik ben het met je eens en vindt het een goede aanvulling door op te merken dat zo’n keus ook eisen stelt aan de organisatie. Beheerorganisaties die een lage graad van volwassenheid hebben en vooral reactief ingericht zijn zullen dan waarschijnlijk ook moeite hebben met zo’n verandering. En ook voor gebruikers kan dit gevolgen hebben als deze verwend waren door ‘liefdevol’ beheer welke altijd de benen uit het lijf liep om incidenten op te lossen.