Microservices c’est quoi?
Des applications monolithiques aux solutions agiles!
Depuis 2010… Le monde “agile” et “scrum” vont remanier la façon de concevoir les applications, et fournir les bases vers la nouvelle informatique Datatech…
Il ne suffit plus de rendre efficace les équipes devenue “agile”, mais il est nécessaire de rendre résilientes et “scalables” les infrastructures pour soutenir cette agilité. Et les containers vont y aider.
Au lieu de créer un serveur pour chaque service, avec sa propre base de données, souvent en partie synchronisée avec plusieurs autres bases de données, et parfois des problèmes de cohérences. Nous allons créer un “pool” de serveurs pour gérer les données A, une grappe d’autres serveurs dédiés aux données B, puis un couple de serveur pour servir les données C.
Avec le gros avantage de permettre d’optimiser l’usage des ressources nécessaires pour fournir les services applicatifs, que ce soit:
- En réutilisant le même groupe de serveurs C pour multiples applications
- En augmentant et réduisant dynamiquement le nombre de serveurs selon les quantités de requêtes effectives.
Mais aussi de gagner en agilité, car les applications suivantes, et l’adaptation des applications existantes, se font sans avoir à impacter les serveurs et les applications existantes. Ce qui permet un fonctionnement 24/7…
Grâce aux progrès de la virtualisation, au niveau applicatif: Il est désormais possible de déployer des services (via Kubernetes ou Openshift) avec bien plus de rapidité que les scripts “puppet” précédents. Un container applicatif docker est déployé, configuré, “up & running” sur un serveur en quelques secondes.
Alors est venue l’ère des nouvelles architectures logicielles (encore), avec les DEVOPS et les Microservices.
C’est la conception même des applications qui évolue vers le modèle ‘SaaS’ afin de s’assurer d’une disponibilité optimale et efficiente des ressources nécessaires à son fonctionnement. Les architectures ‘SOA’ évoluent vers des plateformes avec des bus de communications qui sont plus rapides qu’avec des API de requêtes XML, vers des architectures applicatives distribuées (‘SOAP’ plus anciens, ‘REST’ plus actuels). L’application doit pouvoir intégrer les dysfonctionnements (‘Design for failure’). Les données sont fournies par des système SQL, ou ‘no SQL’, à travers des portails ‘middleware’ qui contrôlent les accès et ne fournissent que l’extraction nécessaire des données.
Dans un modèle ‘SaaS’ le prix du service est défini en mesurant l’activité moyenne d’un utilisateur. Il est directement calculé à partir des ressources consommées, voir selon la facturation du sous-traitant des services ‘Cloud’ utilisé éventuel (PaaS ou IaaS). L’optimisation des codes, la ré exploitation maximale des ressources locales au client (APP sur mobiles, HTML 5 ou Java sur client web) sera la règle pour optimiser et réduire les coûts du côté des services serveurs.
Déjà en 2016: Réf. Etude Deloite : 8 tendances IT (2015) : N°2 : « L’économie des API ». Les portails Cloud, ‘front-end’, deviennent des composants essentiels pour des applications Opendata, ou commerciales (ex. OpenCorporates.com), qui s’adressent aux développeurs. Les API deviennent les sources de revenus d’un grand nombre de nouveaux acteurs et intermédiaires dans la gestion de données (‘data broker’).
Les données elles-mêmes perdent de la valeur, les flux de données en gagnent. Les flux de données vont s’activer et se cascader sur déclenchement automatique (‘trigger’), comme avec IFTTT ou ZAPIER, qui vont exploiter les ‘API’ de centaines de services web, pour créer un flux d’actions: Un mashup.
D’un Internet HTML passif et non structuré en lecture seule, nous passons à un Internet interactif et structuré en flux XML ‘REST’ (‘Semantic Web, RDFa, Microformat’). C’est finalement le début d’une des promesse du web sémantique annoncé, le Web 3.0.
Voir aussi l’excellent article (en anglais) de Martin Fowler et James Lewis sur les micro services :
L’impact de cette émergence et l’explosion des volumes de données (et de leurs data bases, SQL et ‘no SQL’) sur les INFRAs, est la nécessité croissante d’exposer des portails d’API sur le web, accessibles partout ; à chaque instant ; avec de bonnes protections, et de la facturation intégrée par volume… Sera-t-il possible de le faire sans s’appuyer sur des fournisseurs ‘IaaS/PaaS’ distribués et sécurisés ?
Des applications “cloud natives”
Ainsi, il est possible de concevoir des cloud hybrides, pas uniquement afin de choisir de façon binaire si une application sera dans la cloud public, ou le Cloud privé ; mais prévoir des serveurs ‘Web’ dans le ‘public Cloud’ et des bases de données dans le ‘Private’, avec des machines intermédiaires, dans les deux.
Mais cette “révolution” en marche depuis 2010, est en train de céder la place à une autre en 2020: Les applications SERVERLESS…
Informatique sans serveur
Les premiers étaient Amazon avec Lambda, dès 2014
Suivi par Google engine, et Microsoft, bien entendu, avec Fabric:
Tu peux désormais créer ton application “Cloud” sans avoir besoin d’installer le moindre serveur, ni activer le moindre service. Juste un abonnement à un des GAM (Une partie des GAFAM).
Ta machine de DEV et de test ne te coutera “rien” ou presque… C’est quand ton APP va avoir du succès et monter en charge que cela va commencer à “coûter” (et si c’est une App gratuite, comme whatsapp, te faudra des crédits)
Par contre, ton application ne sera plus transportable, nulle part… Rendre captif le client, n’est-ce pas le Graal?
Mais attention, toujours aucune magie, le “cloud n’existe pas”
