Eén van de kenmerken van de ict-sector lijkt het overvloedige gebruik van afkortingen en (Engelstalige) buzzwords te zijn. In het kader van cloudapplicaties worden termen als cloud-enabled en cloud-native gebruikt. De eerste staat voor bestaande applicaties die na bepaalde aanpassingen op een cloudplatform kunnen draaien, terwijl cloud-native gebruikt wordt voor applicaties die dat al vanaf dag één doen. Negen van de tien keer stopt de discussie op dit punt zonder dieper in te gaan op wat nou precies die onderliggende verschillen zijn; waarom de ene applicatie cloud-enabled en de andere cloud-native is.
In de alledaagse praktijk wordt het stempel cloud op een groot aantal infrastructuurplatformen geplakt. Volgens definitie van het Amerikaanse Nist (National institute of standards and technology) zijn de vijf belangrijkste onderdelen van cloud computing: brede netwerktoegang, elasticiteit, meting van het gebruik (en pay-for-use), on-demand self-service en het delen van resources. Op basis van deze definitie benutten vele aanbieders de mogelijkheid om hun platform het stempel cloud geven, maar het helpt helaas niet om het verschil tussen cloud-enabled en cloud-native duidelijk te maken.
En dat is nodig, want als je de puristische definitie hanteert, bieden een groot aantal cloudleveranciers helemaal geen ‘cloud’. Regelmatig worden legacy applicaties van hun klanten zodanig gewijzigd dat ze kunnen draaien op een cloudplatform zonder daarbij te tornen aan hun (verouderde) architectuurprincipes. Deze zogeheten ‘cloud-enabled applicaties’ maken het mogelijk voor organisaties om bestaande functionaliteiten en componenten naar de cloud te migreren, zonder dat er al te ingrijpende veranderingen aan de bestaande applicaties gemaakt worden. Een cloud-enabled applicatie blijft echter per definitie, en van oorsprong, ontwikkeld voor gebruik in het traditionele datacenter, waardoor de applicaties zelf gewijzigd of aangepast worden om in de cloud te werken. Dat maakt dat de heersende opvatting dat cloudapplicaties per definitie kostenbesparend zijn onwaar.
Wat is het verschil?
In de volgende vier architectuurparadigma’s komt het verschil tussen cloud-enabled en cloud-native het sterkst naar voren:
Tight versus loose coupling. Als software enkele jaren of langer geleden werd geschreven, is het zeer waarschijnlijk dat deze sterk afhankelijk is van de onderliggende technologiestack, inclusief de fysieke hardware. Dit noemen we een ‘tightly coupled’-architectuur, waarbinnen software niet goed kan functioneren als het wordt gescheiden van zijn specifieke fysieke omgeving. Voor cloud computing is een ‘loosely coupled’-architectuur vereist, die elasticiteit centraal stelt. Daarvoor moet de software onafhankelijk kunnen draaien van de onderliggende hardware. Veel bestaande applicaties kunnen dat niet. Om die applicaties naar een cloud platform te migreren, zal de software dus dienen te worden aangepast.
Verticaal versus horizontaal schalen. De meeste bestaande applicaties zijn niet gemaakt om automatisch te kunnen schalen, bijvoorbeeld als het aantal transacties toeneemt. Schalen van dit soort applicaties vindt daarom plaats door de capaciteit van de onderliggende infrastructuur te vergroten, door meer rekenkracht en geheugenmodules toe te voegen. Dit wordt ook wel ‘verticaal schalen’ genoemd.
Cloud computing daarentegen gaat uit van het horizontaal schalen van applicaties. Is er meer capaciteit nodig dan worden de bestaande infrastructuurcomponenten ongemoeid gelaten en worden er extra componenten toegevoegd. Dit horizontaal schalen kan plaatsvinden op meerdere niveaus in de services stack, bijvoorbeeld op infrastructuur-, besturingssysteem- en database-niveau. Applicaties kunnen op die manier geautomatiseerd pieken en dalen in het gebruik opvangen en zijn daarmee een stuk flexibeler. Als een applicatie niet gebouwd is om horizontaal te kunnen schalen, vergt het een grote inspanning om de applicatie hiervoor aan te passen. Een inspanning waar meestal de business case niet voor rond te maken is.
Stateful versus stateless. Een stateless applicatie houdt geen rekening met informatie die uit eerdere verzoeken of reacties voortkomen, en is zich dus alleen bewust van de informatie die tijdens een specifieke request wordt verwerkt. De client, en niet de server, weet in zo’n situatie wat de exacte status van een transactie is. Dit heeft een aantal voordelen: als de server niet beschikbaar is, kan er nog steeds gewerkt kan worden op de client. De status van een transactie gaat niet verloren. De server wordt opnieuw opgestart, en de transactie wordt hervat (Rest). De meeste bestaande applicaties zijn niet ‘stateless’ maar ‘stateful’. Als de server niet beschikbaar is, is het totale systeem de status kwijt en kan het niet verder. Om volop gebruik te kunnen maken van de voordelen van cloudtechnologie zou je bestaande stateful applicaties moeten aanpassen en stateless moeten maken. Dat is heel veel werk, en vaak blijkt het compleet vervangen van een bestaande applicatie door een nieuwe cloud-native applicatie een realistischere benadering.
Fault tolerance vanuit de infrastructuurlaag of vanuit de middleware- en applicatielaag. Legacy applicaties zijn ontworpen om te draaien op een infrastructuurlaag die de nodige garanties biedt in termen van beschikbaarheid, bijvoorbeeld uitgedrukt in een zogeheten recovery time objective (rto) en recovery point objective (rpo). Rto is de beoogde tijd waarbinnen een proces moet worden hersteld na een ernstig incident, om onaanvaardbare gevolgen van een breuk in de continuïteit te vermijden. Rpo is de maximale beoogde tijd waarbinnen gegevens verloren gaan als gevolg van een ernstig incident. De rto geeft systeemontwerpers een limiet om mee te werken. Als de rto is ingesteld op vier uur, moeten alle data op continue basis op een tweede locatie worden opgeslagen. Dit is een vereiste omdat een dagelijkse backup en het op een andere locatie opslaan van die backup een onvoldoende maatregel is om aan de rpo te voldoen.
Dynamischer
Een cloudinfrastructuur is veel dynamischer, omdat het er vanuit gaat dat elke component
wel een keer verstek laat gaan. Applicaties moeten hierop voorbereid zijn en slechts een minimale teruggang in performance kunnen garanderen. Dat kan alleen door beschikbaarheid niet af te laten hangen van de infrastructuurlaag, maar door dit te regelen in de lagen daarboven, inclusief die van de applicatie zelf. Op deze manier wordt gesignaleerd wanneer een infrastructuurcomponent uitvalt, kan diezelfde component opnieuw opgestart worden en wordt data op meerdere plaatsen tegelijk opgeslagen.
Met andere woorden: de niet-functionele eisen worden door cloud computing omhoog geduwd in de architectuur en de dienstenstack. Bestaande applicaties houden zich hier niet mee bezig, want die verwachten dat dit soort garanties worden geregeld vanuit de infrastructuurlaag.
Verschillende platformen
Cloud-native applicaties zijn dus ontworpen en gebouwd op architectuurprincipes zoals loose coupling, statelessness en fault tolerance bij de middleware- en applicatielaag. Dat zorgt er voor dat cloud-native applicaties prima kunnen draaien op platformen zoals Softlayer en AWS, waar bestaande applicaties juist eisen stellen aan de onderliggende infrastructuur die meestal niet met deze platformen kunnen worden ingevuld. Sommige organisaties kiezen ervoor een enorme inspanning te leveren door legacy applicaties te herschrijven en geschikt te maken voor een cloudplatform, maar de ervaring leert dat die business case erg lastig hard te maken is.
De realiteit is dat je voor dergelijke bestaande applicaties veelal kiest voor een ander platform, voor een cloud-enabled platform in plaats van een cloud-native platform. Binnen de Nist-definitie zijn er vele manieren om de kenmerken van een ‘native cloud’ applicatie na te bootsen en daarmee het begeerde ‘cloud’ label opgeplakt te krijgen. Bij de beoordeling van clouddiensten is het echter nodig om de kenmerken, de karakteristieken van de geleverde clouddienst te beoordelen in relatie tot de eisen van de applicaties die draaien op die dienst.
Hostingoplossing
Als een bedrijf geen enkele hardware meer wilt bezitten noch het beheer van de infrastructuur wil oppakken, en vervolgens een derde partij vraagt om dat geheel als dienst aan te bieden, dan heeft dit bedrijf een hostingoplossing nodig. Hosting kan een perfect service model zijn voor een gebruikersorganisatie, maar de it-sector is erbij gebaat het label ‘cloud’ in dit soort gevallen te vermijden. Pas als de stap gemaakt wordt naar dienstverlening die voldoet aan de Nist-definitie zou je van cloud kunnen spreken, waarbij de platformkeuze bepaalt of je applicaties cloud-enabled danwel cloud-native zijn.
Marc Steenbergen, business development executive bij IBM
Goed artikel met de juiste verdieping!
Het aardige van cloud enabling is, dat het voor de leverancier ineens heel duidelijk wordt waar de meeste kosten worden gemaakt. Ga er maar vanuit dat dat een goede driver is om de applicaties daarom stapsgewijs de juiste architectuur te geven.
Verder zijn applicaties vaak zo gelaagd opgezet, dat je kunt kiezen op welke plekken je bv wel multi-tenancy gebruikt en waar meerdere instanties verstandiger kunnen zijn. Ik heb onderzoek laten doen naar multi-tenancy architecturen, en we hebben daar 22 tegen elkaar in werkende aspecten gevonden die de keus waar wel en waar niet beïnvloeden. Dat heeft ons veel geleerd hoe je cloud-native applicaties moet ontwerpen afhankelijk van de context. En dat levert niet altijd de meest pure shared-everything architectuur op.
Henri is natuurlijk al gauw tevreden maar ik kan er maar weinig verdieping in vinden omdat de volgende opmerking wel heel erg als het Bimodal IT idee van Gartner klinkt:
‘Sommige organisaties kiezen ervoor een enorme inspanning te leveren door legacy applicaties te herschrijven en geschikt te maken voor een cloudplatform, maar de ervaring leert dat die business case erg lastig hard te maken is.’
Nu is de ROI van nietsdoen echter wel dat je achterhaald wordt door de onaangename feiten van de werkelijkheid, de cloud is tenslotte geen architectuur maar een abstractie waar de paradigma verschuiving alleen maar gaat om het wisselende eigendom van de infrastructuur.
Of je hosting nu cloud of uitbesteding noemt is namelijk lood om oud ijzer, je bent per definitie al technisch failliet als je niet eerst de governance ontwerpt.
Goed artikel wat mij betreft dat terecht constateert dat het labeltje “cloud” vaak onterecht wordt geplakt door de formele definities (NIST, maar ook ISO bijv). met flink wat korrels zout toe te passen. M.b.t. applicaties mogelijk iets te nuanceren omdat je, ook voordat “cloud” bestond, applicaties wel degelijk kon maken op de manier zoals hierboven beschreven is. Service oriëntatie ontwerpprincipes (zie bijv. http://serviceorientation.com/serviceorientation/index) bestaan al lang en passen prima bij cloud-geschikte applicaties.
Dus ja, cloud heeft de wereld echt veranderd en het is geen kwestie van wat plamuren om cloud-geschikt te zijn, maar nee, de ontwerpprincipes bestaan al langer en werden soms al prima toegepast.