Mis à jours 30 décembre 2018
La migration vers le cloud, est-ce bon pour vous ?
Le déplacement des applications et des services vers le Cloud est un procès à long-terme mais cela ne signifie pas que la migration vers le cloud est bon pour tout le monde. Bien que les environnements cloud soient généralement évolutifs, fiables et hautement disponibles, ceux-ci ne seront pas les seules critères auxquelles s’appuient la décision de migrer vers le cloud. Tout en prenant cette décision, il faut être totalement impartial afin de pouvoir faire le bon choix.
Les avantages possibles d’une migration vers le cloud
Il existe de nombreux scénarios qui peuvent vous emmener à vouloir profiter des avantages d’une migration vers le cloud :
- Le trafic vers votre application devient de plus en plus nombreux et vous avez du mal à ajuster rapidement les ressources pour satisfaire cette demande qui ne cesse d’augmenter.
- Vous avez besoin de réduire les coûts opérationnels tout en augmentant l’efficacité informatique.
- Vos clients ont besoin d’une implémentation et d’un déploiement rapides des applications et souhaitent donc se concentrer davantage sur le développement tout en réduisant les frais généraux d’infrastructure.
- Vos clients souhaitent étendre leurs activités sur le plan géographique, mais vous pensez que la mise en place d’une infrastructure multi-région avec tous les efforts de maintenance, de temps, humains et de contrôle des erreurs associés, sera un défi.
- Vous trouvez que faire face à la croissance de vos besoins de stockage devient un problème.
- Vous souhaitez créer une équipe de développement distribuée à grande échelle. Cela qui implique que les environnements Cloud Computing permettent aux employés situés à distance d’accéder aux applications et à travailler via Internet.
- La mise en place d’un système de récupération en cas de sinistre informatique pour un centre de données complet peut parfois coûter presque le double, et nécessite également des plans complexes de récupération. Toutefois, les systèmes Cloud Disaster Recovery peuvent être mis en œuvre plus rapidement et simplement tout en permettant un meilleur contrôle des ressources.
- Le suivi et la mise à niveau du logiciel de serveur sous-jacent peuvent prendre beaucoup de temps. Dans certains cas, un fournisseur de cloud prendra soin de cela automatiquement. A noter que certains modèles de Cloud Computing gèrent de manière similaire plusieurs tâches d’administration telles que la sauvegarde de la base de données, les mises à jours de logiciels et la maintenance périodique.
Les risques possibles d’une migration vers le cloud
Les risques et les inconvénients éventuels associés aux migrations vers le cloud ne doivent absolument pas être ignorés. Considérer les points suivants :
- Si votre application contient et récupère des données très sensibles, vous ne pourrez peut-être pas la maintenir dans le cloud. De même, les exigences de conformité peuvent également limiter vos choix.
- Si tout fonctionne bien avec la configuration existante, plus besoin d’apporter plus de maintenance, de mise à l’échelle et de disponibilité, et si vos clients sont tous heureux, pourquoi le gâcher ?
- Si une partie de la technologie sur laquelle vous comptez actuellement est un logiciel propriétaire, vous ne pouvez pas être légalement capable de le déployer sur le cloud.
- Certaines opérations pourraient subir une latence supplémentaire lors de l’utilisation d’applications cloud sur Internet.
- Vous risquez de perdre de la transparence et du contrôle lors du débogage des problèmes de performances puisque le matériel informatique est contrôlé par une autre personne.
- Les « voisins » bruyants dans un environnement de cloud peuvent occasionnellement prendre tout e processus, vos transferts réseau ou vos opérations de stockage et monopolisent les ressources partagées.
- Votre conception et votre architecture d’application particulière peuvent ne pas suivre complètement les architectures de cloud distribuées et peuvent donc nécessiter certaines modifications.
- Vous (ou vos clients) craignez des problèmes inconnus.
Bien sûr, vous pourriez rencontrer des problèmes entièrement différents dans votre propre migration, mais cela devrait au moins vous aider à réfléchir.
Quel type de cloud avez-vous besoin ?
Après avoir décidé de migrer les charges de travail vers le cloud, il faut bien choisir le type de cloud computing à mettre en œuvre. Généralement, il existe trois sortes :
- IaaS : Infrastructure en tant que service. Exemples : AWS, Azure, Google Compute Engine. Avec IaaS, vous gérez les applications, les bases SQL, la sécurité et l’intégration ainsi que les bases de données. Par contre, le fournisseur de cloud se charge de serveurs, de la virtualisation, du serveur HW, du stockage et de la mise en réseau.
- PaaS : Plate-forme en tant que service. Exemples : AWS Elastic Beanstalk, Heroku, Google App Engine. Avec PaaS, vous êtes en charge des applications tandis que le fournisseur de cloud s’occupent des bases SQL, de la sécurité et l’intégration, des bases de données, des serveurs, de la virtualisation, du serveur HW, du stockage et de la mise en réseau.
- SaaS : Logiciel en tant que service. Exemples : Google Apps, Salesforce. En optant pour SaaS, c’est le fournisseur de cloud qui gère tout : les applications, les bases SQL, la sécurité et l’intégration, les bases de données, les serveurs, la virtualisation, le serveur HW, le stockage et la mise en réseau.
Ceux qui souhaiteraient bien héberger leurs applications dans des centres de données tiers mais préfèrent externaliser le soin de leur infrastructure physique afin qu’ils puissent se concentrer complètement sur le développement, le déploiement et la surveillance de leurs applications, devraient choisir un hôte IaaS.
Mais si vous préférez que vos applications soient portables, vous devrez simplement déposer votre code sur une plate-forme PaaS robuste qui offre un environnement d’infrastructure complet (et invisible). Concernant SaaS, c’est un modèle de livraison de logiciel dans lequel le logiciel de productivité est hébergé centralement et sous licence.
Les occupations de chaque modèle de cloud
Public, privé ou hybride ?
Après avoir choisi un modèle de cloud, il est temps d’opter pour un type de cloud. Il existe trois options de base :
- Public : où vos ressources sont entièrement hébergées par un fournisseur de cloud comme AWS d’Amazon. Elles sont virtualisées et partagées publiquement. En effet, le cloud public prend en charge plusieurs clients et il est accessible sur Internet. Il convient aux informations moins confidentielles.
- Privé : où vous créez votre propre cloud privé à l’aide d’une plate-forme comme OpenStack ou vCloud de VMware. Les ressources sont virtualisées et partagées en mode privé. De ce fait, le cloud privé est destiné au groupe de clients dédiés. Son accès se fait par Internet, par réseau à fibres optiques et privé. Il est surtout utilisé pour les informations confidentielles et s’adapte aux systèmes de base.
- Hybride : où vos ressources sont réparties sur des plate-formes privées et publiques. C’est donc la combinaison de cloud public et cloud privé où les ressources spécifiques sont utilisées dans le cloud public tandis que d’autres sont ajoutées dans le cloud privé.
Grâce à la combinaison saine de la fiabilité et de l’accessibilité, de la haute disponibilité, de la sécurité et de coûts d’exploitation réduits, les implémentations de cloud hybrides peuvent être attrayantes. Opter pour cloud hybride peut parfois donner le meilleur des deux mondes.
Comment le cloud hybride peut-il fonctionner à travers un scénario hypothétique ?
Imaginez que votre application web gagne rapidement en popularité et attire de nombreux utilisateurs. Afin de répondre à cette demande qui ne cesse d’augmenter, vous avez besoin de la ressource sous-jacente pour augmenter votre capacité de stockage de façon dynamique. Pendant l’utilisation maximale de ressources, vous devriez être capable de les déployer pour satisfaire les requêtes, et quand la demande baisse, vous devriez idéalement déposer des ressources inutiles pour économiser des coûts. Avec un cloud public, ceci est tout à fait possible. Mais supposons que les données recueillies par votre application soient très confidentielles et ne doivent pas être stockées dans le cloud public. C’est là qu’une solution hybride peut vous aider. Elle vous permet de choisir les composants que vous souhaitez ajouter dans le cloud public et dans le centre de données.
Notez que la prédiction de Gartner, l’entreprise américaine de conseil et de recherche dans le domaine des techniques avancées, indique que prés de la moitié des grandes entreprises disposeront de déploiements de cloud hybride d’ici la fin de 2017.
Grâce au cloud hybride, votre application est évolutive et prête à faire face à une charge fluctuante. En même temps, vos données sont sécurisées dans votre centre de données.
Evaluation des applications pour une migration vers le cloud
Après avoir choisi un modèle et type de cloud, c’est le moment de la vraie bataille car vous devez évaluer votre application pour la préparation de la migration vers le cloud. Voici quelques éléments dont vous aurez besoin :
1. Complexité de la conception de l’application
Certaines applications traditionnelles sont très compliquées et étroitement liées que les clients pourraient ne pas vouloir les retravailler. Cependant, l’exigence principale pour toute migration réussie est que l’application devrait suivre une architecture distribuée et devrait être évolutive par son design. Il existe de nombreux outils disponibles sur le marché comme PaasLane qui peuvent être utile lors de l’évaluation de la préparation de vos applications à migrer vers le cloud.
2. Complexité d’intégration
Chaque application a ses points d’intégration comme les passerelles de paiement, les serveurs SMTP, les services Web, le stockage externe et les fournisseurs tiers. Alors, il est important d’analyser l’impact de votre migration vers le cloud sur ces dépendances. Parfois, vous rencontrerez des problèmes de connectivité ou d’authentification inattendus auxquels vous serez bien servi pour les identifier et les résoudre à l’avance.
Toutefois, la tâche la plus critique (et fastidieuse) consiste à identifier tous ces points d’intégration. Etant donné que les applications plus anciennes peuvent être mal documentées et que les développeurs connaissent l’intégralité des détails fonctionnels et non fonctionnels qui peuvent ne plus être disponibles, vous devrez peut-être passer par analyser chaque module manuellement. La tâche est compliquée si vous envisagez de migrer des centaines d’applications actuellement en cours d’exécution dans votre centre de données.
Beaucoup de ces problèmes peuvent être résolus grâce à une combinaison de la familiarité de votre équipe avec les applications et un outil de découverte d’actifs (que ce soit open source ou commercial). Un outil de découverte d’actifs peut vous aider à identifier les configurations entières de serveurs dans un réseau, ainsi que les détails de connectivité. Disons que vous disposez d’un centre de données dans un réseau hébergeant une centaine d’applications, un outil de découverte peut vous offrir une vue de l’ensemble du système. Il peut également fournir des détails précis qui peuvent être utiles pour une évaluation générale de la gestion de la capacité. Certains des outils de découverte d’actifs les plus connus incluent BMC Atrium et HP DDMA.
3. Le système d’exploitation de l’hébergeur
Une fois que vous avez décidé de migrer vos ressources vers le cloud, il est également très important de savoir si vous pourrez déployer vos applications sur le système d’exploitation de l’hôte. Il se peut qu’elles ne peuvent être exécutées que sur un système d’exploitation spécifique (ou une version d’OS). Si ce dernier n’est pas compatible avec celui de votre fournisseur de cloud, il faut le remplacer par un système d’exploitation OS fonctionnel, chercher un fournisseur de cloud différent ou tout simplement renoncer à l’ensemble du projet.
Par exemple, la plupart des fournisseurs de cloud ne proposent pas des systèmes d’exploitation en version 32-bits et d’autres peuvent avoir des exigences d’abonnement inattendues. Alors, il est préférable de bien faire vos recherches à l’avance.
4. La base de données de l’application
Une base de données est évidemment un élément essentiel de toute application. En effet, les clients investissent beaucoup sur les serveurs de base de données et, parfois, sur les licences. Souvent, ils préfèrent donc tirer profit de leur investissement dans la mesure du possible.
En outre, compte tenu de la complexité et de la sensibilité des données, ces clients ne veulent pas les déplacer maintenant. Sachant que la migration des petaoctets de données n’est pas un engagement à prendre à la légère.
Dans ces deux cas, il faut s’assurer que les méthodes de migration utilisées sont hautement fiables et offrent la possibilité de retournement pour faire face à un chaos inattendu. Plusieurs fournisseurs de cloud proposent leurs propres services de migration. Il est donc conseillé de bien évaluer ces services avant de pousser le bouton « Démarrer ». Il existe également de nombreux fournisseurs tiers offrant des services de migration de données tels que Attunity CloudBeam.
5. Le réseau
La pluplart des environnements cloud ne prennent pas en charge la multidiffusion. Alors, il faut bien réfléchir si votre application repose sur celle-ci.
Comparaison des coûts
De nombreux fournisseurs de cloud ont des calculateurs de prix servant à estimer les coûts réels de la migration vers le cloud par rapport aux coûts actuels. Par exemple, la calculatrice TCO d’AWS et le Pricing Calculator d’Azure.
POC (Preuve de concept)
C’est toujours une excellente idée de créer un POC avant de migrer une charge de travail vers le cloud. Ceci ne prévoit pas tous les problèmes possibles, mais il peut donner une meilleure clarté et compréhension des migrations vers le cloud et des défis auxquels celles-ci peuvent être confrontées. En effet, ce POC doit contenir :
- Les comparaisons de performances avec votre application existante.
- Les niveaux de complexité impliqués dans la migration de l’application.
- Les problèmes du réseau qui doivent être résolus.
- La fiabilité.
- L’évaluation du soutien du fournisseur cloud.