Het goedkoop aanbieden van diensten op je eigen cloud.
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.
Leave a Reply