We zijn nu een aantal jaren verder met cloud computing. Door inzicht en gebruik verandert het inzicht over wat cloud computing is en voor wie.
Laat ik beginnen met mijn definitie en toelichting: Cloud computing is de vaardigheid van een bedrijf om een verzameling servers samen te laten werken.
Simpel toch? Cloud computing bestaat vooral uit het perspectief van de eigenaar van de servers. En eigenlijk is dit heel logisch. Want wat heeft Software as a Service nu met cloud computing te maken vanuit de afnemer? Vaak komt Software as a Service in de vorm van een applicatie die draait in de browser. De afnemer heeft werkelijk ‘niets’ met cloud computing te maken! De applicatie kan draaien op een enkele server die ergens bij iemand op zolder staat. Hooguit kun je zeggen dat je de applicatie afneemt over het internet en dat het internet vaak aangeduid wordt als cloud.
Dus nog een keer: cloud computing gaat op voor de de eigenaar van de servers, niet per se op de gebruikers van de servers, al kan dit uiteraard hetzelfde bedrijf zijn en krijgt de term ‘private cloud computing’ meteen ook weer betekenis!
Virtualisatie
Alle huidige cloud computing volgens mijn gestelde definitie maakt gebruik van bestaande technologie en leunt sterk op het gebruik van hypervisors. Een hypervisor is een laag tussen het besturingssysteem van een server en de hardware. Een hypervisor is een soort illusionist die een besturingssysteem voor de gek houdt. Hiermee wordt het mogelijk om meerdere virtuele servers op één fysieke server te laten draaien, maar ook om deze server naar een andere fysieke server te verplaatsen zonder consequenties.
Een voordeel van een virtuele server is dat je deze ‘zwaarder’ en ‘lichter’ kan maken, zonder dat de onderliggende hardware hoeft te worden aangepast. De techniek van virtualisatie wordt ook gebruikt om softwarematig data-opslag mogelijk te maken, zodat je niet alleen een hogere performance krijgt, maar dat opslag ook veerkrachtig wordt. Als een element in de keten faalt, blijft de data gewoon bereikbaar.
Maar genoeg over techniek. De basis is dat cloud computing vooral gebruikt maakt van bestaande technologie en dat bedrijven hier zaken aan toevoegen om bijvoorbeeld zelfbediening en betalen naar gebruik mogelijk te maken.
Deze uitleg is nodig voor de volgende stap in mijn betoog. Namelijk dat bedrijven met dit zelf gemaakte maatwerk verschillende diensten kunnen aanbieden. Veel hosters kunnen nu middels een zelfbediening-portaal mogelijkheden scheppen dat klanten zonder tussenkomst van menselijk handelen virtuele servers en anderen diensten af kunnen nemen.
Amazon Webservices en Openstack
Nu stoort het veel mensen dat, als ik praat over cloud computing, ik het praktisch altijd heb over diensten zoals Amazon Webservices en Microsoft Azure. Dit komt omdat zij voorop lopen in hun competentie om grote groepen servers samen te laten werken en het product hiervan als diensten aan te bieden. Amazon is veelal gebaseerd op de technologie van Citrix, Microsoft Azure is uiteraard gebaseerd op technologie van Microsoft.
Zo is er ook een open source project : Openstack. Deze biedt in feite volledige software aan die het mogelijk maakt om servers samen te laten werken, inclusief een portal om dit te beheren. Deze software is gratis, dus ieder bedrijf dat servers en serverruimte heeft kan deze software installeren en een cloud computing provider worden, als is je onderscheidend vermogen in de basis beperkt.
Api is de sleutel
Een zeer belangrijk onderdeel van cloud computing-dienstverleners is dat ze een application programming interface (api) aanbieden. Ofwel je kunt met regels programma code de dienst consumeren en daarmee maak je nog meer automatisering mogelijk. Uiteraard is IaaS niet alles wat de klok slaat. Diensten zoals Orchestrate.io bieden database als dienst aan wat aangemerkt wordt als Platform as a Service (PaaS) en Dropbox biedt bijvoorbeeld Software as a Service in de vorm van data synchronisatie. Het aardige van Dropbox is dat zij zelf een dienst hebben gebouwd, bovenop een dienst van een andere cloud computing provider en daarop meeliften. En dit illustreert eigenlijk het punt wat ik wil maken.
Cloud computing is heel breed met de huidige definitie zodat er moeilijk een goede discussie over gevoerd kan worden. Het afnemen van infrastructuur is totaal iets anders dan een applicatie die functioneert in de browser. Voeg daar de ruis van hybride cloud computing aan toe, plus de eigenschappen van specifieke cloud diensten en de waarde van al die artikelen daalt hard naar een nulpunt qua toegevoegde waarde.
Dit verklaart waarom ik het zo vaak over Amazon Webservices (AWS) heb. Zij zijn voor mij het voorbeeld over waar het naar toe gaat en waar ik ook naar toe zou willen. Amazon is meesterlijk goed in het ontsluiten van bestaande technologie en de medewerkers hebben een extreme customer focus, maar zij ontwikkelen ook technologie die hiaaten opvullen. Zij luisteren naar geluiden in de markt, faciliteren deze en door middel van continuous delivery verbeteren dit met een ongekende snelheid. Daarnaast hebben zij een ongeschreven regel, welke het fundament is van automatisering: alle functionaliteit kan via een api geconsumeerd worden.
In het kort
Ik zal het nog een keer samenvatten. Cloud computing is een vaardigheid. Cloud computing borduurt verder op huidige technologie. Cloud computing is vaak een competentie van de leverancier, niet van de afnemer. Cloud computing wordt versterkt door api’s. Uiteindelijk gaat het niet om cloud computing, maar om de dienst die daar uit voort komt. De discussie zou dus niet zozeer moeten gaan over de betekenis van cloud computing, maar meer over de diensten die daar uit voortkomen.
@HBen het met je eens dat de cloud vele gezichten heeft de webservices, SaaS, die onder de noemer cloud vallen of aan de andere kant op een laag technisch niveau de IaaS waarbij het gaat om het flexibel alloceren van resources. In je definitie van cloud kan ik me niet vinden, de vaardigheid om server samen te laten werken. Dat is iets wat ook al gedaan werd voordat de cloud bestond.
Maar ja, hoe zou je de cloud dan wel omschrijven? Gelukkig is daar @Ad met zijn reactie. Vind de quote de spijker op zijn kop en het beste wat ik tot nu toe over de cloud gelezen heb. Treffende omschrijving van de cloud vanuit een technische standpunt en het pdf document geeft ook een heldere uitleg van alle gangbare cloud begrippen. Eigenlijk verplichte kost.
Louis; grappig, ik doe -de verkeerde- aanname dat iedereen de NIST definitie al van haver tot gort kent. Ik kan me dus niet goed vinden in de definitie! Zeker omdat dan 90% van de niet SaaS diensten dus geen cloud computing is volgens deze definitie en het gros van SaaS dus wel als cloud computing wordt aangeduid, maar het technisch gezien niet is.
Niettemin ben ik geen purist hoor! Juist omdat het zo’n grijs gebied is moet je niet teveel blijven hangen in definities en gaat het uiteindelijk om praktische toepassingen.
Henri,
Mooi betoog, maar ik heb natuurlijk wel een aantal kritische opmerkingen te maken. In het verlengde van eerdere discussies, maar het kan nooit kwaad deze nog eens met andere woorden te herhalen 🙂
Allereerst je omschrijving van cloud computing: “de vaardigheid van een bedrijf om een verzameling servers samen te laten werken.”.
Het laten samenwerken van servers is problematisch als je via Google op zoek gaat naar omschrijvingen van “samenwerken” of “samenwerking”.
Bijvoorbeeld:
“het richten van de inspanningen van twee of meer personen of instanties op hetzelfde doel”
“Samenwerken kan worden gedefinieerd als het gezamenlijk inzetten om een bepaald doel te bereiken. Samenwerking vindt plaats tussen minimaal twee personen, dus ook in een groep of tussen meerdere groepen. Samenwerken wordt gezien als een belangrijke competentie omdat het een efficiënte manier is om doelen te bereiken. “
Enz. enz.
De vraag is dus: hoe kunnen database-servers, applicatie-servers en alle andere soorten servers die je maar kunt bedenken in een n-tier architectuur nu met elkaar samenwerken om bepaalde doelen te realiseren? Samenwerking vindt toch plaats op het niveau van zelf-standige wezens (personen, instanties)?
In de tweede plaats, aanhakend bij de (zoals altijd) mooie reactie van Felix: je betoog is op z’n hoogst 4GL, terwijl je met 5GL nu juist veel meer uit cloud computing zou kunnen halen.
Op zich is Cobol of Java 3GL; echter, door steeds meer functionaliteit onder te brengen in procedures en functies evolueren dit soort 3GL-talen richting 4GL. Door procedure- en functie-aanroepen kun je met steeds minder regels code steeds sneller nieuwe applicaties ontwikkelen. Eigenlijk zijn API’s op hetzelfde principe gestoeld, met dit verschil dat de aangeroepen procedures of functies niet meer op hetzelfde platform hoeven te draaien en ook in een andere taal ontwikkeld kunnen zijn. Op dat moment wordt dan ook gesproken van services ipv. procedures en functies.
Deze aanpak levert precies de procesgeoriënteerde visie op services op: services zijn processen met invoervariabelen en uitvoervariabelen, zoals beschreven in de API. Je blijft hiermee dus hangen in het procedure-data paradigma, wat ten hoogste 4GL is: actieve procedures verwerken passieve data volgens een input-process-output cyclus. Steeds moeten de invoervariabelen bij aanroep bekend zijn, en de uitvoervariabelen worden teruggegeven aan het aanroepende proces. Bij een 5GL worden services niet meer beschouwd als processen, die aaneengeschakeld moeten worden met bijvoorbeeld BPM-flowcharts (ook wel orkestratie genoemd), maar als actieve doelen, die zichzelf realiseren door het uitvoeren van de benodigde subdoelen. Zoals reeds eerder betoogd vormen beslissingstabellen hier de essentiële 5GL-techniek.
Bij het toepassen van procestechnologie (3GL/4GL) – de taal van ICT – ga je van input naar output door middel van een stapsgewijze verfijning van processen; bij het toepassen van kennistechnologie (5GL) – de taal van de business – ga je van output naar input door middel van een stapsgewijze verfijning van doelen.
Ik mag hopen dat je opmerking over 7GL een grapje is, hoewel in het verleden hier al eens een – beslist niet onaardig – opiniestuk aan is gewijd (“Outsourcing overbodig met 7GL”). Maar het idee van 7GL is natuurlijk onzinnig, zolang 5GL nog een punt van discussie is en we nog geen idee hebben wat een 6GL zou kunnen inhouden.
@Henri Dat is dan een verkeerde aanname, dit was de eerste keer dat ik dit artikel las van het NIST. Ik ben het niet met je eens dat het een artikel is wat vooral over het bussinessmodel van de cloudproviders gaat. Ik heb het niet gelezen (summier), ik lees vooral computerterminologie. Ook de definitie van SaaS klonk heel begrijpelijk en helder. Heb nog een paar keer gelezen en blijf het een hele treffende beschrijving vinden.
Dat in de praktijk er (web) diensten verkocht worden onder de noemer SaaS maar dat volgens deze definitie niet zijn dat geloof ik ook. Nu ben ik wel een purist maar vind dat ook niet zoveel uitmaken. Als het om online diensten gaat die een ICT oplossing voor een bedrijf bieden doet dat er niet zoveel toe vind ik ook. Dat de cloud er te pas dus te onpas bij gehaald wordt, daar moet je dan maar even doorheen prikken.
Louis, de NIST definitie wordt in de “cloud” wereld als de feitelijke standaard gezien. Verder vind ik het ook niet zo interessant, waar nu val ik in de herhaling.
Jack, +1 voor je opsomming over samenwerken 🙂
Wat ik bedoel is dat bijvoorbeeld : 3 servers ervoor zorgen dat een website up and running is en blijft en dat er een 4e server wordt aangeschakeld als de druk op de performance toeneemt. Dat bedoel ik bijvoorbeeld als samenwerken. Of meerdere servers die dezelfde data hosten voor performance en redundancy
“…maar als actieve doelen, die zichzelf realiseren door het uitvoeren van de benodigde subdoelen.”
Kun je hier concrete voorbeelden van geven, het is nog iets te abstract, ik mis wat haakjes om te begrijpen wat je zegt. Hiermee, meteen mijn punt. Als ik al niet goed begrijp wat je bedoeld, hoe kan dit dan ooit mainstream worden?
Mijn grapje over 7GL is vooral om aan te geven dat we tzt zelf geen code meer zullen schrijven, maar dat we praten of denken en dat een computer dat interpreteert en dit realiseert. Een voorbeeld: Ik heb een database met organisaties en hun klanten (consumenten). Nu komt er een organisatie met zijn klanten bij en dit bestand, of de API die deze gegevens kan leveren wordt aangeleverd. Nu is dat een klus: Converteren naar een formaat, mappings maken naar de diverse velden en evt. functies om de data te schonen of uit elkaar te trekken (adres regel netjes vertalen naar straat, huisnummer, huisnummer toevoeging, misschien anders als het een buitenlands adres is). Wat op termijn mogelijk moet zijn is dat je het systeem gewoon de opdracht geeft om een nieuwe organisatie aan te sluiten. Het systeem vogelt zelf wel uit hoe de data in elkaar steekt, en wat waar hoort. En waar het systeem een probleem of vraagt heeft, kan deze die terug stellen, denk dan bijvoorbeeld aan: Ik zie rijen zonder postcode, wat moet ik daarmee? Waarop ik dan antwoord “Niet importeren en terugkoppelen”.
Of mooier nog; mijn systeem stelt vragen aan het systeem van de organisatie en ze voeren zelf wel het dialoog. Dit kan pas als we een heel fijnmazig web hebben van patronen die hiërarchisch zijn opgebouwd. Net als assembler krijg je dan een heel low level taal met laagjes op laagjes zodat er uiteindelijk ook een high level taal uitkomt waarbij de programmeur niet alle lagen hoeft te snappen… Nouja, ik sla los 🙂 Enne 7GL was vooral om aan te geven: In de (verre) toekomst.