Champ de force du cloud hybride

Depuis un certain temps déjà, SAP pousse à la mise à disposition de solutions basées sur le cloud. Et même plus encore aujourd'hui. Elle poursuit une stratégie dite "cloud first", qui se traduit par exemple par le fait que les nouveautés ou les innovations dans le successeur de la Business Suite S/4 sont d'abord mises à disposition tous les trois mois dans la variante SAP S/4 Hana Cloud. Une fois consolidées, elles sont ensuite disponibles tous les douze mois dans la version S/4 sur site.

Actuellement, les clients SAP préfèrent l'un ou l'autre plutôt que l'un ou l'autre dans le cadre de leur adaptation au cloud, qui est étroitement liée aux projets de numérisation.

Peu de clients SAP envisagent de transférer entièrement leur(s) environnement(s) SAP on-premise vers le cloud. En particulier, les moyennes et grandes entreprises comptant plusieurs milliers de collaborateurs ont tendance à ne pas suivre une stratégie "Cloud Only". Elles visent plutôt une exploitation mixte de SAP ou une utilisation de SAP sous forme de différents scénarios de cloud hybride.

Certaines parties de l'environnement d'application sont transférées sur site, d'autres sont transférées dans un cloud public ou exploitées via celui-ci. L'accent est également mis sur la transformation des environnements sur site en cloud privé.

Par exemple, en se transformant en Software Defined Infrastructure (SDI) sur la base de solutions cloud-natives telles qu'OpenStack, afin de briser les silos relativement rigides et de pouvoir réagir de manière plus agile, plus flexible et plus rentable aux exigences de l'entreprise. Et ce, dans le but d'une utilisation hybride du cloud. SAP privilégie d'ailleurs une approche similaire.

Le cloud computing hybride est en train de devenir une sorte de guide ou de champ de force pour l'ensemble du cloud computing, comme le prouvent non seulement les chiffres du marché, mais aussi la forte augmentation des demandes de clients adressées à Q-Partners/Devoteam par la communauté SAP.

Les questions qui se posent sont extrêmement variées et chaque client SAP a son propre agenda. Actuellement, le thème Infrastructure as a Service (IaaS) est en tête de l'ensemble du thème du cloud computing, avec l'achat de services d'infrastructure sur la base de SLA définis auprès d'un fournisseur de services de cloud public certifié par SAP, par exemple Google sur la base de Google Cloud Platform (GCP).

Planifier, construire, tester et exécuter

Questions en suspens : quels scénarios d'application SAP cloud aborder en premier, lesquels promettent le plus d'avantages ? Qu'en est-il concrètement des coûts - à court et à long terme ? Quelles sont les questions organisationnelles à prendre en compte ?

Qu'en est-il de la sécurité ? Que faut-il faire pour prévenir une éventuelle perte de données qui se trouvent dans un cloud public ? Ou, ou, ou.

Le fait est qu'il n'a jamais été aussi facile de mettre en place rapidement des ressources ou des capacités d'infrastructure Hana, y compris la plateforme de système d'exploitation Suse Linux Enterprise Server (SLES) pour SAP, auprès d'un fournisseur de services de cloud public (pour en savoir plus sur Suse Linux Enterprise Server pour les applications SAP et le cloud computing hybride, voir l'article Suse Linux en page 48 de ce numéro).

SAP a également joué un rôle important en développant et en fournissant des procédures et des techniques (telles que SAP CAL) permettant d'utiliser rapidement et relativement facilement des services de cloud public en combinaison avec des solutions SAP.

Néanmoins, des travaux de planification ou certains travaux de confection sont nécessaires avant l'utilisation proprement dite des services Cloud. De même que des phases de test, en plus de travaux de détail individuels. Un peu comme le bon vieux cycle de vie de projet simplifié "Plan, Build, Test and Run".

L'expérience montre que la phase de planification prend généralement le plus de place. Grâce à la collaboration entre les clients et des architectes cloud qualifiés, des concepts de solutions cloud hybrides individuels sont créés pour le build ainsi que pour le run suivant.

Différents scénarios d'application possibles de l'utilisation du cloud public sont également discutés ou arrondis. Et ce, en tenant compte de l'environnement SAP sur site existant.

Les scénarios d'application ou les modèles d'utilisation du cloud hybride, y compris la référence aux services de cloud public, sont concrètement utilisés par l'entreprise.

Au-delà des classiques - à savoir utiliser un cloud public pour les systèmes de développement, d'assurance qualité ou de test ou y réserver des ressources Hana - les scénarios d'utilisation suivants (use cases) s'offrent à nous : par exemple, utiliser Google Cloud Platform pour couvrir les scénarios de charge élevée (peaks), par exemple lors des clôtures annuelles, des consolidations mensuelles ou de certains "pics de charge".

