De cloud is (nog steeds) één van de allergrootste hypes in de geschiedenis van computertechnologie en vraagt om een evolutie waar geen enkele instelling, publiek of privé, aan kan ontkomen. Op business niveau biedt ze tal van nieuwe mogelijkheden, maar ook risico’s. Het is dus van belang goed voorbereid te zijn om op een optimale manier te kunnen instappen in het cloudverhaal.

Een spanningsveld dat momenteel sterk speelt bij vele organisaties, is dat van public versus private. Meer bepaald: zal men gaan gebruik maken van diensten in de public cloud, aangeboden door externe, veelal Amerikaanse, leveranciers, of probeert men eerder een eigen cloud uit te bouwen, in het eigen datacenter, waarop men dan zelf de nodige diensten kan aanbieden en uitbaten? De eerste optie zal vaak de goedkoopste zijn, aangezien de public cloud-spelers kunnen profiteren van een enorm schaalvoordeel. Het alternatief wordt vooral aantrekkelijker doordat het als veiliger en betrouwbaarder wordt beschouwd, omdat men de volledige controle behoudt over de eigen infrastructuur en – vooral – data. Zeker in perspectief van recente spionageschandalen lijkt het geen overbodige luxe om de data binnen de eigen landsgrenzen te houden.

In deze blog zullen we dus de tweede visie aanhangen: die van het belang van controle over de eigen data, zeker wanneer het gevoelige, persoonsgebonden of zelfs medische data kan betreffen. We gaan dan ook kijken naar mogelijkheden om een private cloud zo functioneel mogelijk te maken, en dit liefst aan een zo klein mogelijke kost.

Specifiek in deze tekst zullen we onderzoeken wat de mogelijkheden zijn om software, die reeds werd ontwikkeld voor stand-alone gebruik, aan te bieden als cloud-dienst. We gaan dus kijken wat we kunnen doen om deze bruikbaar te maken als Software as a Service (SaaS). Concreet zullen we zien hoe we voor onze klanten of tenants een instantie van een bepaald software-pakket op aanvraag kunnen lanceren; Instance as a Service dus!

Om dit te doen hebben we eerst en vooral een aantal mogelijkheden die reeds voor ons worden voorzien in de IT-wereld. Zo bestaan er al langer oplossingen voor het snel gereedmaken van virtuele servers, en we zoomen ook nog in op Containers, een technologie die reeds op korte termijn de Cloud op haar grondvesten heeft doen daveren. Ten slotte doen we een zelf ontwikkelde methode uit de doeken.

1. Kant-en-Klare Servers

Indien men een bestaand IaaS aanbod heeft, en dus virtuele machines aanbiedt via de Cloud, kan men opteren voor het aanbieden van een hele resem aan virtuele machines waar reeds nuttige software is op voorgeïnstalleerd. Verschillende voorbeelden hiervan zijn te vinden in de publieke Cloud.

Bitnami stelt images van virtuele machines gratis ter beschikking op zijn website, met ondersteuning voor meer dan 100 populaire webtoepassingen, zoals WordPress en Drupal. Daarnaast bieden ze ook installatiebestanden (“stacks”) aan om deze op een reeds bestaande machine te installeren, met inbegrip van alle onderliggende middleware, zowel voor Windows, Linux, als Mac. In de public cloud (Amazon, Google en Microsoft) biedt Bitnami tevens aan om de images naar iemand’s cloud account te sturen en de machine rechtstreeks aan te maken en op te starten. Dit heet dan Bitnami Cloud.

