Bien bâtir un SI dans le Cloud

L’architecture d’un SI qu’est-ce que c’est ? En parlant d’architecture on parle tout de suite de conception. Evidemment ici je ne vais pas commencer à évoquer l’inventaire des techniques de conception mais plutôt prendre le recul nécessaire pour identifier ce qu’on veut construire et avec quels moyens. C’est-à-dire prendre le point de vue de l’architecte solution.

Il y a un certain nombre de considérations à prendre en compte lorsque l’on utilise les infrastructures cloud comme moyen pour déployer une solution. Parmi elles on peut évoquer la sécurité, la flexibilité du système, sa robustesse, sa disponibilité, sa fiabilité et son coût. À quel point ces aspect peuvent être difficiles à mettre en place ? En particulier dans le cloud public on va s’appuyer sur les bonnes pratiques à suivre.

Premièrement on ne conçoit pas un système juste pour construire un système. En règle générale on va d’abord commencer par trouver la proposition de valeur qui va déterminer la raison de vivre de notre système. Cette valeur ajoutée c’est la fondation de notre système. A l’image de la fondation d’une maison en construction nous allons concevoir notre système sur cette valeur.

Il y a certainement une valeur ajoutée à prendre en compte lorsqu’on utilise une architecture statique. Cependant cela fait perdre beaucoup d’argent lorsque le système tombe en panne ou lorsqu’il doit absorber plus de trafic. On ne voudrait par exemple pas que notre site de e-commerce tombe en panne pendant les soldes.

Adopter une architecture moderne c’est donner plus de responsabilités à notre fournisseur d’infrastructure et de services cloud. Si on est dans la position d’un éditeur de logiciel les exigences non fonctionnelles sont invisibles du point de vue de l’utilisateur. Elles permettent quant à elles d’avoir une fondation solide pour la création de valeur. Dans cet équilibre de responsabilité entre l’éditeur de logiciel et le fournisseur cloud on va s’orienter vers une architecture moderne en utilisant des services basés sur le PaaS (Plateform as a Service).

Les bonnes pratiques? A quoi ça correspond dans le cloud?

Revenons au but principal de ce post qui est de:

  • Évaluer et améliorer les architectures
  • Mieux comprendre l’impact commercial des décisions de conception

Essayons maintenant de répondre à la question: « Es-ce que les infrastructures de votre SI suivent les bonnes pratiques? »

Il faut accroître la sensibilisation aux bonnes pratiques architecturales, telles que la sécurité, l’optimisation des coûts et l’efficacité des performances. Ces bonne pratiques sont des domaines fondamentaux qui sont souvent négligés, alors assurez-vous de les aborder. Vous devez également évaluer vos architectures en utilisant un ensemble cohérent de principes.

Ici nous ne parleront pas de détails ou de modèles architecturaux ou d’étude de cas. Nous allons plutôt nous centrer sur la compréhension critique des décisions architecturales. Quels sont les services ou les solutions pertinentes pour répondre à une problématique? Quelles sont nos références? Répondre à ces questions va vous donner l’appétence nécessaire à la remise en question de vos infrastructures en termes d’efficacité fonctionnelle et d’optimisation des coûts.

Pour répondre à la sensibilisations aux bonnes pratiques, je vais reprendre les 5 piliers architecturaux proposé par AWS:


Excellence
Opérationnelle

Sécurité

Fiabilité

Performance & Efficacité

Optimisation des coûts
Excellence opérationnelle pour offrir une valeur commercialeSécurité pour protéger et surveiller les systèmesFiabilité pour se remettre d’une panne et atténuer les perturbationsEfficacité des performances pour utiliser les ressources avec parcimonieoptimisation des coûts pour éliminer les dépenses inutiles
Les cinq piliers de l’architecture cloud (vision AWS)

L’excellence opérationnelle implique la capacité d’exécuter et de surveiller le système, ce qui contribue à offrir une valeur commerciale et à améliorer continuellement les processus et procédures de support.

La sécurité est la capacité de protéger les informations, les systèmes et les actifs. La sécurité offre également une valeur commerciale grâce à des évaluations des risques et des stratégies d’atténuation

La fiabilité permet à votre système de:
• Récupérer après une panne d’infrastructure ou de service en cas d’incident
• Acquérir dynamiquement des ressources informatiques pour répondre à la demande
• Atténuer les perturbations, telles que les erreurs de configuration et les problèmes de réseau transitoires.

