Présentation des applications natives cloud

Un autre jour, au bureau, travailler sur « la prochaine grosse chose ».

Votre téléphone portable sonne. C’est votre recruteur convivial , celui qui appelle tous les jours avec de nouvelles opportunités passionnantes.

Mais cette fois-ci, c'est différent : start-up, capital, et beaucoup de financement.

À 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 les sites de commerce électronique de premier plan.

Comment allez-vous le 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 Identity, Catalog, Ordering, etc. Ils communiquent directement entre eux au sein d’un seul processus serveur. Les modules partagent une base de données relationnelle volumineuse. Le cœur 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 à...

• construire
• essai
• déployer
• résoudre les problèmes
• mette à l’échelle verticalement

De nombreuses applications réussies qui existent aujourd’hui ont été créées en tant que 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 se passe, le sentiment devient plus intense, et vous entrez finalement dans un é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.
• De nouvelles fonctionnalités/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 viennent et vous disent de le réécrire.

Ça vous dit quelque chose ?

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 construit en appliquant des techniques et pratiques cloud-native.

Figure 1-2. Conception native pour le cloud

Notez comment l’application est décomposée sur un ensemble de microservices isolés de petite taille. 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 géré 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, tandis que d’autres dépendent de bases de données NoSQL. Un service stocke son état dans un cache distribué. Notez comment tous les flux de trafic passent par un service de passerelle d'API chargé de router le trafic vers les services principaux et de mettre en œuvre de nombreux aspects transversaux. Plus important encore, l’application tire pleinement parti des fonctionnalités d’extensibilité, de disponibilité et de résilience trouvées dans les plateformes cloud modernes.

Informatique native dans le cloud

Hmm... Nous venons d’utiliser le terme Cloud Native. Votre première pensée pourrait être : « Qu’est-ce que cela signifie exactement ? » Un autre mot clé de l’industrie inventé par les éditeurs de logiciels pour commercialiser plus de choses ?

Heureusement, c’est bien différent, et j’espère que ce livre vous aidera à vous convaincre.

Dans un court délai, le cloud natif 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 cloud natif 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 cloud Native Computing Foundation (CNCF), un consortium de plus de 400 grandes entreprises. Sa charte vise à rendre l'informatique cloud-native omniprésente à travers les technologies et les architectures cloud. En tant que l’un des groupes open source les plus influents, il héberge de nombreux projets open source en croissance la plus rapide dans GitHub. Ces projets incluent Kubernetes, Prometheus, Helm, Envoy et gRPC.

Le CNCF favorise un écosystème open source et de neutralité vis-à-vis des fournisseurs. À cette suite, ce livre présente des principes, des modèles et des meilleures pratiques 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 Cloud Native exactement ? Asseyez-vous, détendez-vous et laissez-nous vous aider à explorer ce nouveau monde.