shutterstock_611605280

L’Agilité sur un nuage…

Avez-vous déjà entendu parler de plateformes comme Amazon Web Services (AWS), Google Cloud Platform ou Microsoft Azure? Savez-vous comment en tirer un maximum de bénéfices?

Si on ne comprend pas bien les différents services offerts et comment ils peuvent interagir les uns avec les autres, effectuer la transition vers l’infonuagique (Cloud Computing) peut être un énorme défi.

Une architecture opposée au nuage : la monolithique

Une architecture monolithique est composée habituellement d’une seule couche de service qui est responsable de deux choses particulièrement liées :

  • L’interface utilisateur
  • La couche serveur (API)

Par contre, ces deux composantes doivent être indépendantes l’une de l’autre. C’est notamment une des raisons pour lesquelles les Single Page Applications (SPA) sont si populaires; elles permettent d’avoir une structure du côté client, mais la communication avec le serveur se fait par un point d’entrée de type API (avec REST et GraphQL, ce qui est un tout autre sujet en soi.)

Cette architecture plutôt simpliste a pourtant une importance fondamentale. En tant qu’êtres humains, elle nous permet d’utiliser notre créativité au maximum en éliminant le plus possible toutes les complexités qui peuvent apparaître lors du développement logiciel. Même avec quelques utilisateurs, le tout peut être déployé sur un serveur et tout le monde n’y voit que du feu!

Cela jusqu’au jour où nous passons le seuil critique et que l’application commence à être lente. Votre architecture doit absolument grandir (scaling en anglais).

Vous avez deux choix de mise à l’échelle (scaling) :

  • Verticalement : en ajoutant plus de mémoire ou de processeurs au serveur actuel
  • Horizontalement : en ajoutant plus de machines et plus de serveurs

C’est en utilisant l’approche horizontale que vous pouvez tirer profit au maximum d’une transition vers le nuage.

Commencez par transférer vos machines virtuelles dans le nuage

Pouvoir héberger des machines virtuelles dans le nuage est un service de base qui est offert par toutes les plateformes. C’est normal, la plupart des applications web sont développées avec des technologies de serveur qui nécessitent justement l’accès au dit serveur.

C’est pourquoi beaucoup de compagnies ont déjà effectué la migration de leurs serveurs vers le nuage. Non seulement les coûts de maintenance sont diminués, mais la sécurité est aussi améliorée. Par contre, il est à noter que cette sécurité ne vient pas par magie. Par exemple, Amazon Web Services mentionne un modèle de responsabilité partagée (Shared Responsibility Model).

Shared responsibility FR

Cela demeure tout de même une grande responsabilité pour nous de veiller à ce que notre infrastructure soit bien sécurisée. Si personne dans votre équipe n’a de connaissances de base en sécurité, cela demande beaucoup d’apprentissage afin de mettre en place ce qui influencera probablement le fait qu’un jour votre application sera piratée ou non. Prenons par exemple l’authentification des utilisateurs avec leurs mots de passe.

Composantes pouvant être remplacées par des services du nuage

Comme vous l’avez sûrement déjà vécu dans des projets précédents (ou même peut-être que vous en êtes un utilisateur sans le savoir), il existe encore des systèmes qui sauvegardent les mots de passe avec une méthode de cryptage facile à déjouer. Aussitôt qu’une entrée par infraction est faite sur la base de données, il est facile de sortir la liste des utilisateurs et de décrypter leurs mots de passe.

C’est l’exemple parfait d’une pièce d’infrastructure qui peut être migrée vers un service dans le nuage. AWS offre Cognito, Azure offre le Directory Service et Google offre Firebase. Ils comportent tous une documentation et des exemples qui vous permettent de commencer à les utiliser facilement.

La même chose existe pour l’entreposage de fichiers, les notifications et autres. Voici une courte liste avec leurs équivalents pour chaque fournisseur majeur :

Cloud services FR

Ce tableau offre une liste incomplète, car chaque mois chacune des plateformes offre de nouveaux services pour accommoder le développement d’applications. Que ce soit dans le domaine de l’infrastructure, de l’intelligence artificielle ou de l’Internet des objets (IoT), la compétition est féroce et en tant que consommateur, vous ne pouvez qu’en tirer avantage.