Een concurrent van Bitnami is Turnkey. Ook dit bedrijf biedt images van virtuele machines aan voor een groot aantal populaire toepassingen. Er zijn een aantal verschillen met Bitnami: Turnkey biedt b.v. enkel zijn pakketten aan voor Linux servers. Daarbij is het wel zo, dat Turnkey de standaard mechanismes van software installatie op deze machines volgt, terwijl Bitnami een aangepaste manier gebruikt. Hierdoor zijn de virtuele machines van Turnkey achteraf gemakkelijker op de standaard manier van Linux te onderhouden (via de package managers). Om een major update te doen van een Bitnami pakket (met inbegrip van de middleware), raadt men daarentegen meestal aan om een nieuwe machine op te zetten en de data van de oude naar de nieuwe te migreren (kleinere updates kan men typisch uitvoeren via de webinterface van de desbetreffende toepassing).
Bij Turnkey is er ook een iets grotere focus op modulariteit. Zo zou men b.v. bij een WordPress installatie kunnen opteren om de achterliggende MySql database op een aparte Turnkey machine te plaatsen. Bij Bitnami heeft men deze mogelijkheid niet. Uiteraard zorgt dit voor een grotere complexiteit, waardoor Bitnami een groter gebruiksgemak heeft.

Samengevat zou men dus aan Cloud klanten eveneens zo’n groot aanbod aan verschillende virtuele machines kunnen aanbieden, waarbij ze dus bij hun gebruik van IaaS konden gebruikmaken. Zolang de applicaties niet te intensief gebruikt worden, passen deze netjes binnen één virtuele machine. Wanneer er echter moet worden geschaald, zijn ze hier niet meer goed voor aangepast.

Containers

Container technologie is één van die dingen die al een hele tijd bestaan zonder dat er een haan naar kraait, en dan plots fenomenaal doorbreken als hype. Eerder stond de technologie vooral bekend als virtualisatie op het niveau van het besturingssysteem (Operating-System-Level Virtualization). Containers kan men beschouwen als een soort ‘light-weight’ virtuele machines: het zijn eigenlijk “stukjes computer” die men binnen een machine inneemt en die men via (Linux) beveiligingstechnologie perfect geïsoleerd houdt van de rest van de machine en van andere containers. In een container kan men dan alle programmatuur en configuratie stoppen voor een applicatie.

Men kan dan twee richtingen uit: zoals bij de virtuele machines kan men in principe een hele software stack in zo’n container stoppen en aldus een werkend en netjes geïsoleerd pakket bekomen, dat men op eender welke machine die de technologie ondersteunt, kan laten uitvoeren (‘build once, run anywhere’). Maar waar containers echt in uitblinken, is in modulariteit: elk deel (‘component‘) van een systeem kan men in een andere container stoppen en dan met elkaar laten communiceren (e.g. het web gedeelte en de database apart).

Over deze technologie kan nog heel veel gezegd worden, maar om applicaties aan te bieden aan klanten, is het voldoende te weten dat men ook van deze containers een heel aantal prototypes kan verzamelen met allerlei nuttige applicaties erin, net zoals men met de virtuele machines kan. Docker biedt zelfs al zo’n plaats aan waar vele mensen vrijwillig toe bijdragen (de Docker Hub). Het volstaat dan om daarnaast op de private Cloud een Container ondersteunend platform aan te bieden en eventueel een GUI om het opstarten van een standaard container nog wat te vergemakkelijken.

3. Instance as a Service

Bij Onderzoek hebben we een studie aan dit onderwerp gewijd, waarvan binnenkort een research nota zal verschijnen. Onze methode om instanties van applicaties aan te bieden, maakt sterk gebruik van een aPaaS platform. Een aPaaS platform ondersteunt namelijk de schaalbaarheid van de erop ontwikkelde toepassingen, en zal zelf ook erg elastisch kunnen schalen, gezien erop uitgerolde applicaties kunnen komen en gaan. aPaaS platformen nemen dus al een groot deel van de effort om efficiënt gebruik te maken van de onderliggende machines, voor hun rekening. Op die manier krijgen we dus de schaalbaarheid en elasticiteit op het niveau van het platform cadeau!

Onze methode werkt als volgt: We kijken eerst of er reeds een “instant app” beschikbaar is voor het aPaaS platform dat we gebruiken. Dit zijn voorverpakte applicaties die er reeds op gemaakt zijn op ons platform te werken. Indien zo’n instant app bestaat, is het gemakkelijk: we kunnen deze dan eenvoudigweg gebruiken en enkel het lanceren van nieuwe instanties moeten we dan nog automatiseren tot er voldoende self-service is. Dit laatste doen we door een catalogus-applicatie te voorzien waar we snel de instant apps aan kunnen toevoegen.

