Journalistiek

Onpartijdig, onafhankelijk nieuws, uitsluitend in dienst van het branchebelang.

Orchestration is de heilige graal van de cloud

  • Door
  • Jeroen Mulder
  • geplaatst op
  • 31 maart 2015 10:00 uur

We houden het echt goed bij. IaaS is nog steeds het populairste product in de cloud. Veruit de meeste starters op de markt voor cloudhosters beginnen met IaaS. Logisch. Dat is immers het meest eenvoudige. Je investeert in een partij ijzer, zorgt dat het via het internet wordt ontsloten, installeert een virtualisatieproduct a la Hyper-V of VMware en klaar ben je. De klanten mogen binnenkomen. Totdat die klant eisen gaat stellen. Bijvoorbeeld dat hij vanuit zijn server op omgeving A ook capaciteit moet kunnen bijschakelen in Azure of Amazon. Waarom? Omdat hij niet van één provider afhankelijk wil zijn.

Want hoe mooi het cloudverhaal ook is, de oude ‘vendor lockin’ bestaat ook in de wolken. De meeste, iets grotere klanten willen dat voorkomen. Die willen zekerheid en zo weinig mogelijk risico lopen. Dat laatste is op zich weer een gevolg van het succes van cloud en de volwassenheid die de services inmiddels hebben bereikt. Ook kritische omgevingen kunnen op een multitenant-omgeving worden gehost, mits je als provider een aantal zaken maar goed hebt ingeregeld op gebied van containment en security. Maar de meeste klanten wedden daarbij niet op één paard. Dat deden ze in de traditionele omgevingen niet, dat gaan ze zeker in de cloud niet doen.

Waar zit dan als IaaS-provider de toegevoegde waarde? In orchestration. De grotere partijen zoeken niet voor niets allemaal naar manieren om als orchestrator de verschillende cloudproviders aan elkaar te knopen, waarbij het de grote uitdaging is om de klant het gevoel te geven dat hij altijd ‘binnen’ zijn omgeving blijft. De klant mag niet merken dat er instances verspreid zijn over verschillende providers. Zaken als SSO (Single Sign On) en volledige platformintegratie worden dan belangrijk. Nog mooier: het kunnen verplaatsen van instances naar de op dat moment meest gunstige locatie binnen de omgeving. Helemaal te gek: volledig geautomatiseerd, op basis van vooraf vastgelegde provisioning- en securityrules, met behulp van populaire utilities als Puppet of Chef. Eén landschap. Volledig te besturen vanuit één controlekamer.

Technologisch is het niet eens een heel groot probleem meer. Federatieservices en multicloud-orchestratie zijn mogelijk. Het vergt alleen wel de bereidwilligheid van providers, zeker de grootsten, om hieraan mee te werken en hun API’s hiervoor ‘open te stellen’. Dat is één. Twee: de klant overtuigen. En dan komen de securityregels op de tafel, de security officer die gaat aandringen op volledige inzage in de mode of controls. Hoe garandeer je de controle op toegang tot deze landschappen waarin je feitelijk voortdurend de grenzen oversteekt. Kortom: hoe regel je een Schengen-verdrag in de cloud?

Nogmaals: technologisch is dat geen probleem met bijvoorbeeld Active Directory en LDAP, maar dat zijn slechts tools. Het komt neer op de implementatie van RBAC: role based authentication. Da’s een stuk lastiger. Dat zijn namelijk afspraken, niet meer, zeker niet minder. En hoe graag we dat in de cloud ook zouden willen, daar is geen generiek model voor. RBAC zal per klant anders uitpakken, mede en vooral afhankelijk van de business van die klant. Toch zullen cloudproviders zich meer en meer bezig moeten houden met dit type dienstverlening. Dan voeg je waarde toe. Met alleen het zoveelste IaaS-product gaat niemand het meer redden.

Patrick, 31 maart 2015 11:26 am

Hyper-V en VMware zijn virtualisatie produkten en hebben weinig met een echte Cloud te maken. Virtualisatie is niet hetzelfde als Cloud. Het gros van de private en public Cloud oplossingen zijn op basis van OpenStack. En dan heb je nog de reuzen als Google en AWS die hun eigen op Linux/KVM/containers gebaseerde oplossingen hebben maar ook nog steeds geen VMware of Hyper-V gebruiken.

Dat orchestratie belangrijk is mag duidelijk zijn. Maar waarom noem je Puppet? Voor complexe orchestratie in een multi-cloud omgeving zal je tool toch echt node interdependencies & ordering moeten snappen en Puppet scoort op dat vlak niet goed. Puppet is uitstekend voor configuration management maar gewoon niet geschikt voor lifecycle management van een complexe multi-cloud omgeving. Wil je orchestration en lifecycle management doen in een dergelijke omgeving kijk dan eens naar Ansible of SaltStack.

De APIs, de Security Officer en RBAC zijn helemaal niet zo uitdagend. Alle grote public Cloud aanbieders en OpenStack hebben al een API waarmee je kan regelen op welk continent en in welk datacenter je instance komt te draaien c.q. je data wordt opgeslagen. Voor RBAC (ondersteund in OpenStack) wijst de klant een admin aan die vervolgens rechten uitdeelt aan de eigen mensen. Daarmee is de klant zelf in control en verantwoordelijk.

Voor een multi-cloud management oplossing kijk eens naar ManageIQ (Open Source). Het kan IaaS infrastructuur managen, ondersteunt service orchestration, lifecycle management, chargeback en geautomatiseerde workflows.

Laatste reacties

Bedankt voor het succes van ISPam.nl
Koen Stegeman, Editor-in-Chief & founder Hostingjournalist.com: Jammer Arnout, maar je hebt een mooie bijdrage aan de hosting industrie geleverd, en dat jaren lang....

Bedankt voor het succes van ISPam.nl
Dillard Blom: Jammer dat een 'instituut' verdwijnt, en daarmee een bron van informatie over actuele zaken (en opin...

Bedankt voor het succes van ISPam.nl
L.: Uit automatisme kijk ik toch nog steeds elke dag naar ispam.nl, toch de hoop dat er nog een berichtj...

Bedankt voor het succes van ISPam.nl
Toni Donkers: Arnout bedankt! ik ga het missen dat is een feit!

Bedankt voor het succes van ISPam.nl
Marcel Stegeman: Ik zie het nu pas. Inderdaad jammer maar ik kijk nu al uit naar het volgende project.