Séparation des domaines par expertise avec le Bounded Context

Avant de pouvoir continuer à segmenter notre application, il faut d’abord segmenter notre propre logiciel pour avoir des composantes qui sont indépendantes les unes des autres.

Pour y arriver, nous pouvons utiliser un patron du Domain-Driven Design : le Bounded Context. Il propose de diviser le domaine d’affaire de l’application en plusieurs contextes. Ces contextes deviendront nos microservices. Le but ici n’est pas d’entrer dans les détails du sujet, mais je vous invite fortement à lire un peu plus à ce propos.

Continuez la segmentation avec des microservices

En utilisant plusieurs services comme composantes de l’architecture, celle-ci devient de plus en plus segmentée. Si on jette un œil à ce que nous avons présentement comme application, elle est tout aussi segmentée mais elle est déployée sur la même machine.

C’est pourquoi si nos domaines sont bien séparés et qu’aucun ne dépend fortement d’un autre, la transition vers un microservice se résume à ajouter un point d’entrée et à en faire un conteneur.

Ensuite, les conteneurs peuvent être gérés à l’aide d’un orchestrateur qui vous offre une centralisation de vos services à travers les différentes technologies de base utilisées par les plateformes infonuagiques.

Cloud Native

Sans le savoir, je viens de couvrir deux des quatre axes principaux de l’approche Cloud Native. Soutenue par la CNCF (Cloud Native Computing Foundation), il s’agit d’une approche basée sur plusieurs systèmes à code ouvert (open source) pour déployer et gérer les applications en faisant abstraction de l’infrastructure. Le but est pour les programmeurs d’optimiser l’utilisation des ressources (pour faire des économies dans l’infrastructure), tout en ayant la possibilité de bâtir des applications rapidement.

Une application Cloud Native est idéalement conçue pour respecter la résilience, l’Agilité, l’opérabilité et l’observabilité.

La résilience nous permet de prendre en compte et gérer les erreurs, au lieu de se concentrer à les prévenir. Comme les plateformes infonuagiques offrent plusieurs composantes séparées, il faut savoir construire le système autour d’un environnement dynamique. Si un processus génère une erreur, un retour en arrière doit pouvoir se faire automatiquement pour que le processus puisse reprendre rapidement là où le problème est survenu.

L’Agilité vient principalement avec les microservices. Plus les composantes sont petites et séparées, plus les déploiements s’effectueront rapidement et nos itérations de livraison seront rapprochées les unes des autres.

L’opérabilité nous donne le contrôle sur le cycle de vie de l’application à partir de l’application elle-même, au lieu de dépendre des outils de surveillance et des processus externes. Le but est de donner le plus de responsabilités possible aux développeurs et d’éviter de tomber dans des cas dans lesquels on doit attendre quelqu’un d’autre pour investiguer ou pour remettre l’application en marche.

L’observabilité donne toutes les informations nécessaires (sous forme de métriques) pour faire état de l’application et pour mieux comprendre les problèmes avant qu’ils se rendent aux utilisateurs. Les temps de réponse, le nombre d’erreurs et la mémoire utilisée ne sont que des exemples qui peuvent nous amener à être proactifs et à améliorer l’application en amont.

En résumé, voici les quatre axes de travail pour se rapprocher d’une architecture Cloud Native :

  • Composition de l’application : elle doit être composée d’un ensemble de services.
  • Journal de bord (logs) et événements : Il doit être facile et simple de soulever un événement ou d’écrire dans le système d’enregistrement (logging).
  • Application delivery : elle doit pouvoir se déployer aussi facilement dans un environnement.
  • Common control & Ops : il devient alors possible d’automatiser les étapes et d’avoir un processus DevOps.

Commencez votre transition vers le nuage dès aujourd’hui!

Un changement de cette ampleur peut vous sembler énorme et coûteux, mais n’oubliez pas que vous pouvez simplement commencer par héberger votre application sur une plateforme infonuagique.

Ensuite, comme un enfant qui joue avec des LEGO, vous pouvez intégrer différents services selon vos besoins et faire évoluer votre logiciel plus facilement.

C’est finalement en brisant votre grosse pièce LEGO – votre application – que vous pourrez plus rapidement changer la structure sans tout casser.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *