Dans mon billet précédent, je vous parlait de jumeau numérique, de BIM, d’industrie 4.0, de microservices et cloud.
Je l’ai évoqué sur mon compte LinkedIn, mais souvenez vous, le passage au cloud supprime le fardeau de la prise en charge de l’infrastructure informatique. J’ai en récemment fait (de nouveau) l’expérience avec un partenaire 🤦♂️.
Alors oui, c’est vrai, le constat que l’on peut faire aujourd’hui, par rapport à la décennie précédente, c’est que l’on ne sait plus réaliser et maintenir une infrastructure performante on-premise. Les technologies évoluent vite, les clients sont toujours plus exigeants et les applications toujours plus nombreuses. Impossible de faire face sans être une énorme structure déjà spécialisée dans l’IT.
Et surtout il faut se dire que le cloud public est un fabuleux accélérateur pour le développement d’applications métier et leur valorisation ! En effet, là ou avant il fallait dépenser des sommes folles en IT, attirer des talents juste pour designer, construire et maintenir une infrastructure qui puisse accueillir des applications, ces questions sont aujourd’hui caduques.
Bien sur il faut toujours des talents et le métier de l’IT existe et existera toujours.
Le TCO…
J’avais évoqué dans mon précédent billet que l’adoption d’un modèle de cloud public permet de se débarrasser de tout CAPEX ou profit de l’OPEX. Mais on peut aller beaucoup plus loin dans l’analyse, notamment en regardant le TCO (Total Cost of Ownership) qui représente le coût global d’un bien ou d’un service tout au long de son cycle de vie. Cette méthode de calcul prend aussi bien en compte les coûts directs que les coûts indirects.
Microsoft Azure propose un outil dédié pour cela. Il permet d’estimer les coûts de migration de vos données et applications vers Azure et prévoir les économies potentielles en définissant des scénarios de charge de travail « classique » dans un datacenter on premise puis en adaptant un certain nombre d’hypothèses (taux horaire de vos techniciens IT, prix de l’électricité, etc.) vous pouvez vous faire une idée assez précise de ce que peux représenter une migration vers le cloud public ou bien tout simplement vous aider à bien choisir dès le début.
Evidemment, d’autres indicateurs sont à prendre en compte.
Mais pas que.
Toujours sur LinkedIn, j’offrais un petit exemple de la mise en place d’une service de transformation de données et de ce que cela peut représenter pour Altametris ⬇️(spoiler, il est question de vitesse de delivery, d’élasticité, de scalabilité et bien sur, d’agilité mais aussi de résilience et de taux de disponibilité).
Le SLA
Quand on parle de niveau de disponibilité, on atterrit sur la notion de SLA (service level agreement). Il faut voir cela comme un contrats qui décrit l’engagement du fournisseur de service cloud en matière de temps d’activité et de connectivité. Habituellement et selon le niveau de service, on parle en « nombre de 9 » c’est à dire des taux allant souvent de « two nine » (99%) à « five nine » (99.999%). Le tableau ci-dessous ⬇️ illustre ce que cela peut représente en temps (cumulé) par semaine / mois / an.
| niveau de SLA | Downtime par semaine | Downtime par mois | Downtime par an |
| 99% | 1.68 heures | 7.2 heures | 3.65 jours |
| 99.9% | 10.1 minutes | 43.2 minutes | 8.76 heures |
| 99.95% | 5 minutes | 21.6 minutes | 4.38 heures |
| 99.99% | 1.01 minutes | 4.32 minutes | 52.56 minutes |
| 99.999% | 6 secondes | 25.9 seconds | 5.26 minutes |
Difficile d’imaginer ce genre de niveau de service dans une infrastructure on-premise sans faire exploser les coûts pour permettre d’atteindre cette objectif (plus de matériel, plus de personnel, des horaires décalés, jamais de coupure de courant, des mises à jour express, etc. )
La durabilité des données
Les données du patrimoine digital, numérique sont primordiales et ont une grande valeur pour les gestionnaires d’infrastructures. Il est absolument nécessaire d’en assurer l’intégrité à travers le temps. Les données doivent être stockées de manière redondante, idéalement dans plusieurs installations et sur plusieurs périphériques dans chacune d’elles. Des catastrophes naturelles, une erreur humaine ou des défaillances mécaniques ou électrique ne doivent pas entraîner de perte de données.
Les clouds providers comme Microsoft Azure offrent des services de stockage qui conservent toujours plusieurs copies des données afin qu’elles soient protégées contre des événements planifiés ou non, notamment des défaillances matérielles temporaires, des pannes de réseau ou de courant et des catastrophes naturelles majeures. La redondance garantit que le stockage répond à ces objectifs de disponibilité et de durabilité, même en cas de défaillance.
Les différentes options de redondance (LRS, ZRS, GRS chez Azure, les différents niveaux S3 chez Amazon) offrent une durabilité des données allant d’au moins 99,999999999 % (11 « neuf ») à 99,99999999999999 % (16 « neuf ») sur une année donnée. Mais qu’est ce que ça veut dire ?
Un niveau de durabilité de 11 « neuf » correspond à une perte moyenne annuelle de 0,000000001 % des objets stockés (un objet étant une unité fondamentale du stockage). Par exemple, si vous stockez l’équivalent de 10 000 000 d’objets (qui peuvent correspondre à autant de fichiers que vous voulez selon votre application), vous pouvez vous attendre à perdre en moyenne un objet unique une fois tous les 10 000 ans 😯. Je vous laisse faire le calcul dans le cas de 16 « neuf ».
Vous trouverez ci-dessous les différents schémas de redondance que propose Azure ⬇️.
Il va sans dire que essayer d’arriver à ce niveau de durabilité des données sur une infrastructure on premise n’est pas possible car elle fait littéralement exploser les coûts de stockage quand elle n’est pas tout simplement impossible faute de locaux.
Haut niveau de disponibilité, forte durabilité des données sont autant d’avantages qui permettent de construire des applicatifs robustes pour des besoins métier exigeants, comme la gestion du patrimoine digital des gestionnaires d’infrastructures !
Mais ce n’est pas tout ! Dans un prochain billet, je vous présenterais d’autres avantages du cloud public, notamment sur des sujets de cybersécurité et de sécurisation des applications, avec le concept de contrôle d’accès basé sur les rôles (RBAC) et de défense en profondeur .
A bientôt !