Services distribués : signeront-ils la fin des architectures client/serveur ?

Des outils qui séduisent aujourd’hui jusqu’aux grandes entreprises, et qui sont en train de s’imposer progressivement comme les outils standard du Cloud Computing. Ils s’appellent Puppet, Chef, Hekoru, Jenkins, Salt, Docker, ou encore Zabbix. Des noms totalement inconnus voici encore quelques mois et qui fleurissent de plus en plus fréquemment dans les conversations avec les responsables de production informatique, qu’ils travaillent chez des prestataires ou directement au sein des entreprises utilisatrices.

Ce sont en tout cas les principes du Cloud Computing qui ont inspiré les créateurs de cette génération d’outils. Dans certains cas, ces logiciels ont été initiés par les géants du Cloud pour faire face à des difficultés qu’ils rencontraient en production, parfois par les utilisateurs de ces environnements : Gestion de plates-formes de production diverses, contrôle des mises en production, gestion des développements jusqu’au passage en production, administration de milliers de machines réparties sur plusieurs datacenters, etc. : les outils visent in fine à concrétiser les promesses du Cloud : une production informatique plus flexible et plus réactive.

Après tout, qu’importe le choix de vos environnements d’aujourd’hui. Que vous soyez familier avec Visual Studio ou avec les produits Open Source, la gestion de vos ressources sur un environnement Infrastructure as a Service tend à devenir transverse entre les fournisseurs de plateformes, et il vous faut désormais penser à disposer d’une fabrique de bout en bout pour la mise en production de vos applications : du producteur (le développeur) jusqu’au consommateur du service. C’est de cette réflexion que naîtra la réversibilité et la transférabilité de vos applications dans le nuage.

Pour mieux comprendre, vous trouverez deux schémas qui pourraient représenter votre infrastructure à l’avenir : un environnement de développement, une bibliothèque de vos codes applicatifs et infrastructure (le repository), des environnements de pré-production et de test (build et test), un environnement de déploiement par blocs applicatifs (deploy), votre plateforme d’exécution (Amazon Web Services, Google Compute Engine, Microsoft Azure) représentée par le bloc Apps, les outils pour la surveillance et les tâches d’exploitation (Ops), et enfin l’environnement de batch processing (Process tools).

(((IMG7496)))

(((IMG7497)))

Microsoft a compris l’utilité de supporter également des environnements et des outils d’origines différentes, s’il ne voulait pas se laisser distancer à la course au Cloud Computing, et c’est tant mieux. Toutefois, pour ses partenaires, cela représentera un changement à 180° et une grande curiosité d’esprit pour les intégrer dans leurs offres de services après des dizaines d’années de conviction à ce que tout puisse se faire qu’avec des technologies Microsoft.