L’efficacité des performances est la capacité d’utiliser efficacement les ressources informatiques pour répondre aux exigences du système. N’oublions pas que dans le cloud nous avons la possibilité de redimensionner les instances de calcul au plus proche de la demande. Vous voulez être sûr que le système maintient cette efficacité à mesure que la demande évolue et que les technologies évoluent.

L’optimisation des coûts est la capacité d’éviter ou d’éliminer les coûts inutiles et les ressources non-optimales. Vous ne voulez pas payer pour quelque chose dont vous n’avez pas besoin ou que vous n’utilisez pas.

Avantages d’architecture entre un environnement traditionnel et un environnement Cloud

Voyons comment répondre à des sujets architecturaux génériques et quels sont les avantages du cloud par rapport à ce qui peut être fait dans un environnement traditionnel avec les 6 sujets suivants:

SujetEnvironnement TraditionnelEnvironnement Cloud
éviter de deviner les besoins en termes de capacitéLa décision sur la capacité du système s’effectue avant le déploiement. On finit par gaspiller des ressources inactives mais coûteuses. On doit faire face aux performances et aux capacités limitées par les décisions précédentes.On élimine l’étude et les procédures préalable sur les besoins en terme de capacité de l’infrastructure. On utilise autant de ressources que nécessaire . On automatise le passage à l’échelle
tester le système à l’échelle de la productionIl est coûteux d’investir dans un environnement de test à l’image de celui en production. La conséquence c’est que la plupart des environnements de ne sont pas testés à l’échelle de l’environnement en production.On peut dupliquer l’environnement en production à la demande, le tester et ensuite le mettre hors service. Comme on paye l’environnement de test que lorsqu’il est en service, cela ne représente qu’un coût négligeable par rapport à un environnement de test permanent.
automatiser pour faciliter les expériences architecturalesAutomatiser cet écosystème peut avoir un certain coût car plus difficile à maintenir si de multiples composants ne sont pas cohérents en terme d’interfaces (API) sur toute l’infrastructure.L’automatisation permet un accès à la création et à la réplication de composants sans effort manuel supplémentaire et à moindre coût. On peut suivre les modifications apportées à une automatisation, auditer les impacts et revenir à une configuration antérieure si nécessaire.
Permettre des architectures évolutivesLes décisions architecturales sont souvent mises en œuvre de manière ponctuelle. Elles déterminent souvent les version majeures de l’architecture et sont peu fréquentes au cours de la vie d’un système. Au fur et à mesure que l’entreprise évolue, les décisions initiales peuvent entraver la capacité du système à répondre à l’évolution des besoins de l’entrepriseLa possibilité d’automatiser et de tester à la demande réduit le risque d’impact des modifications de conception. Cela permet aux systèmes d’évoluer au fil du temps facilement. Les entreprises peuvent alors profiter des innovations comme une pratique standard.
Piloter l’architecture à partir des donnéesLes décisions architecturales sont souvent prises en fonction de l’organisation standard plutôt que par une approche basée sur les données. Un ensembles de données difficile à obtenir peut vous empêcher de prendre des décisions éclairées. Vous utilisez donc probablement des modèles et des hypothèses pour dimensionner votre architecture.Vous pouvez collecter des données sur la façon dont vos choix architecturaux affectent le comportement de la charge de travail du système. Vous pouvez ensuite utiliser ces données pour prendre des décisions factuelles sur la façon d’améliorer la charge de travail du système. Votre infrastructure cloud est faite à base de code, vous pouvez donc utiliser ces données pour justifier vos améliorations au fil du temps
S’améliorer à travers des « jours de matchs »Dans un environnement traditionnel, vous n’appliqueriez votre procédure de déploiement ou de récupération que lorsque qu’un événement inhabituel se produirait en productionDans le cloud, vous pouvez tester les performances de votre architecture et de vos procédures en planifiant régulièrement des « jours de match » pour simuler des événements inhabituels en production. Ce processus vous aidera à comprendre où vous pouvez apporter des améliorations, et il peut aider votre organisation à acquérir une expérience dans le traitement des événements inhabituels.
Les pratiques architecturales génériques dans le cloud selon AWS

Pour capitaliser sur le contenu de l’article, on a vu comment évaluer et à améliorer les architectures. On a découvert les principales caractéristiques et avantages des 5 piliers architecturaux et découvert les principes de conception pour faciliter une bonne conception architecturale dans le cloud.

Dans un deuxième temps et dans de nouveaux billets je vais aborder les 5 piliers architecturaux un à un.


Commentaires

Laisser un commentaire

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