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

Enregistrer un commentaire

Posts les plus consultés de ce blog

Migrer de Oracle à Postgre en automatisant le processus !

Image
    Migrer de Oracle à Postgre en automatisant le  processus, au forfait  ! De nombreuses entreprises quittent Oracle pour PostgreSQL   Oracle Database a la réputation d'être coûteuse en termes de licences et de support.  Cette politique de tarification peut rendre Oracle moins attrayante pour certaines entreprises. Bloomberg note une baisse des ventes de nouvelles licences chez Oracle. Baisse qui se perpétue depuis 7 trimestres.    En face, on a la base de données PostgreSQL,  qui est gratuite, que l’on peut modifier et distribuer, qui a la réputation d’être fiable et stable, avec une bonne gestion des transactions... Tous ces éléments la rendent appropriée pour des applications critiques où la cohérence des données est essentielle. PostgreSQL prend en plus en charge une grande variété de types de données, y compris des types géospatiaux, JSON, etc., ce qui la rend adaptée à la manipulation de données complexes et variées.     Postgre est maintenant la 4ème base de données la plus
Lire la suite

Sur-administrer une plateforme SAP BO simplement

Image
I- Introduction  _______________________________________ Courte histoire de SAP BO :  La Business Intelligence existe depuis 30-40 ans. Business Object, vient de souffler ses 30 bougies (1990). Pratiquement aux origines ! L’idée géniale des inventeurs :  rendre intelligible la donnée, et la mettre à portée de clic pour le métier.           Au départ, dans chaque entreprise qui implémente SAP BO, il y peu d’utilisateurs, mais très vite les plateformes sont dépassées par leur succès. Des Business Analysts viennent s’interfacer. La complexité, et même l’hyper complexité deviennent la norme. Et la confiance s’étiole. Les versions (BO 3.0…. 6, XI, XI R3, 4.0,1,2,3 …) se sont enchainées sur quasi 30 ans sans véritablement bouleverser le concept de départ même si la version Cloud (SAP Analytics Cloud) vient de voir le jour.    SAP BO vs « les tendances de marchés » : Le métier veut de l’autonomie, veut pouvoir jouer dans d’immenses « bacs à sable » de données, et obtenir des réponses instanta
Lire la suite

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

Image
    La Data Observabilité,   Buzzword ou nécessité ?   La qualité des données utilisées dans les opérations quotidiennes a un rôle prépondérant pour les entreprises.    Une étude du Gartner de 2022 suggère que les "mauvaises données" coûtent aux organisations environ 12,9 millions de dollars par an.  Le Data Quality Hub du gouvernement britannique estime que les organisations consacrent entre 10 % et 30 % de leurs revenus aux problèmes de qualité des données, ce qui peut représenter des centaines de millions de dollars pour des entreprises de premier plan.  Dès 2016, IBM estimait que la mauvaise qualité des données coûtait aux entreprises américaines 3 100 milliards de dollars par an. ... Tout le monde souhaite s’appuyer sur des données intègres pour éviter des erreurs simples liées à des problèmes d’alimentation dans des flux, ou à des données mal organisées, répliquées, etc. Mais comment ?    Les techniques d' "observabilité des données" sont une option.     
Lire la suite