C'est peut-être le cas chez un détaillant ("Black Friday"). En cas de besoin, la puissance de calcul moins souvent nécessaire est simplement réservée ou ajoutée via le cloud public. Cela est également important pour l'utilisation des ordinateurs et des serveurs :

L'utilisation des ressources IaaS permet d'éliminer les "coûts de dimensionnement" habituels (mot-clé : coûts de soude ou coûts qui existent de manière latente).

Un autre cas d'utilisation profitable est d'augmenter la haute disponibilité au moyen d'un système secondaire via le cloud public en utilisant la réplication de système Hana (HSR) en combinaison avec Suse SLES HAE. Ou une utilisation économique d'un patching à temps d'arrêt quasiment nul avec la mise en place d'une réplication du système Hana et la mise en œuvre du patching Hana avec Suse SLES for SAP Applications via la procédure DBSL-Suspend.

Après la réalisation, il est ensuite possible de désactiver ou de supprimer simplement l'instance "superflue". De même, on peut envisager comme scénario : avant d'effectuer un patching OS ou Hana, de le tester avec une instance temporaire sur le cloud public (capture et replay). Pour tester la performance avant et après, pour identifier d'éventuelles erreurs, pour réaliser des optimisations de paramètres et autres.

Des cas d'utilisation rentables

En outre, la réalisation de sandboxes ou de systèmes de formation via Google Cloud Platform. De plus en plus souvent, les services spécialisés ou les utilisateurs SAP souhaitent tester ou évaluer des fonctions commerciales ou pouvoir utiliser rapidement un système de formation - ce qui nécessite généralement un système Sandbox ainsi qu'une sorte de système supplémentaire avec des données actuelles.

La solution : créer une instance temporaire de BPC au moyen d'un HSR ou d'une sauvegarde et restauration d'un système Prod et l'utiliser comme système Sandbox ou de formation. Ici aussi, les systèmes peuvent être rapidement et facilement effacés ou "éliminés" lorsqu'ils ne sont plus nécessaires.

En outre, il faut déjà penser à demain. Cela signifie en particulier pour les clients SAP existants, pour lesquels SAP Leonardo est à l'ordre du jour, l'utilisation de nombreux nouveaux systèmes. Pas besoin d'être prophète : Pour utiliser judicieusement l'IoT, l'IA, le Big Data ou la Blockchain, de nombreux nouveaux systèmes supplémentaires seront nécessaires ou les systèmes existants devront être étendus.

Et bien sûr, on veut pouvoir accéder rapidement à de nouvelles possibilités d'application et ne pas avoir à subir un rallye d'acquisition et d'installation de plusieurs semaines. Ici, la solution est la même : réserver ou louer des systèmes via le cloud public avec une offre de souscription adaptée aux besoins.

Une fois la phase de planification terminée, ce qui y a été défini est mis en œuvre dans le build. Il en va de même pour les éventuels changements organisationnels, les modifications et les nouveautés qui concernent la base SAP ou l'exploitation du système SAP.

Il faut tenir compte du fait que chaque fournisseur de services cloud présente pour ainsi dire ses propres spécialités, au-delà des packages de souscription IaaS respectifs que l'on peut choisir (taille des nœuds, CPU ou types et tailles de stockage).

Profiter de l'expérience

La collaboration entre Devoteam et Google en relation avec le BPC a un caractère exclusif dans l'environnement SAP. Cela signifie également que Devoteam, via ses propres Google Cloud Professional Architects, soutient ou a soutenu à son tour Google dans la mise à disposition de services SAP IaaS de diverses manières.

Notamment en ce qui concerne les nécessités d'une exploitation SAP aussi optimale que possible par Q-Partners et, en même temps, de la mettre en œuvre de nos jours. Bien sûr, SAP et Google ont fait un travail de développement intensif avec l'annonce et la disponibilité de "SAP sur le BPC" dans le cadre de Sapphire 2017.

Cela fait longtemps que Google s'intéresse de près à SAP. Et : aujourd'hui déjà, Google met à disposition sur le BPC des tailles de nœuds VM-OLTP et VM-OLAP maximales certifiées par SAP, tout comme Amazon sur AWS et plus que Microsoft sur Azure.

L'objectif à terme est d'atteindre une taille de nœuds Hana d'environ 18 To (plus d'informations à ce sujet à la page 50 de ce numéro). La collaboration avec Google a permis à Q-Partners, en tant que SAP Gold Partner, et à Devoteam, en tant que Google Cloud EMEA Services Partner of the Year 2018, d'acquérir un savoir-faire et des connaissances empiriques précieux, spécialement en ce qui concerne l'utilisation IaaS sur le BPC, dont les clients SAP peuvent profiter dans leurs projets - aussi bien lors de la planification et de la construction que lors des tests et de l'exécution.