Wanneer er nog geen instant app bestaat, moeten we deze zelf ontwikkelen op  basis van de broncode van de bestaande applicatie die we wensen aan te bieden. Dit is een iteratieve procedure die uitgewerkt is in bovenstaande figuur, maar waar we in deze blog niet in detail op in zullen gaan. We kunnen wel zeggen dat het slechts een kleine tot matige hoeveelheid werk is, zeker voor iemand die bekend is met de broncode-taal van de betreffende toepassing.

Wat we ten slotte niet mogen vergeten, is onderhoud: Er zullen namelijk geregeld updates komen van de toepassing die we hebben aangepast, en we willen deze natuurlijk graag incorporeren in ons SaaS aanbod. Ook deze 4e fase is te zien in de figuur, maar gaan we niet verder detailleren in deze blog.

4. Een vergelijking

Het grote voordeel van onze methode is dat we schaalbaarheid cadeau krijgen, dankzij het onderliggende aPaaS platform. Bovendien zorgt ze voor een efficiënter gebruik van resources, zeker tegenover de oplossing gebruik makende van virtuele machines. Daarnaast kan de aanwezigheid van een aPaaS platform ook nog zorgen voor een gemakkelijker beheer van ondersteunende diensten, zoals logging en monitoring van de applicaties.

Het nadeel van een eigen methode te hebben is dat we zelf het werk moeten doen, terwijl dit bij gebruik van b.v. de bestaande vm’s of Docker containers veel minder het geval is. Op die manier wordt het gevaarlijk om zomaar allerlei software te gaan aanpassen, wanneer we niet op voorhand weten of er voldoende afname zal zijn.

Le cloud est en train de révolutionner le monde de l’informatique. En effet, si l’Infrastructure as a Service et le Software as a Service (IaaS et SaaS) sont déjà profondément ancrés, la couche centrale de la pile du cloud – Platform as a Service (PaaS) – est à son tour en pleine progression. Cette fois, l’impact du cloud se fait sentir sur le développement de logiciels même. Dans cette étude, nous avons passé sous la loupe le plus grand groupe de produits PaaS, l’Application PaaS (aPaaS). Les plateformes aPaaS sont clairement axées sur la standardisation et l’automatisation d’une multitude d’aspects du développement, permettant une réduction du time-to-market, une baisse des coûts et une augmentation du service.

Presentation

De moderne “stack” voor applicaties in de Cloud, van IaaS (Infrastructure as a Service) over PaaS (Platform as a Service) tot SaaS (Software as a Service), is stilaan een gekend plaatje. Maar de strikte scheiding tussen het virtualiseren van infrastructuur, het automatiseren van middleware en het aanbieden van applicaties, en dit alles “als een dienst”, hoeft soms helemaal niet zo strikt te zijn.

In de Application Platform as a Service (aPaaS) branche, die reeds in een vorige blogpost uit de doeken werd gedaan, kan men bijvoorbeeld verschillende soorten aPaaS onderkennen, die variëren van een dunne schil boven IaaS, tot een soort van “Applicatie-Ontwerp-SaaS” oplossingen. In deze blogpost een korte verkenning van deze wondere wereld.

1. Vlak boven de infrastructuur

Sommige PaaS platformen bieden geen ingebouwde applicatieserver of database aan, maar vormen een laag bovenop de infrastructuur die het gebruikers makkelijker maakt om de nodige technologie geïnstalleerd en geconfigureeerd te krijgen op (niet noodzakelijk) virtuele servers.

Een voorbeeld is Cloudify. Bij deze aPaaS kan men als gebruiker een applicatie definiëren aan de hand van een recept. Dit recept stuurt men dan naar een Cloud met Cloudify ondersteuning, waardoor het platform de nodige “ingrediënten” van het recept in gebruik zal nemen. Het grote voordeel, zo stelt Cloudify, is dat recepten niet Cloud-specifiek zijn, en dat ze dus op de meeste Cloud systemen kunnen werken. Dit is b.v. nuttig voor het migreren van applicaties van de ene Cloud naar de andere.

2. Middleware als dienst

