Les entreprises souhaitant disposer rapidement de nouvelles capacités métier ont commencé à élaborer des « Cloud Native Applications » (CNA). Ces applications sont intéressantes à plusieurs titres. En effet, les coûts liés à l’hébergement sont faibles et les dépenses d’investissement peuvent être réduites grâce au modèle OPEX basé sur le cloud (paiement à l’usage).

Les CNA présentent des qualités évidentes. Créées dans un environnement cloud adaptable et omniprésent, elles sont ensuite réparties dans des services distincts qui, tirant avantage de la configuration du cloud, sont déployés sur plusieurs serveurs pour permettre la redondance. Cela les rend hautement résilientes dès leur création.

Autrement dit, les CNA résultent de l’association de plusieurs composantes standardisées sur les serveurs, avec une structure de type « Lego ». Chaque composante est exécutée au sein de son propre conteneur et est connectée aux autres par réseau.

Les services, les composantes, les capacités de calcul et le stockage peuvent être adaptés à volonté, dispensant ainsi du besoin de « surbudgétisation ». Le résultat final est une aptitude à fournir très rapidement des capacités métier à des coûts très faibles.

Maintenant, comparons-les au développement d’applications classiques. Les applications monolithiques traditionnelles supposent une longue durée de vie de l’infrastructure. Le processus dépend de ressources telles que les disques partagés et les sessions groupées, qui sont difficilement adaptables. Ces applications ont souvent des difficultés à traiter des charges importantes et leur développement est un processus pénible. Certaines équipes organisées en silos (voir schéma 1 pour connaître les équipes nécessaires pour la fourniture d’applications monolithiques) perdent du temps à essayer de se coordonner et de communiquer entre elles. Les meilleures pratiques, qui partaient des meilleures intentions, deviennent aujourd’hui des goulots d’étranglement et empêchent le recours à de nouvelles technologies et à de nouveaux processus.

Les enjeux des applications cloud natives

Les CNA sont clairement en vogue pour de bonnes raisons. Mais ce qui fait leur force (vitesse, flexibilité, agilité) augmente le risque de perte de données. En vue d’obtenir un meilleur contrôle et une diminution des risques, les équipes ont recours à une architecture cloud native, leur apportant ainsi une meilleure visibilité et un meilleur contrôle de l’environnement, ce qui contre-balance les risques.

Les principaux outils permettant de gagner en visibilité et en contrôle sont le monitoring multifonctionnel et la visualisation de données. Ils servent à alerter les développeurs en cas de déviations du comportement normal, à enquêter sur les problèmes et à rectifier les éléments responsables de l’anomalie.

Les défauts sont isolés pour éviter la propagation à d’autres composantes. Des disjoncteurs interviennent pour éviter des pannes qui seraient catastrophiques pour les systèmes en cas de dysfonctionnement d’une des composantes.

Les CNA dispensent du besoin de « surbudgétisation » en infrastructure et en ressources, mais il faut bien comprendre que c’est à la condition d’éviter de stocker des sessions, des objets et des données de cache sur les serveurs. Implicitement, les serveurs doivent être créés et supprimés rapidement en fonction de la charge afin de disposer de l’infrastructure adéquate à un moment donné.

Amplifier les avantages des CNA

Les entreprises envisageant d’utiliser des CNA peuvent bénéficier du modèle de conception d’application douze facteurs. Ce modèle définit les propriétés des CNA, qui sont ainsi à même de surmonter de nombreux problèmes. Il recommande notamment que les CNA possèdent les caractéristiques suivantes :

– Une base de code gérée par version
– Des dépendances clairement définies et isolées
– Une configuration injectée au moment de l’exécution
– Des processus de construction, de mise en production et d’exécution indépendants
– Les applications doivent être exécutées dans un processus sans état avec une adaptabilité horizontale et exposer le service via un URL/API défini
– Les serveurs applicatifs doivent être supprimés en cas de dysfonctionnement

Les journaux des applications (logs) doivent être traités comme des flux d’événements

De plus, il existe trois autres facteurs essentiels ayant un impact sur le développement / déploiement des CNA :

L’architecture cloud native : Comme mentionné brièvement plus haut, ce type d’architecture crée des applications indépendantes offrant des unités atomiques de valeurs métier. Les applications collaborent avec d’autres services via des interfaces bien définies. Aussi longtemps que l’interface reste la même, l’application peut évoluer indépendamment et être déployée plus rapidement sans affecter d’autres applications.

L’API REST est devenue la norme par défaut pour que les applications publient leurs interfaces.

Les applications sont enregistrées et découvertes de manière dynamique. Grâce aux configurations par version et distribuées, nul besoin de redémarrer l’application en cas de changements dans la configuration.

Dernièrement, les conteneurs sont devenus très prisés pour simplifier le déploiement des services. Les fournisseurs de solutions cloud œuvrent en faveur d’une planification et d’un déploiement de conteneurs (chargement, téléchargement, démarrage, arrêt), souvent avec des outils open source susceptibles de contribuer à adapter le processus pour un très grand nombre de conteneurs (tous hébergements confondus).

Support cloud pour l’architecture micro-services : Les équipes de développement ont recours à une infrastructure en libre-service (IaaS) pour développer, déployer et assurer la maintenance des applications. Les plateformes d’intégration continue et de déploiement continu (CI-CD) sont idéales pour automatiser la construction, le test et le déploiement (code) dans tout type d’environnement. Les services externes (backing services), comme la base de données, la file d’attente de messages, le service de messagerie, sont aussi créés via un système de libre-service (PaaS).

Les services de support, tels que l’évolution à la demande, la gestion du bon fonctionnement, l’analyse des logs et le routage dynamique, sont aussi fournis par le cloud. En résumé, les développeurs ont suffisamment de contrôle pour répondre rapidement aux besoins métier grâce à l’architecture micro-services.

Le processus de l’architecture cloud native : Pour mettre en place l’architecture micro-services, les équipes sont organisées par application et appliquent la méthodologie DevOps. Dans ce cas, le style monolithique traditionnel de développement n’a plus cours. Les équipes sont composées de professionnels dotés de capacités transverses et suivent la méthodologie Agile / Lean pour un développement rapide de l’application, qui fournit une unique capacité métier. L’équipe est libre de choisir les normes et protocoles qu’elle juge les meilleurs. Du fait du développement en conteneurs, cette démarche n’a aucune incidence sur les autres parties de l’application ; les équipes de support exposent l’infrastructure par le biais de services consommés pour le CI-CD et le support (voir schéma 2 pour plus de détails sur les équipes utilisant le delivery micro-services).

Les micro-services permettent de régler de nombreux problèmes liés aux CNA. Ils offrent aux développeurs l’avantage de travailler en petits groupes, ce qui est idéal pour un environnement CI-CD / Agile. Ils donnent aussi la possibilité d’utiliser des protocoles et des langages différents, rendant les équipes plus productives et les applications plus conformes aux exigences métier.

Il facilite la mise en place de changements à la faveur de l’évolution des exigences métier et par-dessous tout, du fait de l’absence de verrouillage technologique, les entreprises sont libres de créer les CNA dont elles ont besoin plutôt que celles dictées par les seules capacités technologiques disponibles.

__________
Cet article a été rédigé par Satyajit Das, consultant de la division AWS au sein de l’équipe Service Transformation et Saksham Khandelwal consultant au sein de la division Innovation et though leadership charter chez Wipro.