La technologie cloud s’impose de plus en plus et le cloud public se taillera la plus grande part du gâteau vu sa promesse de versatilité supérieure et de coûts inférieurs. Toutefois, si l’on ne souhaite pas confier des données sensibles à des fournisseurs de cloud multinationaux, il convient de faire du cloud privé une alternative valable, capable de rivaliser par une utilisabilité accrue. Le SaaS Enablement, qui consiste à remanier une application de telle sorte qu’elle puisse être proposée dans un contexte cloud sous forme de SaaS, figure parmi les moyens susceptibles d’augmenter le pouvoir d’attraction d’un cloud privé. Dans ce texte, nous aborderons les possibilités pour cette stratégie et verrons comment les appliquer moyennant un effort minimal. Le résultat s’appelle Instance as a Service, une méthode de SaaS Enablement relativement simple et rapide, qui tire au maximum profit d’une plateforme aPaaS sous-jacente. Le SaaS Enablement n’est toutefois qu’une pièce du puzzle : la grande valeur ajoutée est à chercher dans les possibilités d’intégration poussée (“Enterprise Enablement”) et les services supplémentaires.

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.

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.

La mise à disposition d’une infrastructure (IAAS), d’une plate-forme (PAAS) ou d’un logiciel (SAAS) dans le Cloud sont aujourd’hui entrés dans les usages de l’IT moderne.

Un autre phénomène est occupé à se développer, celui que j’appellerai le TAAS ou Tool As A Service. Un subset du SAAS mais qui mérite d’être mis en évidence.

Occupé à gérer la mise en place d’une solution de e-learning, d’entrée de jeu, et autant que possible, j’ai pris l’option de m’inscrire dans la philosophie du Cloud (ou de l’externalisation pour le dire avec un terme plus ancien).

Les contraintes sur la performance et la disponibilité de l’application étant élevées, la question s’est rapidement posée de choisir les moyens pour les mesurer et les contrôler.
Soucieux de rester dans une logique de minimalisation des coûts d’exploitation, et donc de miser là aussi sur l’effort de mutualisation des ressources (matérielles et humaines) propre au Cloud, mes recherches m’ont fait découvrir trois solutions à priori intéressantes (il faut évidemment évaluer couverture fonctionnelle, fiabilité, disponibilité, pérennité, …) :

• PingDom (www.pingdom.com) pour les tests “is alive”, indispensables de mon point de vue pour la 1ère ligne de support;
• CloudCareNet (www.cloudnetcare.fr) pour les campagnes de tests de charge, que nous voulons pouvoir confier au gestionnaire de la plate-forme, donc à un profil plus administratif que véritablement technique.
• NewRelic (www.newrelic.com) qui combine tests de charge, application monitoring et server monitoring.

En première analyse, les coûts récurrents de ce type d’outil sont faibles au regard de ce que peuvent coûter les ressources humaines nécessaires à la mise en place d’une solution en interne. A étudier plus avant.

Des versions d’évaluation sont disponibles, voire des versions gratuites. Elles sont utiles pour se forger une première impression, mais une implémentation professionnelle digne de ce nom demande de s’appuyer sur les versions payantes.

Une question d’importance est évidemment de déterminer la qualité du support. En effet, pour arriver à utiliser au mieux ces solutions, une aide de l’éditeur s’avère rapidement  nécessaire. De mon point de vue leur avenir se jouera en particulier sur cet aspect. C’est d’ailleurs une question récurrente avec les solutions dans le Cloud : la proximité avec l’éditeur est-elle suffisante, et les modes d’interaction sont-ils bien organisés et efficaces. Loin des yeux, loin du coeur !

La pérennité est évidemment tout aussi importante. Personnellement je crains de voir se former une bulle Cloud comme s’est formée à l’époque une bulle Internet. Pour l’heure, la crise économique en limite vraisemblablement le risque.

Je voudrais encore citer un probable futur tool as a service, sans rapport avec les préoccupations du projet de elearning évoqué dans ce blog : Numara (www.numarasoftware.com) pour la gestion des postes de travail et de leur cycle de vie. Selon certains dires cette société envisagerait une offre dans le Cloud. Mais ceci reste à confirmer.

