Ismael HOMMANI

Introduction L’usage du cloud dans les entreprises ne fait plus débat. Bien utilisé, il devient moteur d’avantages concurrentiels et ouvre la voie à de nouvelles perspectives de marché.

Lors d’un précédent article sur Google BigQuery nous parlions de la data comme le nerf de la guerre dans la concurrence que se mènent les fournisseurs cloud. Cette affirmation se base sur la logique suivante: Là où se trouve ma donnée, se trouveront les processus qui la crée ainsi que les calculs qui l'explorent.

Introduction Dans une application la configuration peut se définir comme tout ce qui varie d’un déploiement à un autre. Cela peut concerner des sujets applicatifs (URLs de services tiers, identifiants, ...), comme technique (IP de la machine hôte). Dans l’un de nos précédents articles nous présentions Lightbend config, une solution simple et puissante de fédération de configurations d'applications. Nous la qualifiions alors d’adaptée aux applications dites cloud-natives. Pour comprendre les fondements de cette affirmation, il est nécessaire de qualifier la relation entre un applicatif et sa configuration dans un environnement “cloud”. Quelles problématiques pose la gestion d’une configuration ? Comment y répond-on ? Ce n’est pas tant que le Cloud ait créé de nouvelles problématiques qu’il ne les a exacerbées. L’application de nouvelles approches de gestion de configuration devient alors nécessaire plutôt qu’optionnelle. Au-delà des réponses qu’apportent des solutions comme Lightbend config, ce qui nous intéresse ici c’est de comprendre comment ces questions se sont posées et comment les solutions peuvent se penser.

“Je ne peux plus passer l’aspirateur… parce que [la région AWS] us-east-1 est en panne.”

Dans l’un de nos précédents articles, nous parlions de Google BigQuery comme d’un service différenciateur pour la Google Cloud Platform. Ses performances alliées à sa facilité d’utilisation en font une solution de choix dans le marché des Data Warehouse. Le succès de BigQuery ne doit rien au hasard et nous avons vu que disruption technique, facilité d’utilisation et communication font partie d’un cocktail nécessaire au succès commercial. Nous employons le mot nécessaire car l’exemple d’un autre service démontre que ce n’est pas suffisant.

Le refactoring, une pratique nécessaire Que nous soyons développeur, ops ou architecte nous manipulons des notions en mouvement constant : le besoin client change et sa compréhension évolue. La robustesse d’un système se consolide. La maîtrise d’une technologie s’améliore. Les besoins en sécurité doivent s’adapter...