Le TCO dans l'innovation

Le traitement des données par l'informatique en mémoire nécessite pour la base de données Hana beaucoup plus de mémoire de travail, des unités centrales et des cœurs correspondants ainsi qu'une mémoire flash très rapide.

Les mécanismes habituels de disponibilité dans la virtualisation atteignent également leurs limites et de nombreux clients SAP existants doivent à nouveau penser à des appliances dédiées et certifiées.

Cela signifie que nous nous éloignons à nouveau de la virtualisation, qui a triomphé il y a plus de dix ans, et que nous nous dirigeons vers des machines physiques rigides et inflexibles.

Intégration des centres de données Hana

Celui qui veut faire fonctionner Hana sur son infrastructure informatique virtuelle existante doit respecter strictement les directives de SAP et utiliser du matériel compatible avec le "Hana Tailored Data Center Integration Guide", comme les serveurs, le stockage, le réseau et la virtualisation.

Certes, le nouveau guide Hana TDI offre désormais la possibilité de réduire davantage les cœurs de processeur et, en particulier, la virtualisation permet d'utiliser autrement les ressources non allouées, mais on est toujours dépendant du matériel sous-jacent et, en général, les amortissements du matériel et des logiciels informatiques sont fixés à cinq ans.

Ce qui, selon les critères actuels et la rapidité d'innovation, est déjà une vieille affaire après trois ans. Qui peut aujourd'hui prétendre planifier un dimensionnement de son infrastructure informatique et de son paysage SAP pour cinq ans dans le futur ?

Les directeurs informatiques et les DSI ont cette tâche permanente de trouver un équilibre entre la conscience des coûts, la flexibilité et l'agilité ainsi que l'innovation.

Dans le centre de données classique, de plus en plus de clients se heurtent à des limites insurmontables, voire à des investissements massifs, qui devraient en fait être réalisés pour mettre en œuvre la prochaine innovation dans l'informatique, ce qui occupe à son tour le personnel informatique pendant plusieurs mois avec des projets et empêche le cas échéant l'entreprise de lancer un produit ou un service.

Le dilemme est le suivant : les services spécialisés savent désormais comment consommer des services cloud par carte de crédit et ils n'attendent pas que quelqu'un ait commandé et installé un serveur.

Une comparaison avec la voiture : en fait, nous voulons simplement conduire une voiture et ne pas construire au préalable toujours plus de routes, de ponts et de bornes de recharge électrique pour cela. L'infrastructure est un mal nécessaire, mais la véritable innovation et la valeur ajoutée devraient se trouver dans le logiciel (voiture), les processus et les connaissances des collaborateurs, et non dans la tôle (route). N'est-ce pas ?

Tôle morte versus cloud

Quel est le rapport avec le TCO et SAP on Azure ? Beaucoup de choses, en fait ! Dans les prochains paragraphes, nous allons expliquer pourquoi il est important de sortir de la tôle "morte" et de se tourner vers une plateforme logicielle comme Microsoft Azure, et pourquoi il y a là des aspects intéressants en termes de TCO pour l'exploitation et l'intégration d'environnements SAP.

En quoi l'exploitation de SAP sur Azure diffère-t-elle de mon centre de données ? L'exploitation et l'hébergement ne peuvent pas être différents d'un centre de données classique à une comparaison sur la plateforme cloud de Microsoft Azure.

Mais : je déploie via Azure une machine virtuelle de la taille requise et certifiée SAP, je lui alloue la mémoire correspondante, j'installe au préalable un réseau virtuel incluant une passerelle VPN et je commence à installer le système d'exploitation, la base de données Hana et la pile de base S/4 vide.

Idéalement, j'ai terminé en deux ou trois jours et j'intègre encore un monitoring, la sauvegarde et je remets le système pour le projet test de trois mois que mes collègues américains ont demandé. Avez-vous remarqué la différence ?

Sans mon centre de données

À aucun moment, le centre de données n'a regardé s'il restait des ressources telles que le CPU, la RAM ou le disque. Dans ce scénario, nous aurions pu installer une machine Mv2 avec 12 To de RAM et 416 vCPU. Est-ce que cela serait également possible dans votre centre de données ?

