Le cloud est devenu une solution d’infrastructure incontournable : nous proposons dans cet article de passer en revue ses impacts sur l’architecture du SI.
Impossible d’éviter un SI hybride
Garder un SI interne “on premises” est devenu intenable pour différentes raisons :
- Les métiers exigent de bénéficier de l’agilité et des innovations fonctionnelles offertes par le Cloud. Ainsi, même les grands comptes qui ont de fortes contraintes de sécurité utilisent des solutions SaaS.
- Il est impossible de rivaliser, à des coûts acceptables, avec les SLA et la durabilité offertes “by design” par le Cloud grâce à des zones de disponibilité répliquées.
- Les solutions Cloud permettent de minimiser les tâches de production car elles sont managées (l’opérateur gère les montées de version, le provisioning des ressources, les sauvegardes, etc.)
Par ailleurs, avoir son SI sur un seul Cloud, par exemple un des 3 hyperscalers, est quasiment impossible. Ce serait se couper :
- Des innovations fonctionnelles des pure players SaaS : CRM, SIRH, etc.
- Des innovations techniques des pure players PaaS : nocode, routage d’email, etc.
Par conséquent, deux choix s’offrent à nous aujourd’hui :
- Un SI hybride multi-cloud pour les PME et les startups
- Un SI hybride on premises/multi-cloud pour les entreprises ayant un patrimoine informatique et/ou des contraintes réglementaires
L’architecture cloud-ready
Pour bénéficier au maximum de la scalabilité offerte par les plateformes Cloud, il est incontournable de bâtir des applications reposant sur :
- Du traitement distribué permettant l’auto-scaling des charges de travail
- De la persistance distribuée permettant la réplication des données et fichiers
Les architectures à base de conteneurs et de microservices ont deux avantages :
- Elles répondent très bien à ce besoin de scalabilité
- Elles sont déployables on premises comme sur les cloud publics (voir la métaphore marine des conteneurs)
On dispose donc aujourd’hui d’un pattern d’architecture totalement adapté au SI hybride.
Mitiger l’entropie
La multiplication des opérateurs Cloud rappelle les problématiques de dispersion des systèmes informatiques rencontrées par les grands comptes à l’an 2000.
On parlait à l’époque d’urbaniser son SI afin de limiter leur entropie. En particulier, les grands comptes ont lancé à cette époque des projets de gestion centralisée des identités (IAM) et d’intégration des informations entre les applications (EAI).
Le SI hybride repose ces questions d’entropie et y ajoute une problématique de latence réseau, liée à un SI distribué à l’échelle de l’Internet. Le Cloud peut donc être vu comme un cauchemar pour les architectes de SI…
Heureusement, des solutions ont commencé à émerger pour mitiger cette entropie :
- Des opérateurs network-as-a-service (NaaS) qui nous interconnectent avec les Clouds et garantissent une qualité de service réseau
- Des solutions d’Identity-as-a-Service (IDaaS) pour fédérer les identités Cloud
- Des solutions d’Integration platform as a service (iPaaS) pour gérer les flux d’information entre les Clouds et leurs API
Il est donc aujourd’hui possible de bien architecturer un SI hybride. Le schéma illustre cette démarche avec quelques exemples de solutions.