Cloud Computing standaard en REST API

2013

[CC STANDAARD, CAMP EN REST API] Dit document geeft inzicht in de toekomst van Cloud Computing door de actuele situatie m.b.t. de definitie en ontwikkeling van een Cloud Computing Standaard wereldwijd en de introductie en acceptatie van een REST API voor Cloud Computing. Het heeft ten doel koudwatervrees voor Cloud Computing weg te nemen.

28 februari 2013

[CLOUD COMPUTING STANDAARD; CAMP EN REST API]

Inhoudsopgave

Samenvatting.............................................................................................. 3 Waarom is een standaard belangrijk? .............................................. 5 De 5 evolutiefasen van een standaard ........................................... 8 De Gouden Standaard voor Cloud Computing ....................... 10 Representational State Transfer (REST) .................................. 14

2

Jambo ConsultancyŠ

28 februari 2013

[CLOUD COMPUTING STANDAARD; CAMP EN REST API]

Samenvatting Gedurende 2012 is Cloud Computing of IT as a Service (ITaaS) steeds meer gemeengoed geworden binnen ondernemingen wereldwijd en de inschatting is dat dit in 2013 explosief zal toenemen, mits koudwatervrees rond dataveiligheid en de angst voor de wet van de remmende voorsprong wordt overwonnen. Deze angst bestaat er vooral uit als Early Adaptor van de Cloud niet te kunnen voldoen aan de toekomstige Cloud standaard.