L'évolutivité presque infinie promise est garantie par Microsoft avec ses centres de données dans le monde entier. Bien sûr, il ne faut pas se leurrer, Microsoft aussi doit installer et maintenir ces systèmes quelque part, mais vous, en tant que client, vous n'avez plus à le faire !

En combien de temps auriez-vous trouvé un fournisseur de centre de données aux États-Unis qui vous aurait fourni la VM avec la qualité, la certification SAP et l'intégration dans votre environnement Microsoft existant ?

La plupart des clients ont des contrats existants grâce à Office 365 et peuvent donc également utiliser la plateforme Azure. Il est toutefois important à cet égard de définir au préalable la bonne architecture cible (landing zone) avec un prestataire de services et de ne pas foncer à l'aveuglette.

Changement de Capex en Opex et évolutivité quasi infinie : grâce à l'affectation exacte des ressources aux besoins actuels, il n'est pas nécessaire de conserver et de payer des ressources vides.

Dans le scénario susmentionné, nous avons pu mettre à disposition de nos collègues américains un système de test pendant trois mois et n'avons pas eu à acheter ou à installer de serveur. Il n'y a donc pas de délai pour l'achat, l'expédition et l'installation, ni de frais d'installation. Après trois mois, nous supprimons simplement la machine et réduisons les coûts à zéro.

électricité, location, maintenance, licences

Si l'on compare les centres de données classiques avec Microsoft Azure et que l'on calcule réellement toutes les charges d'exploitation et les coûts tels que l'électricité, le refroidissement, la location, la maintenance, le matériel, les logiciels, les licences, les services informatiques et le personnel, notre expérience montre que le potentiel d'économie des centres de données hautement optimisés est généralement d'environ cinq à dix pour cent.

En revanche, les centres de données distribués, non homogènes et non optimisés présentent des potentiels d'économie pouvant atteindre 30 % et plus. Dans ce scénario, nous comparons un à un, c'est-à-dire Lift-&-Shift sans optimisation du paysage ou changement vers des services PaaS et SaaS.

L'utilisation de PaaS et de Saas Services permet ici de procéder à des optimisations supplémentaires, par exemple l'utilisation de services SQL Azure ou le Serverless Computing avec Kubernetes.

Allocation à court terme et flexible des ressources informatiques : si j'utilise maintenant aussi le concept Pay-as-You-Go et que j'éteins le système de test pendant la nuit et le week-end, je peux encore économiser des coûts.

Pay-as-You-Go signifie que je ne paie que les ressources que j'utilise réellement. Dans ce cas, il s'agirait de la machine virtuelle et de la licence OS incluse. Je dois toutefois continuer à payer pour la mémoire réservée.

Le système SAP, y compris la base de données, est coordonné et arrêté par un moteur d'automatisation, comme Ansible par exemple, et démarré au moment défini. Grâce à un portail en libre-service, je peux réduire ces efforts et la complexité et donner le contrôle aux clients internes.

Des systèmes qui respirent

Pour les périodes de projet et les situations de marché incertaines, je peux augmenter ou réduire les besoins de manière flexible et rester ainsi proche des besoins réels. Grâce à l'analyse des données de consommation, il est possible de déterminer à l'avenir les ressources nécessaires et de les réserver à l'avance de manière proactive pour l'activité saisonnière.

Il ne faut toutefois pas donner l'impression que cela n'est possible que pour les systèmes de test. Les instances de production peuvent également être mises à l'échelle et désactivées de manière flexible en fonction des besoins.

L'utilisation du libre-service et d'une forte automatisation permet de réduire encore de manière significative les dépenses liées à l'exploitation des systèmes SAP. Les demandes de copies de systèmes, de systèmes sandbox, de sauvegarde ou de machines virtuelles peuvent être traitées de manière entièrement automatisée et facturées de manière transparente au service spécialisé grâce à une logique d'imputation des coûts. Ainsi, le service informatique retrouve le contrôle des opérations et de la conformité.

Monitoring et auto-guérison