Au vu de ce qui précède on peut penser que l’outillage de “gestion technique” va lui aussi basculer progressivement (pour partie) dans le Cloud. Avec, comme pour les équipes de développement, quelques chamboulements à prévoir dans les habitudes des équipes concernées. S’il s’avère que la tendance permet de baisser les coûts sans altération du service aujourd’hui rendu par des équipes et des outils strictement internes, il y a fort à parier qu’il sera difficile d’y échapper à moyen ou long terme.

Le phénomène du Cloud est irréversible. Pour ceux qui n’en seraient pas encore convaincus je ne peux que conseiller la lecture du livre “The big switch”, Rewiring the World, from Edison to Google, de Nicholas Carr, a Wall Street Journal bestseller . Il explique de façon magistrale le parallèle entre l’évolution du marché de l’électricité au cours du siècle passé et celui de l’informatique. Ou le passage d’une production locale à une production globale, disponible via le réseau. Une bonne lecture parmi bien d’autres pour les longues soirées d’hiver ?

 This Web Page Created with PageBreeze Free HTML Editor

Het gebruiken van specifieke programmeeromgevingen heeft echter ook enkele vervelende nadelen:

• De output van de berekeningen uitgevoerd in deze programmeeromgevingen dienen vaak gebruikt te worden als input voor een nieuw programma, rapport, webapplicatie, … .  Dit is vaak een complex gegeven waarbij heel wat configuratie en integratie komt kijken;
• Analyses en berekeningen kunnen vaak nuttig zijn voor meerdere personen, instellingen, onderzoekers…  Het is weinig flexibel om analyses te delen met de requirement om een hele software stack te installeren.

Om code afkomstig van specifieke programmeeromgevingen makkelijker te delen en te integreren introduceert doctoraatsonderzoeker Jeroen Ooms ‘OpenCPU‘. OpenCPU is een centraal platform waarop men R-scripts kan plaatsen. De scripts die men op OpenCPU plaatst worden vervolgens automatisch beschikbaar als REST-services.  Deze services kan men makkelijk integreren in andere programmas/webapplicaties. Belangrijk is ook te vermelden dat OpenCPU een open-source platform is. Dit maakt het mogelijk om intern een eigen OpenCPU-server op te zetten (met de nodige beveiligingen) en indien nodig te koppelen aan interne achterliggende databases.

OpenCPU Tutorial

Bij wijze van proof-of-concept hebben we getest hoe men OpenCPU kan gebruiken om een bar-chart analyse te genereren in een web-applicatie. De stappen die we hierbij ondernomen hebben staan hieronder opgesomd.

Stap 1: Verzamel en upload de nodige data

In deze proof-of-concept analyseren we het klantenbestand van bedrijf X. Elke klant heeft een bepaalde Importance code van 1 tot 9 (1=een klant met weinig opbrengst, 9 een klant met heel veel opbrengst). Per klant houdt men ook bij of  hij makkelijk beschikbaar is voor een telefonische enquete (Y=yes,N=no). Onderstaande tabel geeft deze twee dimensies weer, gekoppeld aan het aantal klanten (Frequency) die in deze categoriëen kunnen ondergebracht worden.

Bovenstaande data kan men uploaden als CSV-file (of ander formaat) op de OpenCPU server via volgende link. Eens de data geupload is krijgt men een unieke ID terug waar de data te vinden is.

Stap 2: Creëer en save het R-script

In een volgende stap willen we een barchart genereren die per Importance-code weergeeft hoeveel klanten er zijn, en elke bar inkleurt in twee vlakken: een vlak makkelijk beschikbare klanten en een vlak met moeilijk beschikbare. Deze grafiek genereren we met de ggplot2 library. Onderstaande code omvat het complete R-script:

#Include ggplot 2 library
library("ggplot2"); 
#Haal de geuploade data op (zie stap1, de DATAID is dezelfde als uit deze stap) 
myTable <- read.csv("http://public.opencpu.org/R/tmp/DATAID/csv?");
#Plot en print te barchart
pl <- ggplot(myTable, aes(x = Importance, y = Frequency,fill=Available) ) + geom_bar(stat="identity");
print(pl);

Dit script zetten we op de OpenCPU-server via volgende link, we kiezen voor de optie ‘save to store’. Deze code krijgt ook een unieke ID, dewelke we later kunnen gebruiken om de code uit te voeren via een REST-service.

Stap 3: Maak de web-applicate met de REST service

