[Clous PaaS SaaS] après Force.com et Azure c’est Google App Engine qui s’attaque au problème de solution multi-tenant

Nous observons actuellement une concurrence acharnée entre les offres de PaaS (plateforme as a Servce), de Salesfoce.com, Azure, Google App Engine, jusqu’à la nouvelle offre en préparation de Vmware/Spring.

Mais, la maturité de ce marché passe par la capacité d’offrir en native la prise en charge de de l’aspect multi locataire qui sera à même d’attirer les éditeurs de solution SaaS (Software as a Service) vers ce type de plateforme.

Une application SaaS est dite multitenant, si plusieurs organisations clientes (locataires) peuvent exécuter la même application déployée sur la même infrastructure.

La capacité de proposer une solution basée sur une architecture multi locataire (multi-tenant) est un des éléments fondamentaux de la viabilité économique d’une offre SaaS.

Rappelons que le PaaS Force.com (Salesforce ) est l’un des pionniers de ce domaine et que Microsoft a déjà annoncé que son offre PaaS Azure supporte l’aspect « multitenacy ».

C’est au tour de Google d’annoncer le support de l’aspect « multitenacy », comme l’amélioration majeure apporté par la version 1.3.6 de Google App Engine. La fonctionnalité est disponible pour toutes les API de Google App Engine : Datastore, Memcache, et Task Queues..

Google appengine réalise la ségrégation des applications basée sur un espace de nommage (namespace à la XML) unique affecté à chaque client (organisation). Ainsi, on pourra servir avec la même instance d’application les utilisateurs de plusieurs clients. Chaque client ne voit que sa propre copie personnalisée de l’application.

La bonne nouvelle, pour les développeurs, est que cette amélioration est activé par une simple configuration, aucun changement dans les codes sources n’est nécessaire..

Google app engine, cherche ainsi à séduire les éditeurs désireux de migrer, en mode SaaS, leurs logiciels ou d’en créer de nouveaux.

http://googleappengine.blogspot.com/2010/08/multi-tenancy-support-high-performance_17.html

[cloud PaaS] Microsoft Azure : quels usages pour les Web Role et Worker Role

L’arrivée du PaaS (Plateforme as a Service) Azure de Microsoft, dans le paysage du développement .Net ne peut passer sans l’apparition d’un nouveau jargon technique.

Cet article met l’accent sur l’un de ses nouveaux termes techniques : la notion de Role.

Pourquoi c’est important de comprendre la signification réelle de la notion de « Role »,

Tout simplement pour savoir utiliser le bon Role pour le bon usage

Le développeur Windows Azure doit choisir un ou plusieurs types de rôles à implémenter lors de la mise en ouvre de sa solution (sous forme de service), en phase d’architecture. Une fois déployée au sein de Microsoft Azure, l’application pourra exécuter plusieurs instances de rôles différents.

Le plus simple est de distinguer les rôles en deux catégories

• Web role: pour traiter des requêtes HTTP/HTTPS. Un Web Role est un rôle adapté pour le développement d’application web supporté par IIS 7 et ASP.NET (3.5 pour le moment). Exemples de Web  rôles disponibles : ASP.NET Web Role, ASP.NET MVC2 Web Role,  CGI Web Role et WCF Service Web Role : 

• Worker role: pour traiter des tâches en arrière plan : il s’agit de processus de tache de fond (aucune requête HTTP entrante, ni exposition à un protocole). Il s’agit d’application de type s’exécutant comme une sans nécessiter d’être exposée sur un quelconque protocole. : un worker role peut servir de tâche de fond à une application web basé sur un Web Role.

Typiquement, pour un site ou une application web en ASP.NET il suffit de créer un Web Role. En créer plusieurs permet d’augmenter la disponibilité de l’application et de prétendre aux bénéfices d’un niveau de service d’au moins 99.95%.

Le niveau de service assuré par Azure exige au moins deux roles pour bénéficier du Windows Azure Service Level Agreement “Windows Azure has separate SLA’s for compute and storage. For compute, we guarantee that when you deploy two or more role instances in different fault and upgrade domains, your internet facing roles will have external connectivity at least 99.95% of the time.”

Le Worker role est utilisé typiquement pour des activités de traitement de fond :

• Création de fichier pdf,

• Traitement d’images

• Préparation des fiches de paye, en fin du mois

• Datamining

• calcul statistique

• etc.

Faire fonctionner 10 Worker Role durant une heure offre la même capacité de calcul que celle réalisée par 1 seul Worker role durant 10 heures, et ça coûte le même prix.

Un web role peut définir un point de contact (Endpoint) HTTP unique et un autre point unique HTTPS pour les clients externes.

La configuration d’un worker role est plus flexible : il peut définir jusqu'à cinq points de contact (Endpoint) externe en utilisant HTTP, HTTPS ou TCP. La principale contrainte est que chaque point de contact externe défini pour un rôle doit rester à l’écoute sur un port unique.

De plus, tous les rôles peuvent accéder aux services Windows Azure de stockage (Windows Azure storage services ) via les API de Windows Azure Managed Library ou le protocole REST via Windows Azure Storage Services REST API..

Avant de lancer votre application sur Azure (en mode SaaS ou non), pensez à prendre le temps de bien choisir les rôles adéquats : faire de l’architecture applicatif, devient plus important dans le cloud que dans le cas « on premise ».

Mais ceci est un autre sujet …

Le PDG de Google se fait le chevalier de la protection de la vie privée.

Eric Schmidt, s’inquiète quant à l’impact futur de la compilation, par facebook et les autres réseaux sociaux, d'informations sur les individus, qui « se dénudent numériquement » en toute confiance.

Ce défenseur de la vie privée, prophétise que certains seraient obligés de changer de nom pour fuir leur passé numérique.

Mais, peut-il nous détailler, ce que Google « compile » et stocke sur nous tous ? :

· Google search: le détail de nos recherches

· Gmail: nos emails et nos contacts

· Googlegroups : nos questions les plus stupides et nos réactions les plus spontanées

· Chrome : nos centres d’intérêts

· Google Calendar: nos habitudes

· Google Docs: nos travaux et nos idées

· Google Maps: nos adresses et nos trajets

· Picasa: nos photos, et par extrapolation nos visages

· Youtube : nos vidéos

· Google voice : nos voix …

· Google News: les informations qui nous intéressent

· Google alerts: les sujets qu’on suit au fil de l’eau

· Google Books: nos centres d’intérêts culturels

· Google talk : nos amis, et nos messages instantanés,

· Google analytics : ceux qui s’intéressent à nos idées et visitent nos sites web / blogs,

· Google adwords : ce que nous cherchons à vendre,

· Etc..

Et enfin, s’il reste d’autres informations non compilées, elles le seront avec Android (OS et Mobile) …

Ainsi, Googleet n’a pas besoin qu’on partage nos informations personnelles, il les "possède" déjà. !!

Il sait déjà tout, d’ailleurs c’est pour cette raison qu’on visite google.com….

[Java et Java EE ] Newslettre à lire, LeJournalduNet

La nouvelle version de la Newslettre du JDN (LeJournalduNet) est intéressante pour deux raisons :

• La première raison , est qu’elle est “Spécial Java, Tutoriel Apache Tomcat native, Analyse Spring, Eclipse 3.6, Quel avenir pour Java, Netbeans 6.9...

• la seconde est qu’elle comprends une de mes tribunes  dans le JDN :

lien : http://benchmail.journaldunet.com/magazine/numero_10176814.html

ou bien

visualisez sur ISSUU.com