En couplant le monitoring et l'automatisation, il est possible de réaliser un self-healing en cours de fonctionnement. Dans le cas le plus simple, il s'agit de l'extension d'un disque dur jusqu'au redémarrage de la sauvegarde de journal défectueuse.

Une automatisation intelligente permet d'atteindre des temps de déploiement de l'ordre de la minute. Dans notre exemple, plus haut dans le texte, il nous faut deux à trois jours pour installer manuellement un environnement S/4-Hana vide.

Scheer, partenaire de SAP et Microsoft, a pu réduire le déploiement d'un paysage S/4 vide "from-the-scratch" à quelques heures grâce à l'automatisation sur Azure. Grâce à une Golden Image, ce délai peut même être réduit à quelques minutes supplémentaires.

Au niveau de l'exploitation, la combinaison d'Ansible et d'Azure, par exemple, permet de réaliser un patching presque entièrement automatisé et de réduire ainsi encore les charges d'exploitation. Microsoft Azure offre ici différents outils et services qui aident à orchestrer cela.

La valeur ajoutée d'Azure Cloud pour le secteur professionnel est la rapidité et l'innovation. Les nouveaux services et fonctions peuvent être mis à la disposition du service spécialisé de manière coordonnée et contrôlée par l'IT.

Les dépenses informatiques sont ainsi réduites et les collaborateurs peuvent être affectés à des tâches à plus forte valeur ajoutée. Grâce à l'innovation de nouveaux logiciels dans le cloud du jour au lendemain, il est possible de les mettre immédiatement à la disposition du service spécialisé sans devoir d'abord installer une mise à jour.

Avec le programme Embrace de Microsoft et SAP, les services Azure peuvent désormais être consommés de manière transparente par la SAP Cloud Platform dans les produits SAP, par exemple S/4 ou également dans les produits Cloud comme SuccessFactors. C'est là que naît une véritable innovation, non pas dans le serveur, mais dans le logiciel.

La plateforme cloud Azure offre, en plus de ses propres services, une place de marché logicielle quasiment infinie qui élargit le paysage SAP et le rend accessible par des services et des fonctionnalités.

Outre les services de plateforme, Azure offre une plateforme de programmation pour les projets logiciels complexes, qui peuvent ensuite être intégrés de manière transparente dans SAP. Grâce à l'informatique sans serveur avec Kubernetes, il est possible de déployer et de faire évoluer sa propre architecture logicielle de manière presque infinie et flexible.

Le défi consiste toutefois à aborder le problème réel par le biais de la technologie et non l'inverse, à savoir que la technologie cherche encore les problèmes. De nombreux clients adoptent une stratégie multi-fournisseurs avec Microsoft et SAP afin de ne pas générer de verrouillage des fournisseurs. La plupart du temps, les deux fournisseurs sont connus et peuvent bien se compléter grâce à leur portefeuille respectif.

En plus de la flexibilité, de la rapidité et de la réduction des coûts, il y a des effets doux et invisibles que l'on ne ressent que lorsqu'ils sont importants. Il est difficile de les évaluer en termes monétaires, mais la plupart des clients ont d'énormes défis à relever en termes de budget lorsqu'il s'agit de sécurité.

SLA de service et conformité

C'est comme une assurance, je n'en ai besoin qu'en cas de problème. Microsoft dépense environ un milliard de dollars par an pour la sécurité et protège la plateforme Azure contre les attaques et les abus.

Les clients reçoivent toujours ce service avec la plateforme. En outre, des services tels que Azure Sentinel, le cryptage avec Key Vault et l'authentification unique avec Azure AD peuvent être ajoutés et le niveau de sécurité individuel peut être défini pour chaque paysage ou VM.

Le centre de sécurité Azure permet de contrôler tous les paramètres et les accès liés à la sécurité et de surveiller la conformité. Par exemple, pour une entreprise qui traite des cartes de crédit, nous avons mis en place un paysage de conformité PCI-DSS entièrement fermé, qui fonctionne séparément du paysage non conforme, et donc l'augmentation des coûts pour certaines mesures de sécurité ne s'applique qu'à ces systèmes.

Scénarios DR et HA