De bar-chart die we gemaakt hebben in het R-script willen we nu tonen in een web-applicatie. Dit doen we via een eenvoudige Javascript applicatie die de OpenCPU-REST webservice aanroept. OpenCPU biedt verscheidene webservices aan om een plot te laden: als pdf, png, svg, R-file, … Wij hebben hier gekozen om de plot in te laten als SVG. Onderstaand is de source-code  en een screenshot van de webapplicatie weergegeven (de status na het klikken op de “calculate graph” button).

<html>
 <head>
 <script src="//ajax.googleapis.com/ajax/libs/jquery/1.8.0/jquery.min.js"  type="text/javascript">
 </script>
 
 <script type="text/javascript"> 
     $(document).ready(function() { 
          $("button").click( 
                 function(){ 
                      $("#svg").load("http://public.opencpu.org/R/tmp/SCRIPTOPENCPUID/svg", function() {});
                 } 
          );
     }); 
 </script>
 
 </head>
 <body>
   
   <button>Calculate graph</button> 
   <div id="svg"> </div>
   
 </body>
 </html>

Besluit

Specifieke softwarepakketten en programmeertalen zijn handig om in enkele lijnen code complexe berekeningen uit te voeren. Het is echter moeilijk om deze scripts te koppelen met bestaande code en te delen met verschillende mensen. Als oplossing voor dit probleem kunnen we OpenCPU gebruiken, een opensource server waar R-code op gepusht kan worden en vervolgens kan aangeroepen worden als REST-service. In een tutorial toonden we aan hoe deze aanpak werkt.  Er zijn ook nog 2 blogposts die deze aanpak beschrijven: embedding a plot in your website en running a block of R-code in OpenCPU.

Ainsi ce weekend j’ai été surpris de découvrir un outil de mindmapping (gratuit) en SAAS : Mind42.com.

J’ai d’abord été amusé par la simplicité de l’outil, en comparaison avec des outils standalone tels que FreePlane, Xmind ou le haut de gamme Mind Manager, avant de me persuader que dans le cadre d’un projet faisant intervenir différents partenaires, simplicité et mode SAAS pouvaient justement constituer un bel avantage en termes d’efficacité dans la collaboration.

Voici,  à titre d’exemple, un relevé,  de quelques applications bureautiques en mode SAAS.
http://perso.univ-lille3.fr/~rlecerf/?Mes-travaux:Formation:Outils-Web-2.0—Bureautique

Cet inventaire est aussi à mettre en rapport avec le sucès des technologies du Web 2.0, en particulier le recours de plus en plus prononcé au Javascipt et à Ajax (voir le RIA en général). Les futures applications de type client riche seront-elles toutes demain basées sur cette approche? Avec en filigrane le souci de gommer les frontières entre les différents devices : pc , netbooks, tabletpc, smartphone, … (sachant bien évidemment que taille d’écran et puissance du processeur conditionnent les fonctionnalités accessibles).

Le nomadisme en IT est de plus en plus une réalité. Devices mobiles, technologies du Web 2.0 et mode SAAS en seront vraisemblablement les piliers technologiques.

La conjonction du nomadisme et du besoin accru pour le travail collaboratif (un important gisement de productivité encore mal ou sous-exploité) vont doper le phénomène SAAS.

Pour terminer, un dernier mot sur le mind mapping : l’utilisation de cet outil de conception dans le groupe de travail qui construit les premiers modules de elearning pour les soins de santé est révélateur de l’aptitude de ces outils à fédérer et organiser rapidement les idées d’un groupe.

Intalio heeft zijn pijlen gericht op de nieuwste hype: Cloud Computing.  Met Intalio | Cloud promoot ze het concept van “Cloud in a box”, dit is een Cloud Appliance die zowel Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS) en IaaS (Infrastructure-as-a-Service) bevat. In dit artikel proberen we na te gaan hoeveel Intalio van haar beloftes kan waarmaken.

Zo zijn er een paar tekenen aan de wand die indiceren dat de oplossing van Intalio vooral “lucht” is: diepgaande documentatie ontbreekt, er kunnen geen geloofwaardige referenties voorgelegd worden en bovendien staat Intalio bekend om een zeer sterke marketing machine te hebben (de presentaties van CEO Ismael Ghalimi laten bij iedereen een sterke indruk na).

The marketing company

Intalio is er vroeg bij om in te pikken op de nieuwste trends: zo veranderde de slogan van bedrijf de laatste twee jaar van “the open source business platform company” naar “the leader in open source BPMS” tot nu, “the Enterprise Cloud Company”.  Deze veranderingen lijken aan te geven dat Intalio nog op zoek is naar haar core business.

