Présentation des applications cloud natives
Conseil
Ce contenu est un extrait du livre électronique, Cloud Native .NET apps for Azure (Architecture d’applications .NET natives cloud pour Azure), disponible dans la documentation .NET ou au format PDF à télécharger gratuitement pour le lire hors connexion.
Un jour, au bureau, à travailler sur « la prochaine grande nouveauté ».
Votre téléphone portable sonne. C’est votre gentil recruteur, celui qui appelle tous les jours avec de nouvelles opportunités passionnantes.
Mais cette fois, c’est différent : start-up, équité et plein de financements.
À la mention du cloud, des microservices et de la technologie de pointe, vous décrochez.
Passons quelques semaines dans le futur, et vous êtes maintenant un nouvel employé dans une session de conception de l’architecture d’une application eCommerce majeure. Vous allez concurrencer des sites de commerce électronique de premier plan.
Comment allez-vous la construire ?
Si vous suivez les instructions des 15 dernières années, vous allez probablement créer le système indiqué dans la figure 1.1.
Figure 1-1. Conception monolithique traditionnelle
Vous construisez une application de base volumineuse contenant toute votre logique de domaine. Il inclut des modules tels que Identité, Catalogue, Commande, etc. Ils communiquent directement entre eux dans un processus à un seul serveur. Les modules partagent une base de données relationnelle volumineuse. Le noyau expose les fonctionnalités via une interface HTML et une application mobile.
Félicitations ! Vous venez de créer une application monolithique.
Tout n’est pas mauvais. Les monolithes offrent des avantages distincts. Par exemple, ils sont simples à...
- build
- test
- déployer
- dépanner
- mette à l’échelle verticalement
De nombreuses applications réussies qui existent aujourd’hui ont été créées comme monolithes. L’application est un succès et continue à évoluer, itération après itération, ajoutant plus de fonctionnalités.
À un moment donné, cependant, vous commencez à vous sentir mal à l’aise. Vous perdez le contrôle de l’application. À mesure que le temps passe, ce sentiment s’intensifie et vous entrez finalement dans cet état connu sous le nom de Fear Cycle :
- L’application est devenue tellement compliquée qu’aucune personne ne le comprend.
- Vous craignez d’apporter des modifications : chaque changement a des effets secondaires inattendus et coûteux.
- Les nouvelles fonctionnalités et les correctifs deviennent difficiles, fastidieux et coûteux à implémenter.
- Chaque version devient aussi petite que possible et nécessite un déploiement complet de l’ensemble de l’application.
- Un composant instable peut bloquer l’ensemble du système.
- Les nouvelles technologies et infrastructures ne sont pas une option.
- Il est difficile d’implémenter des méthodologies de livraison agiles.
- L’érosion architecturale s’installe à mesure que la base de code se détériore avec des « correctifs rapides » sans fin.
- Enfin, les consultants interviennent et vous disent de le réécrire.
Cela vous semble familier ?
De nombreuses organisations ont abordé ce cycle de peur monolithique en adoptant une approche native cloud pour créer des systèmes. La figure 1-2 montre le même système conçu appliquant des techniques et pratiques natives cloud.
Figure 1-2. Conception native cloud
Notez comment l’application est décomposée sur un ensemble de petits microservices isolés. Chaque service est autonome et encapsule son propre code, ses données et ses dépendances. Chacun est déployé dans un conteneur logiciel et managé par un orchestrateur de conteneur. Au lieu d’une base de données relationnelle volumineuse, chaque service possède son propre magasin de données, dont le type varie en fonction des besoins des données. Notez comment certains services dépendent d’une base de données relationnelle, mais d’autres de bases de données NoSQL. Un service stocke son état dans un cache distribué. Notez comment tous les routages de trafic via un service de passerelle d’API chargé de router le trafic vers les services back-end principaux et d’appliquer de nombreuses préoccupations transversales. Plus important encore, l’application tire pleinement parti des fonctionnalités de scalabilité, de disponibilité et de résilience trouvées dans les plateformes cloud modernes.
Informatique native Cloud
Hmm... Nous venons d’utiliser le terme native Cloud. Votre première pensée pourrait être, « Qu’est-ce que cela signifie exactement ? » Un autre mot à la mode du secteur, inventé par les fournisseurs de logiciels pour commercialiser plus de choses ? »
Heureusement, c’est bien différent, et j’espère que ce livre vous aidera à vous convaincre.
En très peu de temps, le natif Cloud est devenu une tendance moteur dans le secteur des logiciels. C’est une nouvelle façon de construire de grands systèmes complexes. L’approche tire pleinement parti des pratiques de développement de logiciels modernes, des technologies et de l’infrastructure cloud. Le natif Cloud modifie la façon dont vous concevez, implémentez, déployez et mettez en œuvre des systèmes.
Contrairement à la frénésie continue qui anime notre secteur d’activité, le natif Cloud est bien réel. Considérez le Cloud Native Computing Foundation (CNCF), un consortium rassemblant plus de 400 grandes entreprises. Sa charte consiste à rendre l’informatique native Cloud omniprésente dans les technologies et les piles cloud. En tant que l’un des groupes open source les plus influents, il héberge dans GitHub de nombreux projets open source à la croissance la plus rapide. Ces projets incluent Kubernetes, Prometheus, Helm, Envoy et gRPC.
Le CNCF favorise un écosystème de neutralité open source et fournisseur. Suite à cela, ce livre présente des principes, des modèles et des meilleures pratiques natifs Cloud, indépendants de la technologie. En même temps, nous abordons les services et l’infrastructure disponibles dans le cloud Microsoft Azure pour construire des systèmes natifs Cloud.
Alors, qu’est-ce que le natif Cloud précisément ? Asseyez-vous, détendez-vous et laissez-nous vous aider à explorer ce nouveau monde.