Pour les VM à instance unique, Microsoft propose un SLA standard de 99,9 pour cent de disponibilité par mois, ce qui est une valeur très élevée pour la plupart des centres de données propres et d'hébergement.

Avec des sets de disponibilité et l'utilisation d'autres régions, cette valeur peut être augmentée jusqu'à 99,99 pour cent. Même dans le scénario DR, il est possible de mettre en place de véritables architectures géoredondantes.

L'exemple d'un client du secteur automobile a permis de réaliser une architecture Always-on avec un cluster HA-Scale-out sur Hana de 6 TB dans la région d'Amsterdam ainsi qu'avec une réplication Hana dans la région de Dublin.

Les sauvegardes sont également répliquées à Dublin et le client dispose d'une connexion réseau redondante dans les deux régions. Cette architecture couvre aussi bien les pannes locales dans le centre de calcul que les pannes régionales à Amsterdam.

En option, les sauvegardes peuvent être cryptées et mises en miroir sur un autre continent, par exemple aux États-Unis ou à Singapour.

En outre, la conformité sur Azure augmente considérablement par rapport au centre de données propre et à l'exploitation propre de SAP. Plus de 90 cadres de conformité ont été mis en place sur Azure afin de permettre à presque toutes les industries de traiter leurs clients et leurs données sur Azure.

Il est prouvé que Scheer a pu amener des clients du secteur de la finance et de l'assurance avec la conformité Bafin, du secteur pharmaceutique avec la conformité GxP ainsi que du secteur du voyage avec la conformité des cartes de crédit PCI-DSS sur la plateforme Azure avec leurs systèmes SAP et qu'il l'exploite aujourd'hui avec beaucoup de succès.

L'exemple du partenaire SAP/Microsoft Datavard montre à quel point les services Azure HDInsight Hadoop avec Azure Data Lake Store peuvent être utilisés intelligemment pour transférer les données à faible valeur et les anciennes données inutiles vers un stockage bon marché, afin de réduire la taille de la base de données Hana et d'augmenter ainsi à nouveau les performances.

Au cours des deux dernières années et demie, nous avons pu voir, à travers divers projets, qu'un TCO global de l'ordre de dix à quarante pour cent est possible. Une infrastructure informatique hautement optimisée, avec peu de changement et de croissance, profitera moins du cloud Azure qu'un environnement qui évolue de manière agile et disruptive, parfaitement adapté à une plateforme de cloud.

Dans cet environnement, il est possible de réaliser de véritables économies et de stimuler l'innovation. Nous avons notamment pu déterminer la meilleure valeur ajoutée et le meilleur TCO lors de l'introduction de S/4 dans une phase d'évaluation précoce, lorsque le dimensionnement et l'architecture ne sont pas encore clairs, et en tirer un paquet "S/4 Project Service" prêt à l'emploi à un prix attractif sur une base mensuelle.

ROI, mais quand ?

Dans l'exploitation ultérieure, l'effet d'innovation d'un nouveau paysage S/4 et les demandes de changement qui en résultent de la part des services spécialisés se manifestent à nouveau et peuvent être satisfaites immédiatement et de manière flexible sur une plateforme Azure.

En raison de la complexité de la nouvelle architecture S/4, j'ai parfois besoin de nouveaux systèmes séparés pour des produits et services supplémentaires. Si les moteurs du projet sont la conformité, la standardisation et la modernisation, on constate parfois des effets de retour sur investissement après neuf mois.

Le TCO comprend également les coûts de migration, qui sont étonnamment très faibles. Avec Azure-Migrate et -Site-Recovery, les paysages virtuels peuvent être analysés et migrés très rapidement, par exemple pendant le week-end.

Dans le cas le plus rapide, un environnement S/4 complet dans le contexte pharmaceutique validé GxP a pu être migré vers Azure en quatre semaines, du début du projet jusqu'à la mise en service.

Dans ce scénario, le temps d'arrêt correspond uniquement au temps nécessaire à la mise hors tension et à la mise sous tension ainsi qu'aux adaptations pour IP, DNS et interfaces, qui peuvent être préparées à l'avance.