De bekendste aPaaS platformen bieden doorgaans een sterke integratie met web- en applicatieservers, en met diensten voor gegevensopslag. Sommige focussen zich op ondersteuning van een welbepaalde technologie, andere op het werken met zoveel mogelijk van de populairdere frameworks van het moment.

Een belangrijk kenmerk van platforms op dit niveau, en voor mij één van doorslaggevend belang, is dat er abstractie wordt gemaakt van de onderliggende infrastructuur. Niet langer moet je rekening houden met op welke server wat komt te staan: je deployt naar een platform, en dit platform kiest transparant welke delen van jouw applicatie op welke resources terecht komen. Welke en hoeveel infrastructuur onderliggend zijn aan het platform, daar hoef je als ontwikkelaar dan minder wakker van te liggen. Bovendien is er bij platformen met deze eigenschap doorgaans enige ondersteuning voor failover, elastisch schalen en multi-tenancy (voor ontwikkelaars).

Architectuur in een Openshift Node

Dit keer kiezen we Red Hat OpenShift als voorbeeld. Dit aPaaS platform bestaat zowel in de publieke cloud, als in een “on premise” installeerbare versie, waardoor je het dus kan gebruiken voor een private Cloud. De basis van het platform is open source.

Wanneer we op deze PaaS inloggen, krijgen we een web console te zien met behulp van dewelke we applicaties kunnen deployen in de Cloud. We moeten daarbij kiezen uit welke “cartridges” een app bestaat. Cartridges kan men beschouwen als een technologisch afgezonderde module, e.g. een MySQL cartridge. daarnaast kiezen we ook hoeveel “gears” de applicatie krijgt, en of ze schaalbaar zal zijn. Gears (letterlijk vertaald: tandwielen of radartjes) zijn eenheden van computatie, ze stellen een bepaalde hoeveelheid processorkracht, geheugen en opslag voor, los van de onderliggende infrastructuur. De cartridges van de applicatie komen dan terecht op de gears en die laatste worden transparant gedeployed op het platform.

3. (Semi-)Grafisch Applicaties ontwikkelen

Dichter bij de SaaS-laag van Cloud platformen, vinden we producten terug die doorgaans gespecialiseerd zijn in slechts enkele onderliggende implementatie-, server- en database-technologieën. Deze specialisatie laat echter wel verregaande automatisatie toe, waardoor het mogelijk wordt om eenvoudige tot matig complexe applicaties te ontwikkelen zonder code te schrijven, of dit slechts in beperkte mate te doen.

Zoho Creator is bijvoorbeeld zo’n platform. Het richt zich vooral op applicaties die sterk gericht zijn op online databases. Zo kan men via drag and drop webformulieren aanmaken, waarvan de data dan in zo’n database zal terechtkomen en eventueel in een complexe workflow. Voorts kan men acties en triggers voorzien rond data-access. Verder kan men bepaalde taken automatiseren, zoals het versturen van emails en genereren van rapporten. Html pagina’s kan men dan verder aanpassen m.b.v. html en het zogenaamd “Deluge Script”, een taal eigen aan het platform.

 Besluit

Deze 3 voorbeelden van een genuanceerdere definiëring van wat aPaaS nu eigenlijk inhoudt, zijn, opnieuw, niet te beschouwen als de enige correcte onderverdeling. In de software-industrie zijn er ondertussen tientallen producten die zichzelf volgens de definitie PaaS mogen noemen, en nog veel meer die zichzelf de noemer geven zonder het strikt genomen te zijn, allemaal met hun eigen specifieke invulling van de term. Al deze producten staan allicht net iets verder of net iets minder ver van IaaS/SaaS dan de voorbeelden hier omschreven.

Dit is voor ontwikkelaars zowel een voordeel als een nadeel: Aan de ene kant biedt het voor elk wat wils, en voor elke applicatie die moet worden geschreven kan men het “ideale platform” vinden. Anderzijds kan dit standaardisatie tegenwerken, en laat dat nu net één van de kenmerken zijn die een aPaaS platform nuttig maken.

Over aPaaS verschenen onlangs een Research Note en Presentatie.