AWS Public CloudSpoiler : il l’est.

 

Nous avons des relations avec de nombreuses entreprises clientes, et connaissons leurs préoccupations et hésitations face à la perspective de migrer leurs charges de travail SAP vers AWS. Dans cet épisode, nous aborderons quelques thèmes récurrents qui méritent une investigation supplémentaire.  Plus précisément, nous examinerons les inquiétudes que suscite la perspective de placer des charges de travail vitales, héritées d’anciens systèmes, dans le cloud AWS.

 

Adoption de la plateforme de cloud public

 

Commençons par la plateforme. Considérant le cloud public tel qu’il était il y a seulement quelques années, rares étaient ceux qui l’estimaient adapté à l’hébergement d’une base de données, quelle qu’elle soit… et encore moins à celui d’une charge de travail vitale. Les performances, les ressources et l’accessibilité suscitaient questions et inquiétudes.

 

Mais notre perception et notre confiance ont évolué au fur et à mesure que le cloud public gagnait en maturité. Aujourd’hui, personne ne pourrait imaginer une plateforme cloud incapable de supporter plusieurs bases de données en offrant des performances comparables à celles offertes par un cloud privé ou une infrastructure sur site.

 

Avec l’adoption grandissante du cloud public, les inquiétudes au sujet de la sécurité et de la conformité se sont aussi intensifiées. Rien de surprenant. Le cloud public est un peu comme une boite noire. En moins de mots, rares sont ceux qui savent réellement ce que le cloud AWS (Amazon Web Services) a sous le capot mais tous savent qu’il fonctionne exceptionnellement bien. Outre l’énigme du cloud AWS, certains continuent de trouver déconcertante la façon dont cet univers multi-locataires hyper-extensible a littéralement réinventé la sécurité.

 

Les points forts du cloud AWS

 

Le déploiement de pare-feu, première ligne de défense lors d’un déploiement sur site, fait désormais davantage figure d’exception que de règle dans le cloud. Qui aurait pu le prédire ? Il est intéressant de noter que les sociétés informatiques n’ont pas complètement adopté le cloud public pour toutes leurs charges de travail, parce qu’il s’agit d’une infrastructure partagée à la base.

 

Bien que source d’inquiétudes légitimes au sujet des « voisins » qui font du bruit et des attaques DDoS, c’est aussi là le véritable point fort d’Amazon Web Services. Le cloud AWS est pratiquement capable d’auto-régénération et dispose de plus de 100 services, notamment les groupes de sécurité ACL, ou des services avancés tels que AWS Shield Advanced, à même de sécuriser l’infrastructure à la périphérie de votre nouveau réseau virtuel. En matière de conformité, AWS répond à la quasi-totalité des normes en vigueur.

 

Malgré tous les outils qu’offre le cloud AWS, les possibilités d’exploitation vont bien au-delà des simples outils natifs lors des déploiements de SAP dans le cloud AWS. Et c’est là que la plus grande place de marché au monde entre en jeu.  Outre une bonne connaissance du cloud AWS et d’AWS Marketplace, il est également indispensable de connaître SAP et la façon de créer une architecture pour SAP dans le cloud AWS.

 

Créer une architecture pour SAP dans le cloud AWS

 

Par exemple, nous déployons SAP dans le cloud AWS sans presque aucune exposition publique à Internet. Nous verrouillons tout et déployons des bastions de contrôle qui sécurisent davantage l’environnement SAP. Nous utilisons la meilleure solution de surveillance de sa catégorie comme fondation et déployons des collecteurs qui travaillent de concert avec AWS CloudWatch pour apporter la visibilité requise sur l’ensemble de la pile.

 

Ne pas avoir d’accès racine aux hyperviseurs ne signifie pas que nous n’avons pas – ou n’avons pas besoin – de visibilité sur l’état de santé de l’infrastructure sous-jacente. C’est justement là que se situe la différence entre un suivi d’événement réactif et un suivi d’événement préventif.

 

C’est précisément ce qui fait d’AWS une excellente plateforme d’hébergement pour une application aussi sophistiquée que SAP. Mais malgré la puissance du cloud AWS et tous nos outils spéciaux de déploiement, certaines questions techniques continuent de se poser concernant la migration des charges de travail héritées vers le cloud public, et il convient de les étudier.

 

