“as a Service”: een Waaier aan Mogelijkheden

Over PaaS en de brede lading die erdoor wordt gedekt

stack

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.

cloudify-screenshot

Een Cloudify recept

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).

openshift-screenshot

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

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.

3 thoughts on ““as a Service”: een Waaier aan Mogelijkheden

  1. Pingback: Instance-as-a-Service | Smals Research

  2. Pingback: I’m dreaming of a digital Xmas | Smals Research

  3. Pingback: Productiviteitsverhoging met PaaS | Smals Research

Leave a Reply

Your email address will not be published. Required fields are marked *