Cloud bursting : six étapes clés de la planification et de la prise de décision

1. Scénarios : modélisation des données et des flux de travail

Les organisations doivent commencer par examiner leur parc informatique actuel, y compris la façon dont elles utilisent le cloud, leurs flux de travail et les données qu’ils traitent.

L’éclatement du cloud est le plus souvent associé au calcul plutôt qu’au stockage. En effet, le déplacement de gros volumes vers le cloud et inverse peut ne pas être pratique en raison des coûts, de la latence et des risques pour l’intégrité des données. Les entreprises sont plus susceptibles de transférer les charges de travail vers le cloud lorsque les données sont déjà présentes ou lorsqu’il existe des goulots d’étranglement dans le traitement des données.

Il existe des situations où les données peuvent être déchargées vers le cloud de manière plus permanente, par exemple pour l’archivage, l’analyse avancée ou l’intelligence artificielle et l’apprentissage automatique. Le déchargement des données (souvent non structurées) vers le cloud est de plus en plus populaire à mesure que les entreprises passent au stockage objet. Mais ce ne sont pas, à proprement parler, des scénarios d’éclatement.

Le déplacement de données à partir de bases de données relationnelles est plus difficile pour des raisons de performances. Les systèmes transactionnels, en particulier, sont sensibles à la latence. D’autre part, une application Web orientée vers le consommateur pourrait éclater dans le cloud, car les consommateurs sont moins susceptibles d’être rebutés par de petits retards dans le traitement des transactions.

Le travail de test et de développement, cependant, peut être plus facilement déplacé vers le cloud et peut libérer des ressources pour les systèmes de production.

Les directeurs des systèmes d’information (DSI) doivent donc évaluer la pertinence et la faisabilité de l’éclatement des applications vers le cloud, sans oublier de prendre en compte le coût de la capacité et de l’infrastructure de support telle que les interconnexions haut débit au fournisseur de cloud.

Comme le note Ajay Khandelwal, directeur général de la stratégie logicielle chez EY, les DSI doivent évaluer quatre charges de travail clés : statique, périodique, « piquante » et inconnue ou temporaire. Toutes les charges de travail, sauf statiques, peuvent bénéficier de l’éclatement si cela est bien fait.

2. Examinez les mécanismes d’éclatement

Les grands fournisseurs de cloud divisent l’éclatement en trois catégories : l’éclatement manuel, l’éclatement automatisé et l’équilibrage de charge distribué.

L’éclatement manuel a la compatibilité la plus large, mais généralement les performances les plus faibles, car quelqu’un doit invoquer la rafale et décider également quand ramener la charge de travail en interne.

Les systèmes automatisés sont plus efficaces, mais nécessitent un investissement initial dans la technologie, telle que la mise à l’échelle de la technologie pour les machines virtuelles (VM) ou le passage à des plates-formes conteneurisées, ainsi que dans l’analyse de l’utilisation informatique. Sans données robustes, les entreprises ne sauront pas quand éclater ni quelle capacité migrer vers le cloud.

Et, bien que les systèmes tels que l’équilibrage de charge distribué soient largement invisibles pour l’utilisateur, l’architecture informatique doit être conçue pour le prendre en charge.

3. Adéquation de l’application à l’éclatement

Un nombre croissant d’applications sont désormais « cloud native » et conçues pour fonctionner dans des environnements hybrides ou multi-cloud. Mais les applications d’entreprise plus anciennes ne le sont généralement pas.

Les entreprises doivent examiner leurs applications pour voir si l’éclatement est possible, ou si l’application doit être mise à jour, adaptée ou même remplacée. S’il s’agit d’une application interne, les équipes DevOps devront se familiariser avec le cloud bursting et ses exigences techniques.

Certaines applications ne conviennent tout simplement pas au processus, car elles sont très sensibles à la latence ou à la variabilité des niveaux de service ou des délais de traitement. Ces applications pourraient être mieux exécutées en interne ou peut-être entièrement dans le cloud.

C’est également le cas pour les applications avec de très gros volumes de données. Le déplacement des données dans le cloud prendra plus de temps qu’il n’est possible, compte tenu de la nécessité de maintenir les performances des applications.

Et les organisations doivent également prendre en compte la sécurité, la conformité et la gouvernance, en particulier lorsque les données sont transférées vers un fournisseur de cloud public.

Les équipes informatiques doivent également se pencher sur la gouvernance. Peuvent-ils contrôler la période d’éclatement? Quelle est la durée probable de l’excès de charge de travail et est-il facile de réduire à nouveau? Utilisation d’un mécanisme d’éclatement de nuages aIl est peu probable que l’infrastructure infonuagique à long terme soit rentable.

4. Analyser les ressources

Bien que le cloud bursting soit maintenant assez bien établi, et quelque chose que les environnements de conteneurs tels que Kubernetes gèrent nativement, la configuration des applications et des magasins de données pour éclater vers le cloud nécessite un travail préparatoire minutieux.

Les entreprises devraient se demander si elles disposent du budget, des compétences et du temps nécessaires pour introduire le cloud bursting. Et les DSI doivent peser ces facteurs par rapport aux alternatives.

Il s’agit notamment de ressources supplémentaires sur site, ou d’une utilisation plus efficace de celles-ci via des machines virtuelles et des architectures plus modernes telles que des conteneurs, le déplacement de l’ensemble de la charge de travail dans le cloud public ou l’utilisation d’un environnement hybride plus permanent. Encore une fois, beaucoup dépendra du volume, de la nature et de la sensibilité des données de l’entreprise.

5. Élaborer une analyse de rentabilisation

Une fois que l’équipe informatique a audité les données, les applications et les flux de travail, elle peut élaborer une analyse de rentabilisation pour l’éclatement du cloud. Cela sera régi par, bien sûr, les coûts et le type de cloud bursting qui convient le mieux à la charge de travail.

Ceci, alors, devrait être mis en balance avec les avantages pour l’entreprise. Comme le souligne Anay Nawathe, consultant chez ISG, le bursting est plus adapté aux « charges de travail gourmandes en calcul et non critiques », plutôt qu’aux systèmes d’entreprise de base.

Cependant, il y aura d’autres scénarios où l’analyse de rentabilisation est plus simple. Ceux-ci sont courants dans des secteurs tels que la vente au détail, les médias et le divertissement.

Si le coût marginal de la transaction sur une base « éclatée » est inférieur au chiffre d’affaires qu’elle rapporte, et que les performances sont dans les tolérances de l’utilisateur ou du client, cela vaut la peine de le faire. Chez EY, M. Khandelwal évoque l’utilisation du cloud pour exécuter des promotions de commerce électronique lors d’un événement sportif ou du Black Friday, où les entreprises ont réalisé des économies de 50 % en déplaçant ces charges de travail vers le cloud.

6. Planifier et tester

Enfin, les entreprises doivent planifier l’introduction du cloud bursting et tester qu’il fonctionne comme prévu. Les entreprises doivent s’assurer que non seulement elles peuvent passer au cloud, mais qu’elles peuvent également revenir rapidement et sans affecter les performances des applications.

Il ne s’agit pas non plus seulement d’effectuer des tests techniques, bien que ceux-ci soient essentiels. Il s’agit également de surveiller la consommation et de combiner les données avec les prix du fournisseur de services cloud pour comprendre le coût réel du processus.

Et si la technologie, les besoins de l’entreprise ou les prix des CSP changent, les DSI doivent réexécuter leurs modèles pour revenir sur ce flux de travail et examiner une fois de plus leurs décisions en matière d’éclatement du cloud.