Bovendien is het verdacht dat er geen enkel groot bedrijf haar naam wil geven als referentie voor Intalio — de verklaringen blijven erg vaag: “Intalio is integral to the operation of the Bank’s back office processes,” said a Vice President (VP) at one of the World’s largest banks.”  De vraag is uiteraard: welke bank? Als de klant tevreden is, zou de VP toch graag zijn naam bekend maken?

Ook wat betreft inhoud, houden ze zich op de vlakte: eerder dan hun sterke punten  in de spotlight te zetten, vervallen ze in lege vergelijkingen met de marktleiders: “een betere user interface dan Microsoft Dynamics CRM”,  “at feature partity with salesforce.com”,…

The enterprise cloud company

En dan nu: Intalio, the enterprise cloud company.  Wat houdt dit pretentieus statement juist in? In het kader van de studie “Cloud Computing” van de dienst Onderzoek, werd de Cloud Appliance van Intalio (“cloud in a box”) onder de loupe genomen.

Specificaties

In’t kort bestaat de Cloud Appliance uit een arsenaal van HP server hardware, samengezet in een rack: 32 3Ghz Quad Core Intel CPUs, 560 TB Hard disk space, 24 TB Solid State Diskspace en 2.3 TB of RAM (zie ook onderstaande figuur).

Hardware alleen maakt natuurlijk nog geen cloud, en daaromtrent levert Intalio volgende informatie omtrent de architectuur:

Dit schema somt ongeveer alle technische termen gerelateerd aan Cloud Computing, gedistribueerde architecturen en business applications op, en geeft bijgevolg de indruk dat het een veelbelovende en geheelomvattende oplossing is.  De realiteit blijkt iets minder rooskleurig.

Eerste demonstratie: BPM, geen cloud

Om de proef op de som te nemen werd persoonlijk contact werd opgenomen met Intalio, met de vraag om expliciet de cloud aspecten van hun oplossing te demonstreren — zowel IaaS, PaaS als Saas.  Hoewel duidelijk geformuleerd, werd tijdens een eerste demonstratie hun BPM en CRM software  alsook het MashUp center gedemonstreerd (die lokaal draaide op een laptop).   Niets nieuws onder de zon hier; het moet wel gezegd: het ziet er allemaal heel mooi uit! 

Tweede demonstratie: immatuur, geen cloud

Een tweede demonstratie werd gevraagd zodat ook de cloud aspecten konden geanalyseerd worden, opgesomd op hun eigen site:

• virtualisatie
• automatisatie
• self-service provisioning
• elasticiteit
• …

Deze presentatie verliep iets minder “flashy” dan de vorige.  Concreet komt heel hun enterprise cloud systeem op het volgende neer.

De SaaS software voor BPM, CRM, Mash Ups  (afkomstig van overgekochte bedrijfven), draait op Apache server, op verschillende “nodes” (virtuele of fysieke machines).  Een Apache Load Balancer verdeelt de aanvragen over deze verschillende nodes, die gebruik maken van een distributed file system. De gemeenschappelijke data is opgeslagen op een database die niet geclustered is, maar wel failsafe ontdubbeld.

Behalve het feit dat er technisch nog vele verbeteringen mogelijk zijn (hoe schaalbaar is deze databank? wat als we niet met webverkeer werken? etc…), bleek de huidige technologie ook nog immatuur: zo was er geen interface aanwezig (alles gebeurde via een gekunstelde command line interface) en zijn er geen load testen voor grote aantal gebruikers etc… gebeurd.

Het deed me allemaal veel denken aan the amateur cloud.

Conclusies

Op het huidige moment stijgt Intalio niet uit boven het niveau van jonge speler en immature SoSaaS provider  (Same old Software, as a Service).  Het gebrek aan documentatie en aan referenties, de sterke focus op marketing en het falen om hun oplossing te demonstreren, kan niet anders dan de indruk wekken dat Intalio slechts lucht verkoopt.

Bovenstaande vaststellingen nemen niet weg dat Intalio de nodige competentie bezit om in de toekomst haar beloftes waar  te maken.  Het is echter maar zeer de vraag of  een marketing-gericht bedrijf zonder grote referenties en onvoldoende documentatie een gewenste business partner is…

]]>