De Cloud is een heel ruim begrip, en er zijn tal van “XaaS” (X as a service) technologieën in omloop. APaaS (zie ook een aantal vorige blogs), IaaS, DBaaS… Allemaal hergebruiken ze wel ergens in hun definitie de nuttige eigenschappen van Cloud-technologie, zoals elastische schaalbaarheid en gedeeld gebruik van infrastructuur.

SaaS betekent Software as a Service. Dit wil zeggen dat men een gebruiksklaar product, zoals b.v. een webmail-applicatie, aflevert als een Cloud-dienst (en dus niet b.v. een server in de cloud, waarop men nog software moet plaatsen). Van SaaS kunnen we ook verschillende eigenschappen opnoemen, maar wat maakt nu écht het verschil tussen deze technologie en tussen de andere XaaS? M.a.w. waaraan, buiten dat het “Software” is en niet “Platform” of “Infrastructure”, kunnen we nu échte SaaS onderscheiden van de wannabe’s? Waar zit hem de Saus in de SaaS?

1. Multi-Tenancy as a Service, maar dan echt!

Een SaaS toepassing kenmerkt zich door het feit dat het één internettoepassing is die door meerdere klanten, of ‘tenants’ kan worden gebruikt, en dit via zelfservice. Uiteraard is er daarbij nog een verschil met de typische Cloud-diensten die we als particulier kunnen gebruiken, zoals Dropbox, Gmail, Twitter, etc. Bij een echte SaaS is het zo dat de tenants ook grote klanten kunnen zijn, die het product als het ware ‘huren’ om het te laten gebruiken door hun eigen (eind-)gebruikers. Typisch dus b.v. een instelling die zijn eigen interne e-mailsysteem via Gmail wil laten werken, of een bedrijf dat Dropbox gebruikt om een intern File sync & share systeem op te zetten. Kortom: er zijn typisch 3 partijen aan het werk: de aanbieder van de dienst, de klant of ‘tenant’ en de eindgebruiker.

Enerzijds is het dus belangrijk dat deze multi-tenancy via zelfservice kan worden opgezet om van SaaS te kunnen spreken: typisch zal een tenant via een webportaal een speciale account kunnen aanmaken, waarmee hij zijn afgehuurd deel van het software-systeem kan beheren. Dit houdt o.a. user management in, en het beheer van de kosten.

Anderzijds is ook van doorslaggevend belang op welke manier er aan multi-tenancy wordt gedaan. Doorgaans is er nood aan een zekere vorm van isolatie tussen de verschillende tenants, die ervoor zorgt dat ze a.h.w. “geen last hebben” van elkaar. Concreet betekent dit o.a. dat gebruik van een grote hoeveelheid bandbreedte, cpu-tijd, of schijfruimte door één tenant geen nadelig gevolg mag hebben op die van andere tenants. Iedereen zal dus een bepaald quota krijgen. Ook wanneer eventueel fouten in het programma optreden bij één tenant, moet worden vermeden dat deze zich uitbreiden naar de andere. Kortom, voor elke tenant moet aan een bepaalde Service Level Agreement (SLA) kunnen worden voldaan, los van de andere tenants.

Ook functioneel kunnen er trouwens zaken zijn die tenants graag geïsoleerd zien. Zo is het uiteraard vanzelfsprekend dat tenants geen toegang hebben tot elkaars data (tenzij ze dit expliciet willen als extra functionaliteit).

2. Aardappelen, SLA? Alles apart betalen!

Nog typisch aan een SaaS product is dat de service betaald wordt op basis van verbruikscriteria, en niet op basis van vaste contracten. Wie meer verbruikt – of wil verbruiken – of wie een betere service wil, kan daarvoor dus bijbetalen. Dit soort van facturatie kent verder nog twee varianten:

• Het “McDonald’s” model. Dit is het zuivere “pay-per-use” model: Net zoals men bij een hamburgerrestaurant elke burger, elk pak friet en de saus allemaal apart betaalt, doet men dit ook voor sommige Cloud diensten. B.v. het maximum aantal GB dat gedurende een bepaalde maand werd ingenomen aan opslag, of het aantal gebruikers dat gedurende een bepaalde maand lid was. Normaal gezien zijn er geen kosten indien niets wordt verbruikt, al komt dit model ook vaak gecombineerd voor met het tweede model.
• Het “All you can eat” model. Bij dit model, dat werkt via de zogenaamde “monthly subscription”, betaalt men een vast maandelijks bedrag om binnen een bepaald quota te verbruiken wat men wil, net zoals men – per persoon – kan eten wat men wil in de gelijknamige restaurants. B.v. 9,99 dollar per gebruiker per maand voor 100 GB opslag (huidige prijs bij Dropbox Pro), of je ze nu leeg laat staan of opvult. Zoals gezegd kan men dit model soms ook aanvullen met het eerste: men betaalt dan extra voor wat men verbruikt boven het vaste quota.

De gehele prijszetting en facturatie is typisch ook goed online op te volgen door de klant, in een apart administratief scherm van de toepassing, en kan, via de typische zelfservice, ook gemakkelijk worden aangepast aan de specifieke behoeften van de klant.

Ten slotte, zoals de titel van dit puntje al aangaf, is een goede SLA niet gratis: ook extra support zal men vaak, typisch via subscriptie, moeten bijbetalen. Dit kan dan typisch onder de vorm van “silver” of “gold” plannen, die men ook in andere branches van computing graag gebruikt.

 

3. De klant in controle, “Softwarematisch”

Zoals gezegd dient een SaaS gebruik te maken van zelfservice technieken. Deze zelfservice kan in een goed SaaS-product ook gebruikt worden om een aantal zaken per tenant te configureren en adapteren. Zo kan het bijvoorbeeld mogelijk zijn om een logo en kleuren aan te passen, maar b.v. ook om bepaalde beveiligingsregels in te stellen waaraan alle gebruikers van de tenant zich aan moeten houden.

Dit alles moet “softwarematisch” kunnen gebeuren in een goed SaaS-product. Dat wil zeggen, het mag niet de bedoeling zijn om manueel in configuratiebestanden zaken te gaan aanpassen en daarna het product te moeten herstarten. Eerder moet het mogelijk zijn om allerlei instellingen via panelen en wizards in de web-interface van de tenant te doen, en die – liefst onmiddellijk – in werking te laten treden.

 

 

Momenteel onderzoeken we hoe bestaande toepassingen “SaaS-Enabled” kunnen worden, d.w.z. dat we ze kunnen aanbieden als SaaS. Zoals je ziet komt daar dus heel wat bij kijken aan extra benodigde functionaliteit, en dit is dan uiteraard nog bovenop het typische Cloud-verhaal (het moet schaalbaar zijn, het moet op gedeelde infrastructuur draaien, …) Hierover meer in een volgende blogpost.