In de zomer van 2012 is Cloud Application Management for Platforms (CAMP) in het leven geroepen door belangrijke spelers als Oracle, Red Hat, Reckspace, Software AG (zie 1. http://snk.to/1JFL en 2. http://snk.to/1Kuz ) Zij zetten in op de definitie van een REST Application Programming Interface (API).

Ook HP is actief via de Open Group en heeft de eerste technische standaard voor Cloud Computing begin 2013 gelanceerd genaamd SOCCI. De Amerikaanse overhead, FEDRAM, heeft eind 2012 het eerste cloudcertificaat geïntroduceerd, 3PAO, voor alle Cloud leveranciers die aan de US overheid willen leveren.

In Europa stuurt mevrouw Kroes ook aan op een standaard voor de cloud.

In deze publicatie het waarom van een standaard en de uitleg van alle belangrijke en actuele aspecten voor de vorming van de Gouden Standaard voor Cloud Computing, zoals SOCCI, CAMP, RESTAPI etc. zodat u een afgewogen inschatting kunt maken over het zetten van een eerste stap in de richting van de Cloud voordat het te laat is...

“Stop it!”

“You’ll be waiting there till 2015, while everyone else is building fundamental skills and ramping up their cloud knowledge,” “So jump in the game already!”

3

Jambo Consultancy©

28 februari 2013

[CLOUD COMPUTING STANDAARD; CAMP EN REST API]

Waarom is een standaard belangrijk?

Voor ITaaS consumenten heeft een Gouden Standaard voor Cloud Computing twee voordelen. Overdraagbaarheid tussen verschillende cloudomgevingen is één van de belangrijkste eisen van Cloud Computing consumenten. Door het standaardiseren en specificeren van Use Cases rond het inzetten, stoppen, starten en updaten van ITaaS vergroot het voor klanten de mogelijkheid om applicaties van verschillende ITaaS aanbieders af te nemen en dit verkleint weer de kans op Vendor Lock-In. Het ligt in de lijn der verwachting dat er Plug-Ins of “Management API’s” komen voor deze Use Cases voor ontwikkelomgevingen (ADE’s) maar ook dat leveranciers alleen hierin zullen gaan investeren i.p.v. in oplossingen voor maatwerk implementaties. In het verleden is gebleken dat na verloop van tijd dergelijke meer algemene implementaties alle aandacht krijgen en van grotere kwaliteit zijn dan de implementaties geschreven voor specifieke en eigen applicatiebeheer interfaces.

De aanbieders echter proberen met een Gouden Standaard de taart voor Cloud Computing te vergroten i.p.v. de taart in stukken op te delen. CAMP is bedoeld als een gemeenschappelijke basis voor het ontwikkelen van multi cloud management tools en het bieden van een op REST gebaseerde aanpak voor applicatiebeheer door cloudleveranciers voor –consumenten.

CAMP formuleert een gemeenschappelijke ontwikkeld woordenboek en een API die over meerdere cloudomgevingen kan functioneren zonder al te veel aanpassingen en één die compatibel is met ITaaS bewuste applicatie ontwikkelomgevingen, zowel offline als in de cloud.

Gemeenschappelijke Use Cases maken het verplaatsen van On-Premises applicaties naar de cloud (private of publieke) mogelijk en herschikken deze applicaties naar cloudplatforms van verschillende leveranciers. CAMP vermindert deze inspanning en biedt zekerheid voor het verplaatsen van diensten.

Lees meer in het eerste officiële CAMP woordenboek http://cloudspecs.org/CAMP/CAMP_v1-0.pdf of http://www.cloudspecs.org/paas/

4

Jambo Consultancy©

28 februari 2013

[CLOUD COMPUTING STANDAARD; CAMP EN REST API]

Het belang van een Gouden Standaard en de acceptatie van CAMP door zowel instituten als The Open Group en OASIS als nieuw normalisatie instituut wordt nog beter verwoord in onderstaande quotes.

Steven Harris, vice-president CloudBees Inc "Hoewel de PaaS markt nog in de kinderschoenen staat voor leveranciers zoals CloudBees gaat de innovatie ongelooflijk snel. Klanten zijn vooral bezorgd over Lock-In en interoperabiliteit. CAMP is een belangrijke eerste stap in de richting van dat belangrijke doel ".

Duncan Johnston-Watt, CEO, Cloudsoft Corporation.

"Hybride en Multi cloud omgevingen zijn in opkomst als de standaard voor de onderneming. PaaS is trending en een natuurlijke toegangspoort voor Cloud Computing. CAMP zal deze trend versnellen.

Cloud agnostisch applicatiebeheer is de sleutel tot cloud interoperabiliteit op dit niveau ".

Zheng Yelai, president van Huawei's IT Product Line "Als een toonaangevende wereldwijde informatie en communicatietechnologie (ICT)-oplossingen, dragen wij bij aan de ontwikkeling van de industrie norm en de ontwikkeling en vooruitgang van de Cloud industrie. Interoperabiliteit bij ITaaS maakt het mogelijk dat cloud applicaties naadloos opereren in platform providers. CAMP is een bemoedigende stap in de richting van dat doel. " Don Deutsch, Vice President, chief Standards Officer, Oracle "Oracle zet zich in voor een industriestandaard die cruciaal is voor onze klanten hun cloudomgevingen. Voor de vaststelling van deze normen zoekt Oracle samenwerking met CAMP. CAMP definieert een eenvoudige API die klanten in staat stelt om een interoperabele oplossing over meerdere leveranciers te hebben, die gemakkelijk te beheren is voor toepassing met levenscycli en toepassingen die tussen Clouds bewegen ".

Adrian Otto, technologie strateeg, Rackspace.

"Rackspace staat open voor het geven van keuzevrijheid aan hun klanten. CAMP biedt een manier om overdraagbaarheid van toepassingen mogelijk te maken tussen publieke en private clouds en zelfs tussen de cloud service providers met soortgelijke ITaaS oplossingen ".

Mark Little, director of Engineering, Middleware bij Red Hat "Red Hat geloofd al heel lang in het zoeken naar samenwerking met de industrie en de open source gemeenschap om op deze manier technologische ontwikkelingen af te dwingen en aan de behoeften 5

Jambo ConsultancyŠ

28 februari 2013

[CLOUD COMPUTING STANDAARD; CAMP EN REST API]

van ontwikkelaars en bedrijven over de hele wereld tegemoet te komen. Onze deelname aan CAMP is daarvoor het bewijs. Het ITaaS aanbod zoals OpenShift van Red Hat maakt hetvoor ontwikkelaars eenvoudiger te starten met het ontwikkelen van applicaties. Een instituut als CAMP is een aanzienlijke stap in de richting het verlagen van de drempel voor de toegang van nieuwe ontwikkelaars en als het gaat om het migreren naar ITaaS." Hans Christoph Rohland, Vice President R&D, Software AG “Software AG staat in de voorhoede van gedefinieerde standaarden en het erkennen van de behoefte aan interoperabele oplossingen voor onze klanten. Tot nu toe zijn cloud normen beperkt tot de infrastructuur (IaaS). Een interoperabele standaard voor het beheer van applicaties op hosted platformen (PaaS), brengt de CAMP specificaties naar het volgende niveau in de cloud ruimte. We zijn blij hieraan te hebben bijgedragen en kijken uit naar CAMP specificaties door OASIS in de toekomst".

De diplomatieke woorden van bovenstaande leveranciers geven aan voor wat voor een moeilijke taak CAMP staat om met de introductie van een REST API tegemoet te komen aan alle eisen van de verschillende leveranciers en zo te komen tot standaardisatie voor de cloud.

Sponsoren van OASIS komen vooral uit de hoek van Microsoft. The Open Group sponsoren zijn vooral traditionele hardware, database en diensten leveranciers zoals HP, IBM, Oracle, CapGemini en Kingdee. Naast de traditionele software tweestrijd tussen Microsofts Windows en Linux met Red Hat is er een andere arena in de cloud namelijk die van Rackstack vs. Openstack. Het nieuwe instituut CAMP moet proberen om voor alle aanbieders de Cloud Computing taart te vergroten door o.a. de introductie van een REST API zonder daarbij de voordelen van de consument uit het oog te verliezen.

Dat niet iedereen al op één lijn ligt blijkt uit de introductie van SOCCI door HP. HP en The Open Group introduceren begin 2013 dé technische standaard voor de Cloud genaamd SOCCI, voortbouwend op SOI en hun meta model TOGAF, voor alle SOI gerelateerde zaken zoals bv. Governance, en richten zich daarbij (als excuus) op een andere doelgroep bestaande uit; 1. De sponsoren van The Open Group Service Oriented Architecture Work Group en The Open Group Cloud Computing Werkgroep 6

Jambo Consultancy©

28 februari 2013

[CLOUD COMPUTING STANDAARD; CAMP EN REST API]

2. Enterprise architecten, SOA architecten en infrastructuur architecten als ook ICT strategen. N.B. OASIS steekt op dit moment nog maar weinig energie in de verdere ontwikkeling van S-RAMP. 3. Normalisatie instituten die een andere basis voor standaarden binnen het industrie domein kennen.

Ondertussen is Google volop in de weer met een eigen REST API. Het kan daarom nog wel even duren voordat er een definitieve Cloud Standaard is. Ervaring leert ook dat de Gouden Standaard voor Cloud Computing eerst nog een aantal evolutiefasen moet doorlopen.

7

Jambo ConsultancyŠ

28 februari 2013

[CLOUD COMPUTING STANDAARD; CAMP EN REST API]

De 5 evolutiefasen van een standaard.

Hieronder volgt een korte beschrijving van alle fasen.

1. Ontdekking. Bedrijven zoeken en ontwerpen nieuwe technieken en struikelen daarbij soms op nieuwe kostenbesparende toepassingen zoals ITaaS. Diverse opties komen in deze fase bovendrijven door de eisen van interne (prive) en de externe (publieke) omgevingen. Continue ontdekkingen van nieuwe technieken en hun variaties resulteren in een snelle spreiding in beschikbare opties.

2. Ervaring. De opkomst van nieuwe technieken leidt niet automatisch tot de acceptatie ervan. Alle technieken zijn onderhevig aan voortdurende evaluatie op basis van ervaring met deze diensten door consumenten, leveranciers, integrators etc. De techniek wordt voortdurend verbeterd, gerationaliseerd en verfijnd.

3. Consensus. Opstellen van een definitie van de standaard en de invoering ervan vereist actieve deelname van de belangrijkste spelers binnen het domein. Deze spelers hebben de neiging om hun eigen techniek als standaard te definieren.

Conflicten zoals de huidige prijzenoorlog, zullen tussen deze spelers ontstaan. Echter, de tegenkracht van de "Wij zijn anders" denkers is de noodzaak van interoperabiliteit die voor een ruimte in de dialoog brengt. Het bereiken van consensus is de meest uitdagende van al deze fasen; De Gouden Standaard voor Cloud Computing (ITaaS) is geen uitzondering.

4. Vereenvoudiging. Normen en standaarden hebben de neiging om alles in één te zijn om zo het proces van consensus te bespoedigen. Dit resulteert meestal in een monolithische definitie die bevorderlijk is voor een consistente wereldwijde acceptatie. Gebruikers zijn vervolgens geneigd om slechts delen van de standaard te gebruiken. Ook zien sommige standaarden het daglicht nooit omdat ze te omvangrijk zijn en te complex. Vereenvoudiging is het sleutelwoord. Vereenvoudiging kan het beste worden aangepakt door het identificeren van een gemeenschappelijke noemer (REST API) en tegelijkertijd te zorgen voor uitbreidingen als dat nodig is.

5. Governance. Standaarden blijven evolueren samen met veranderende zakelijke behoeften. Governance rond deze veranderingen is soms belangrijker dan de Gouden 8

Jambo Consultancy©

28 februari 2013

[CLOUD COMPUTING STANDAARD; CAMP EN REST API]

Standaard zelf. Het niveau van goedkeuring, bv van overheidswege (3PAO) geeft vorm aan de wijze waarop het bestuur van een organisatie Governance uitgeoefend.

De Cloud Computing standaard bevindt zich vandaag ergens tussen de fasen Ontdekking en Ervaring.

9

Jambo ConsultancyŠ

28 februari 2013

[CLOUD COMPUTING STANDAARD; CAMP EN REST API]

De Gouden Standaard voor Cloud Computing.

Er bestaan meerdere normalisatie instituten zoals daar zijn NIST, ISO of The Open Group die aansturen op de definitie van standaarden. Voor Cloud Computing leek er een onoverzichtelijk woud aan definities en standaarden te ontstaan (zie http://snk.to/1RFu ). Een aantal belangrijke spelers in de Cloud hebben daarom in de zomer van 2012 speciaal hiervoor CAMP opgericht.

Cloud Computing stelt naast een Service Oriented Infrastructure (SOI) een aantal unieke en nieuwe eisen aan de infrastructuur van ICT en het beheer daarvan; het vereist een meer abstracte benadering van de operationele omgeving. Een Cloud Computing leverancier kan niet langer voor elke abonnee maatwerk leveren. Dit betekent dat, in plaats van een werkelijk fysiek apparaat of software (code) Cloud Computing een afgeleide is van een server, file system, opslag, netwerk, database, code etc. Bovendien vereist het door haar Economies of Scale, waardoor de providers winstgevendheid en het maximaliseren van het gebruik van middelen kunnen nastreven, multi-tenancy, dynamische toewijzing van middelen en metingen met Charge-Back. Tegelijkertijd, verwachten abonnees bij de invoering van ITaaS een OnDemand gebruikersmodel zodat ze alleen moeten betalen voor hun eigen gewenste gebruik. Daarom moet de nieuwe ICT infrastructuur wendbaar en elastisch (agile) zijn en een gevoel geven van een oneindige voorraad aan IT-middelen die op verzoek direct beschikbaar zijn.

De volgende figuur illustreert het in kaart brengen van de verschillende SOI gerelateerde lagen met de lagen die worden vertegenwoordigd in de meer operationele SOA Reference Architecture (SOA RA) sfeer òf SOA Repository Artefact Model en Protocol (S-RAMP) van OASIS.

(Het doel van OASIS S-RAMP was een gemeenschappelijk datamodel voor SOA repositories als een interactieprotocol voor m.n. queries te definiëren om het gebruik van gemeenschappelijke tools en het delen van gegevens zowel binnen als buiten de cloud te vereenvoudigen).

10

Jambo Consultancy©

28 februari 2013

[CLOUD COMPUTING STANDAARD; CAMP EN REST API]

Governance Informatie

Presentatie Laag API

Gebruiker Interface

Bedrijfsprocessen

Services I n f r a s t r u c t u u r

Operationeel Systeem Netwerk

Opslag

Compute

Facilities

SOI

Kwaliteit Integratie Terwijl SOI niet het hele spectrum van de gewenste eigenschappen beslaat werd het wel een enabler voor wat beter bekend staat als Service Oriented Cloud Computing Infrastructuur (SOCCI).

Socci kan worden gedefinieerd als een service-oriented, utility-based, beheers-, schaalbaar, On-Demand infrastructuur die de essentiele cloud Karakteristieken, Service en Implementatie modellen van het National Institute of Standards and Technology (NIST) ondersteund. In andere woorden, SOCCI beschrijft de essentie voor het implementeren en beheren van ITaas omgevingen.

11

Jambo ConsultancyŠ

28 februari 2013

[CLOUD COMPUTING STANDAARD; CAMP EN REST API]

Er zijn meerdere commerciĂŤle ITaaS aanbieders die bestaan dankzij programmeertalen zoals Java, Python en Ruby en infrastructuur framewerken als Spring en Rails. Hoewel deze leveranciers verschillen in aspecten als programmeertaal, applicatieraamwerk, etc. zijn er inherente overeenkomsten in de manier waarop zij de levenscyclus en het beheer van deze toepassingen inrichten. De kernpropositie van de SOCCI standaard is dat deze overeenkomsten kunnen worden ingezet om een generieke applicatie en platform management API te maken die taal, kader en platform neutraal is. In het volgende hoofdstuk het verschil tussen RESTfull en RESTlike maar eerst de verschillen tussen Traditioneel, SOI en SOCCI infrastructuur op een rij.

12

Jambo ConsultancyŠ

28 februari 2013

[CLOUD COMPUTING STANDAARD; CAMP EN REST API]

Traditionele

SOI

SOCCI

ICT Infrastrucuur

ICT Infrastrucuur

ICT Infrastrucuur

Eigenhandig vormgegeven

Eigenhandig vormgegeven

Geautomatiseerd

Dedicated hardware

Dedicated of shared hardware

Shared hardware

Niet Schaalbaar

Schaalbaar

Schaalbaar

Pay for capacity

Pay for capacity or for use

Pay for use

Vaste and operationele kosten Vaste and operationele kosten Gemanaged via systeem administratie.

Operationele kosten

Gemanaged via systeem Gemanaged via API of andere administratie, via API of andere vorm van automatisering vorm van automatisering

Statische omgeving

Dynamische omgeving

Dynamische omgeving

Scheduled configuration

On-demand resource usage

On-demand resource usage

Voornamelijk invloed Middleware benutten

Infrastructuurdiensten benutten

Infrastructuurdiensten ten volle benutten

Contract-based payment

13

Contract-based payment met specificatie elementen

Specificering met Charge-Back maar ook contract-based payments gebaseerd op werkelijk verbruik en vooraf gedefinieerde drempels

Jambo ConsultancyŠ

28 februari 2013

[CLOUD COMPUTING STANDAARD; CAMP EN REST API]

Representational State Transfer (REST) Wordt de REST API zoals geformuleerd door CAMP voor het krijgen van een Cloud Computing standaard RESTfull of RESTlike? Dit laatste hoofdstuk over een Cloud Computing standaard introduceert REST. Een REST API moet Cloud Computing klanten goede performance, schaalbaarheid, eenvoud, aanpasbaarheid, zichtbaarheid, overdraagbaarheid en betrouwbaarheid garanderen.

Voor het begrijpen van de REST API is het volgende 20 minuten durende Youtube college een aanrader.http://youtu.be/llpr5924N7E In dit college komen de 6 restricties die van een RESTlike API een RESTfull API maken aan de orde. Deze zijn; 1. Cliënt-server Een uniforme interface scheidt de cliënts van de servers. Deze scheiding zorgt er bv. voor dat cliënts geen gegevens opslaan, dit blijft een eigenschap van de interne server waardoor overdraagbaarheid van cliëntcode behouden blijft. Servers zijn niet bezig met de gebruikersinterface of gebruikersaspecten waardoor servers eenvoudiger schaalbaar zijn. Servers en cliënts kunnen worden vervangen en onafhankelijk verder ontwikkeld, zolang de interface tussen beide maar niet veranderd.

2. Statusvrij De cliënt-server communicatie wordt verder beperkt doordat er geen enkele cliënt content wordt opgeslagen op de server. Elk verzoek van een cliënt bevat alle informatie die nodig is om aan die aanvraag te voldoen en elke aanvraagstatus wordt bijgehouden op de client zelf.

3. Cacheable (in een tijdelijk geheugen opgeslagen) Net als op het World Wide Web kunnen klanten reacties cachen. Reacties moeten dus, impliciet of expliciet, zichzelf kunnen opslaan om door klanten hergebruikt te kunnen worden of juist niet als het om verouderde of onjuiste gegevens gaat. Een 14

Jambo Consultancy©

28 februari 2013

[CLOUD COMPUTING STANDAARD; CAMP EN REST API]

goed beheersbare manier van caching elimineert gedeeltelijk of volledig sommige cliënt-server interacties en het verder verbetert daardoor de schaalbaarheid en prestaties.

4. Gelaagd systeem Een cliënt kan gewoonlijk niet zeggen of deze rechtstreeks met de server of via een intermediair communiceert. Intermediaire servers kunnen de schaalbaarheid van het systeem verbetert door Load-Balancing en door gedeelde caches. Zij kunnen ook het beveiligingsbeleid afdwingen.

5. Code On Demand (optioneel) Servers kunnen de functionaliteit van een cliënt tijdelijk uitbreiden of aanpassen door de overdracht van de uit te voeren code. Voorbeelden hiervan zijn bv. samengestelde componenten, zoals Java-Applets en client-side scripts, zoals JavaScript.

6. Uniforme interfaces De uniforme interface tussen cliënt en servers vereenvoudigt en ontkoppelt de architectuur zodat die elk voor zich in staat is om zich zelfstandig te ontwikkelen. De vier leidende beginselen van deze interface worden hieronder beschreven. Een RESTful webservice (web API) is een web service met behulp van HTTP en de beginselen van REST. Het is een verzameling van middelen met de volgende vierkenmerken: 1. een op URI gebaseerde web service, bv. http://example.com/resources/ 2. de gegevens worden met het medium internet ondersteund door de webservice. Vaak is dit een XML-object of kan een andere geldige Internet mediatype zijn onder de voorwaarde dat het een geldige standaard soort hypertext is.

3. een reeks handelingen ondersteund door de webservice via HTTP methoden (bv. GET, PUT, POST, of DELETE).

4. de API moet hypertext gedreven zijn 15

Jambo Consultancy©

28 februari 2013

[CLOUD COMPUTING STANDAARD; CAMP EN REST API]

De enige optionele beperking van een REST architectuur is: "Code On Demand".

Zolang een REST API in strijd is met één van de vereiste overige 5 beperkingen kan het niet worden beschouwd als RESTful en daarom geen Cloud Computing standaard garanderen.

Conclusie …

16

Jambo Consultancy©