Migration des charges de travail héritées vers le cloud public

 

Pour resituer le contexte, lorsque nous parlons d’applications qui sont expressément conçues pour s’épanouir dans le cloud public, nous employons des termes comme Cloud Natives ou Born in the Cloud (natives/nées dans le cloud). Cela désigne les applications de nouvelle génération qu’il faut architecturer pour maximiser toutes les couches de la pile et pas uniquement la couche du système d’exploitation et celle de virtualisation.

 

Peu de systèmes historiques (comme l’indique leur nom) respectent ces critères. Ceci est dû au fait que la plupart des applications héritées, telles que SAP, sont transportées individuellement et depuis une zone de serveur spécifique. Ces applications ont été à l’origine architecturées et conçues pour des environnements statiques, et la plupart d’entre elles étaient déployées sur des infrastructures, serveurs ou appareils dédiés. Stables. Prévisibles. Isolées. Mais avec l’avènement de la virtualisation, ce modèle est en voie de disparition.

 

Au cours des dernières années, nous avons pu observer un basculement. Il y a de plus en plus d’applications héritées prises en charge par des machines virtuelles, ce qui a ouvert la voie à la virtualisation, et par extension, aux fournisseurs de cloud public. Concernant SAP, et plus récemment, SAP HANA, les deux solutions sont aujourd’hui certifiées non seulement comme machines virtuelles de vos – et nos – centres de données, mais aussi comme instances du cloud AWS.

 

Cette certification atteste que SAP est complètement Cloud Ready – prêt pour le cloud. L’expression « Cloud Ready » désigne un état dans lequel les applications héritées qui ne sont pas nées dans le cloud ont été testées, approuvées et peuvent fonctionner comme prévu dans un cloud public hyper-extensible (dit Hyperscale).

 

Mais ce n’est pas tout. C’est une chose pour SAP que d’être Cloud Ready, c’est une toute autre de la combinaison de vos machines virtuelles, systèmes d’exploitation et bases de données à faire certifier. C’est là que le cloud AWS s’avère conforme à la matrice de disponibilité des produits (dite PAM, pour Product Availability Matrix) de SAP.

 

Partenaire dans le développement d’une stratégie clé

 

C’est ici qu’un partenaire qui vous sait naviguer les méandres de ces directives très diverses peut vous aider à développer votre stratégie. Par exemple, Oracle travaille avec SAP et est disponible dans le cloud AWS. Mais comment connaître les versions spécifiques du système d’exploitation qui seront compatibles sans une expertise englobant à la fois le cloud AWS et SAP ?

 

Pour conclure, là est toute la puissance du POC. SAP fonctionne dans, et est certifié pour, le cloud AWS. OK. Les bases de données prises en charge par SAP fonctionneront dans, et sont certifiées pour, le cloud AWS. OK. SAP fonctionne et est pris en charge par ESX dans vos centres de données comme dans les nôtres. OK.

 

Toutefois, SAP requiert de nombreux correctifs. Lors d’une migration vers le cloud AWS, il est utile de savoir en amont que vous n’êtes pas les premiers à rencontrer un problème, de savoir s’il existe des correctifs pour couvrir les éventuels points de friction lors de votre déploiement SAP dans le cloud AWS, et de pouvoir valider la compatibilité et vos performances SAP dans le cloud AWS.

 

C’est là que notre partenariat avec SAP et le cloud AWS s’avère particulièrement utile. Parlons ensemble de ce que nous pouvons faire pour vous aider à réaliser un POC où les coûts d’infrastructure et de licence ont été absorbés, afin de faire de votre transition une expérience positive.

 

Donc, oui, le cloud public AWS est prêt pour héberger SAP. Avec le bon partenaire et avec un peu plus de soins et d’attentions, la migration sera tout ce qu’il y a de plus gérable et prédictible.

 

Au prochain épisode,nous verrons pourquoi la migration de SAP vers le cloud AWS n’est pas seulement gérable et prédictible, mais aussi commercialement sensée en termes de coûts, de retour sur investissement et de priorités informatiques diverses.  Nous montrerons comment créer un cas d’école probant et vous aiderons à déterminer le calendrier le plus adapté pour envisager une migration au regard de votre environnement et de vos ressources limitées.