Maintenant que vous avez tout compris à la couche applicative, il est temps de regarder de plus près les infrastructures permettant de supporter les flux, gisements de données et autres middlewares identifiés.
Il faut distinguer 2 cas :
Les infras mutualisées, utilisées par le système que vous êtes en train de bâtir, mais aussi par d’autres systèmes, sur lesquels on va zoomer au niveau des spécificités permettant de répondre aux exigences identifiées dans l’analyse fonctionnelle.
Les infras dédiées, uniquement utilisées par le système considéré, qui doivent être pensées et décrites complètement dans le cadre de cette méthode.
Je vous propose de nous concentrer sur le premier cas, les infrastructures mutualisées, car il est, selon mon expérience, le plus représentatif du quotidien. En effet, on monte rarement, par exemple, un réseau dédié pour un projet. Le Cloud renforce cette tendance en nous poussant de plus en plus à utiliser des services unitaires sans parfois pouvoir expliciter comment sont construits les systèmes sous jacents.
Comme pour l’analyse applicative, ici chaque choix de composant devra se faire en prenant en compte la partie exploitation. Choisir un élément d’infrastructure séduisant mais que personne ne maîtrise est une recette pour un désastre s’il n’y a pas une volonté au niveau de l’entreprise d’en assurer la gestion à terme.
Le calcul
Je vous propose de commencer au plus proche de l’applicatif, par la partie calcul : serveur, machine virtuelle, conteneur.
Au niveau infrastructure, on va s’attacher à décrire 3 éléments :
Le dimensionnement—quel niveau de performance requis ? Nombre de coeurs versus fréquence GHz ? Taille mémoire ? Nombre de ports réseau et/ou SAN ?
L’emplacement—Quel datacenter ? Quel fournisseur Cloud ?
L’identifiant—Qui permet de faire le lien avec la couche applicative.
On peut également mettre en avant les mécanismes de disponibilité (clustering OS, VMware HA, zone de disponibilité cloud…) en essayant toujours de répondre à la même question : comment l’architecture décrite répond aux contraintes de services ?
On ne parle plus de dimensionnement, de nos jours, avec l’auto-scaling ?
Malheureusement (ou pas…), les architectures autorisant une élasticité automatique sont encore rares et ne couvrent pas tous les cas d’usage. On pourra dans ce cas préciser au niveau de la couche technique les bornes d'élasticité ou encore les critères de montée et descente en charge.
Le réseau
Dans un deuxième temps, il peut être pertinent d’analyser la partie réseau :
Comment mes composants sont-ils interconnectés ?
Comment mes clients communiquent-ils avec les composants (que ce soit de façon physique ou virtuelle) ?
Quel débit (1G, 10G ?), quelle latence ?
Quel type de lien (RJ45, SFP, vAdapter ?) ?
Quelle redondance (LACP, interfaces multiples…) ?
Il m’arrive régulièrement de travailler sur des architectures hybrides, utilisant à la fois des infrastructures du datacenter et du cloud. Dans ce cas, la méthode d’interconnexion est capitale—que ce soit via internet ou des liens dédiés type Azure ExpressRoute ou AWS DirectConnect, il faut bien prendre en compte les débits et latences générés. Cela peut permettre d’affiner son architecture, en choisissant par exemple de placer tel ou tel service plus sensible aux contraintes réseau d’un côté ou de l’autre.
Le stockage
Un dernier élément que je vous propose d’analyser est la partie stockage. Dans la droite lignée des autres éléments, il s’agit de se poser les bonnes questions :
Comment j’accède à mon stockage (SAN ? NAS ? FC ? IP ? attachement direct ? Local ?)
Quelle forme de stockage (bloc, fichier, objet) ?
Quel type de disque utilisé (SSD vs HDD, Full Flash vs Hybride) ?
Plus généralement les performances délivrées (latence, débit, nombre d’E/S...) ?
La localisation du stockage va également être un enjeu important afin de pouvoir évaluer les risques de sinistre, dans une approche de PRA (Plan de Reprise d’Activité).
C’est également l’occasion de détailler les fonctionnalités particulières : virtualisation, cluster actif/actif, chiffrement (c’est par exemple une fonctionnalité des Azure Storage Account), réplication synchrone et asynchrone, stockage Objet…
La couche infrastructure est aussi l’occasion d’analyser et de détailler les différentes machines physiques ou virtuelles dédiées à des usages spécifiques (appliances), comme par exemple un système d’archivage (support physique à écriture unique (WORM)) ou des fermes de calcul utilisant des GPU dédiés.
Pour conclure cette partie Méthode, je vous propose de finir avec l’analyse du côté Opérations, qui met l’accent sur comment le système ou l’application va être pilotée et maintenu.
