Opinion : les Big 3, seul choix pour sa migration Cloud ?


 

Lorsque la plupart des gens pensent « Cloud », trois noms viennent immédiatement à l'esprit : AWS, Azure et Google Cloud.

Ces Clouds publics, connus collectivement sous le nom de "Big Three", dominent le marché du Cloud computing public depuis quelques années. Mais AWS, Azure et Google Cloud ne sont pas les seuls Cloud Provider public. Il existe un nombre conséquent d’acteurs, allant des Clouds généralistes associés aux grandes entreprises, comme Oracle et IBM, aux clouds publics de petits provider qui se spécialisent uniquement dans certains types de services cloud, comme OVH, Ionos, et bien d’autres.

Cela pose une question : est-il possible de ne pas utiliser l'un des trois grands Cloud Provider publics, et d’envisager une autre architecture ? 




Avantages des trois grands Cloud Provider publics :

Les raisons sont assez évidentes, mais elles méritent d'être précisées :

  1. Les ingénieurs IT sont d’avantage susceptibles d'avoir une expérience probante sur des infra Cloud des Big Three que sur des Clouds moins connus.
  2. En raison de leur popularité, les trois grands fournisseurs ont chacun de vastes écosystèmes d'outils, d'applications construits autour de leurs solutions. Si vous recherchez un module complémentaire tiers, vous n'avez probablement même pas besoin de vérifier s'il est pris en charge par un des 3 Big Three ; ce sera le cas !
  3. Chacun des Big Three est partie intégrante d'une plate-forme logicielle plus vaste : le commerce électronique dans le cas d'AWS, Windows et tout ce que cela implique dans le cas d'Azure, et les divers services en ligne de Google dans le cas de Google Cloud. Cela facilite l'intégration des fonctionnalisé Clouds avec d’autres services en place. Cela crée de fait des synergies puissantes. Il en va de même pour certains autres clouds publics, comme ceux d'IBM ou d'Oracle, mais ce n'est pas le cas de tous les clouds publics (chez OVH, ou Ionos typiquement, on ne trouvera pas de services créant originellement une traction de marché).

Chacun de ces facteurs contribue à faire d'AWS, d'Azure ou de Google Cloud un choix incontournable.

Mais ce n'est pas parce que les Big Three sont les Cloud Providers public les plus incontournables qu'ils constituent le meilleur choix pour chaque projet.

Voici les raisons pour lesquelles il serait peut-être envisageable de challenger ce type de décision, en envisageant aussi d’autres options

  1. Coût : en fonction de ce qu’il faudra déployer sur le cloud, un Cloud Provider du Big Three peut ou non proposer la solution la plus économique. Cela a tendance à être particulièrement vrai dans les situations où il faudra d'exécuter des gros paquets de queries dans le Cloud et que le mode de facturation repose essentiellement sur les I/O. Il sera d'ailleurs intéressant d’être en capacité de mesurer les coûts précisément, et d’en monitorer l’évolution. Il peut être utile de se tourner vers un Cloud Provider qui apportera une réponse en adéquation parfaite avec le besoin. Par exemple, si tout ce dont vous avez besoin est un stockage Cloud, un Cloud Provider spécialisé dans le stockage, peut proposer des offres plus avantageuses que celles d'AWS, Azure et Google Cloud.

  2. Performances et possibilité de configuration : de même il est possible que les Big Three offrent moins de choix ou de personnalisation pour un type de service précis que d’autre Cloud Provider plus petits. Par exemple, chacun des trois grands Cloud Provider permet d'exécuter des projets basés sur Kubernetes. Certains Cloud Provider se sont spécialisés spécifiquement dans Kubernetes dans le Cloud (ou les applications basées sur des conteneurs en général), comme OpenShift Online ou Platform 9.3.

  3. Spécialisation géographique : bien que la plupart des Cloud Provider public aient des Data Center répartis dans le monde entier, ces centres ne sont pas toujours répartis de manière uniforme. Certaines zones géographiques peuvent être insuffisamment couvertes. Typiquement, si la plupart des utilisateurs d’une solution se trouvent en Asie, Alibaba Cloud aura toute sa pertinence. Alibaba compte plus de 20 « régions » Cloud en Asie, alors que la plupart des autres grands Cloud Provider publics n'en ont que quelques-unes, voire aucune. En revanche, la présence d'Alibaba en Europe, et en Amérique du Nord est plus limitée. Le choix d'un Cloud Provider qui propose différentes options d'hébergement dans une région particulière peut contribuer à améliorer les performances techniques. La présence dans une région particulière peut aussi simplifier les réponses aux exigences réglementaires, par exemple dans le cas où il est exigé que les données soient hébergées localement.

  4. Éviter la « prolifération » de votre Cloud : Chacun des Big Three propose des dizaines de services. En général, avoir un large éventail de service est une bonne chose. Mais pour les entreprises où la gouvernance est limitée, un choix de service trop vaste peut devenir un problème. Cela peut conduire à la « prolifération du Cloud », autrement dit la tentation de lancer de nouveaux services Cloud simplement parce que... c’est possible ! Le fait de choisir un Cloud Provider qui offre les services utiles, mais pas au-delà permet d’éviter ces effets de bords. Par exemple, si votre besoin en Cloud computing se résume à une IaaS, vous pouvez décider de vous orienter vers Rackspace au lieu d'AWS, Azure ou Google Cloud. Rackspace propose une liste assez complète de services cloud en lien avec l’IaaS, mais il n'offre pas beaucoup d'autres options.

  5. Un mot sur le multicloud : nous vivons à l'ère du multicloud. Si les équipes sont à l’aise avec la complexité qui accompagne le multicloud, alors ça vaut le coût d’adopter une telle architecture ! Ça réduit la dépendance à un acteur. Dans de nombreux cas, les stratégies multicloud sont orientées vers la combinaison de deux des Big Three, plutôt que de mélanger un Big Three avec une alternative moins connue. Cependant, il faut garder à l'esprit que le multicloud ne doit pas nécessairement impliquer uniquement AWS et Azure, ou uniquement Azure et Google Cloud, ce peut-être un assortiment d'autres type de Clouds publics dans une architecture multicloud… et il est même possible de créer une architecture uniquement à partir de Clouds alternatifs 😉

Conclusion

Il existe de bonnes raisons de construire une stratégie de cloud computing basée sur AWS, Azure et/ou Google Cloud. Mais il existe d'autres bonnes raisons de regarder au-delà des trois grands et d'envisager des fournisseurs de cloud computing publics moins connus ou plus spécialisés.

Et quoi qu’il arrive, la véritable complexité résidera dans l’interopérabilité entre votre système hérité (legacy) et la plateforme cible. Les systèmes hérités cumulent deux pathologies : la volumétrie, et l’hyper complexité. Dans ce cadre-là, que faut-il garder, quelle est la « matière morte » dans le SI qu’il conviendra d’évincer… Les approches « papier / crayon » montreront rapidement leur limite. Il conviendra de procéder à un reverse engineering précis sur le système hérité, et à la mise en œuvre d’outils permettant de créer les conditions d’une véritable interopérabilité entre le système hérité, on prem’, et la plateforme Cloud.


#cloudmigrations

www.ellipsys-bi.com 

ellipsys@ellipsys-bi.com

Commentaires

Posts les plus consultés de ce blog

La Data Observabilité, Buzzword ou nécessité ?

Migrer de SAP BO vers Power BI, Automatiquement, Au forfait !

BCBS 239 : L'enjeu de la fréquence et de l'exactitude du reporting de risque