Préambule
J'ai assisté hier soir à la 5ème édition des Altaïde Dev’ Drink consacrée à l'évolution du modèle de développement Web. Ce type de rencontre a plusieurs objetifs :
- pour Altaïde (cabinet de recrutement, leur blog), d'étendre son réseau sur de potentiels candidats,
- pour les participants, d'assister à des présentations sur de nouvelles technos. ou de nouveaux moyens liés au Web / Web2,
- prendre un pot à l'issue de la présentation, et boire des bières, du coca ou manger des carottes bio.
chacun y trouve son compte, dans du gagnant-gagnant, le concept me plaît, c'est fun et moderne. Nous étions une petite quinzaine.
Voluntis (qui présentait le sujet) est une start-up qui a développé sa solution SaaS, medpassport, un PRM, cela rejoint l'idée de CRM), à base de technologie .NET.
Introduction
Les grands acteurs d'aujourd'hui sont parmi les plus connus, on pensera à Amazon AWS avec S3 (stockage de données en ligne) et EC2 (Cloud computing), Google app engine, Salesforce, ...alors quels acronymes trouve-t-on aujourd'hui, pour quelle solution apportée ?
- SaaS, né en 2000, a remplacé le mode ASP.
- Saas add-on, facebook en est le digne représentant : donner la possibilité de développer des applications qui seront adjointes à la plateforme Facebook, et accessibles par tout utilisateur facebook, 26 000 applications ont été déjà développées,
- DaaS, né mi-2007, cela permet d'offrir tout l'environnement, outils (IDE, bases, interfaces utilisateur) et APIs aux développeurs afin de développer et concevoir une application avec un déploiement directement sur la plateforme (ou pré-prod, test, ...). force.com (SalesForce, très grand éditeur CRM) présente une plateforme de ce type
- PaaS, arrivé fin 2007 - début 2008, propose toute l' infrastructure pour développer, héberger et maintenir une application Web (ie : permet donc de gérer tout le cycle logiciel), en unifiant également l'expérience utilisateur (ie : les composants développés pourront être réutilisés par des tiers), http://www.bungeelabs.com propose ce type de solution : IDE en ligne, infrastructure dédiée.
- enfin le Could computing permet de proposer des ressources serveurs (virtualisés) à la demande par le biais du Web, selon les besoins, et facturées selon les unités allouées.
La solution la plus avancée apportera toute l'infrastructure en termes de serveurs : sécurité, serveurs web, bases de données, liens Internet (débit). Ces XaaS apportent des briques de type authentification, gestion de sessions, et bien sûr des APIs que pourra utiliser le développeur.
Les APIs explosent par leur nombre, chacun tente de fournir la sienne (et c'est une bonne chose), le site ProgrammableWeb répertorie l'ensemble des APIs pros., maintenant au nombre de 800 !
Acteurs
Quelques présentations des grands acteurs, et de leurs solutions.
AWS (Amazon Web Services)
Né en 2002 par l'exposition d'une API, en 2006, Amazon sort S3 puis EC2. Le prix réel (qui s'avère parfois très difficile à calculer) revient en moyenne à 10 cents / heure d'une instance serveur. AWS étend également sa solution avec des modules spécialisés dans l'achat en ligne, avec ECS (e-Commerce), FPS (micro-paiement), DevPlay (facturation).
SalesForce
SalesForce est un CRM en ligne, avec 40 000 clients et 1 million d'utilisateurs de leur plateforme SaaS. Le Langage utilisé est APEX, propriétaire et diffusé par Salesforce. Un répertoire de composants, d' applications APEX, est disponible à la vente sur AppExchange (environ 800 applications sont disponibles).
SalesForce édite également un IDE (basé sur Eclipse) afin de développer sur leur plateforme à partir de leur langage APEX. L'atoût est dans le déploiement immédiat de l'application : elle n'est pas développée en local sur le poste, mais bien directement sur la plateforme DaaS.
Le projet Code Google et notamment http://code.google.com/more/#products-featured-android offre plus de 37 APIs aux développeurs afin de développer et d'utiliser ces services en ligne afin de les intégrer dans leurs applications : Google Chart, Google Calendar, Google Maps, ...
Récemment lancé, Google App Engine vous permettra de vous affranchir d'une infrastructure (sécurité, serveurs, performances serveurs, ...), offerte par Google, afin de vous concentrer sur l'applicatif et de développer directement sur la plateforme App Engine. Jusqu'à présent, un seul langage est proposé : le développeur, au travers de Python et du framework MVC Django, pourra développer ses applications hébergées sur Google. Nous espérons que Google fournira d'autres langages que Python, afin de satisfaire le plus grand nombre d'ingénieurs.
Le choix de Python a été pris car Google a recruté le créateur du langage. Je ne me suis jamais mis à Python tout simplement à cause de la syntaxe que je trouve peu lisible (un peu comme du Perl ;)), oui je sais, c'est un peu limite de s'arrêter à ce critère, mais cela reste important pour moi. Il n'en reste pas moins que Python reste très bien, et est utilisé sur certaines plateformes (Zope, Django).
Dans la stratégie Google, il s'avère très certainement, que l'objectif n'est pas de concurrencer des plateformes de type Amazon ou Salesforce, mais bien d'augmenter au maximum le nombre de comptes Google (il faut un compte pour App Engine, ou tout autre service), afin d'afficher de la publicité à la plus large audience possible. Le modèle économique de Google étant basé sur la vente de la publicité.
mi-2007, facebook lance sa plateforme de développement, qui permet à tout à chacun d'adjoindre son application (sorte de plug-in) à Facebook, afin qu'elle soit utilisée par le plus grand nombre d'utilisateurs Facebook. Le langage utilisé est FBML, 26 000 applications sont déjà disponibles (la majeure partie ne sont pas professionnelle).
Comme Google, l'accès à Facebook nécessite un compte. On peut supposer de la part de Facebook un objectif de création de comptes maximum.
Récemment, Facebook a été décrié pour son manque de sécurité du point de vue de la fuite des amis
des carnets d'adresses des facebookers. En effet, le système est facilement hackable afin de pouvoir obtenir la liste de tous les amis d'une personne (qui d'habitude peut être rendue inaccessible au public), afin, par exemple de vendre spammer des produits à ces derniers.
Solution Voluntis
Leur solution / API est basée sur SOAP, le challenge client/serveur s'effectuant grâce aux entêtes SOAP dans lesquels sont inscrits différents champs de vérification afin de contrôler la sécurité des échanges.
On trouvera 4 champs :
- AppId : l'identifiant de l'application développée sur la plateforme
- SessionId : le n° de session utilisateur
- Signature : HASH des paramètres passés dans l'URL afin de vérifier une usurpation éventuelle de ces derniers
- Nonce : technique de lutte contre les replay attacks, qui correspond à une piraterie des données par un tiers en substituant l'IP d'origine.
Enfin, plusieurs solutions sont proposées afin d'inclure une application sur une plateforme de façon transparente pour l'utilisateur (ie : comme on pourrait le faire pour un site en marque blanche) :
- via une iframe + paramètres en GET
- via un moteur de rendu en tâche de fond
- via un langage propre à la plateforme qui fournir le code final d'affichage (langage interprété à la volée).
Remarque concernant la solution Voluntis : je suis étonné qu'ils aient pris le parti SOAP, alors que la tendance actuelle (du point de vue des développeurs) est une utilisation massive de REST (pour par exemple du XML over HTTP, technique utilisée par Facebook, Google ou Amazon), considéré plus simple à mettre en oeuvre. SOAP c'est bien, mais avec le recul, c'est plus approprié pour des langages de haut niveau tel que .NET ou JAVA (donc entre plateformes de même technologie) qui ont des outils pour générer les proxy (au sens classes qui représentent la description WSDL, et donc des objets manipulés) et la manipulation s'en trouve facilitée. Dès lors que l'on s'oriente vers des solutions de type PHP, RoR, Python, Perl, ...il s'avère beaucoup plus hasardeux d'échanger en SOAP, et dès lors, on réduit le potentiel d'utilisateur de nos APIs.
La dernière version (3.5) de .NET et ses modules afférents permettent de s'ouvrir à REST, notamment grâce à WCF ou encore ADO.NET Data Services.
Quelques ressources sur le thème REST.
Conclusion
Rencontre intéressante sur un sujet brûlant qui permet d'avoir pas mal d'idées sur la façon de mettre en oeuvre ce type de solution, ou du moins comprendre la tendance actuelle.
Egalement, un billet très intéressant sur cette problématique.
Jeu de briques
Snake
Pacman
Bubble