Pour réussir votre migration vers le cloud, concentrez-vous sur l'architecture

Deux modèles distincts de « passage au cloud » ont émergé. La première, la plus évidente, est l’approche native. Natif signifiant nouveau, soit vierge, soit réécrit. L’approche native encourage une concentration étroite sur l’application, l’hypothèse étant que lorsqu’elle est adaptée au cloud, les performances et la sécurité deviennent une question de provisionnement des bons services dans le cloud. Ce n’est pas entièrement vrai, mais c’est suffisamment proche pour que nous nous en tenions à cela pour l’instant.

La deuxième approche est celle du « lift and shift », qui se concentre exactement sur ce que son nom indique : soulever une application existante de sa base de centre de données et la déplacer vers le cloud, où elle est placée sur une base cloud. Mais dans ce modèle, l’accent ne peut pas être mis uniquement sur l’application, car l’application a également des dépendances qui doivent être traitées. Cela inclut d’autres composants architecturaux qui couvrent les services d’application et d’infrastructure. 

Cela a été récemment mis en évidence dans un rapport Cloud Velox , mettant l’accent sur l’exploitation du cloud comme centre de données secondaire. Il est intéressant de noter cette constatation :

Jusqu’à présent, Cloud Velox se concentrait sur la reprise après sinistre, mais il semble que le problème général soit plus largement applicable. Le transfert et le déplacement des applications vers le cloud sont beaucoup plus acceptables si vous pouvez également transférer et déplacer les contrôles de réseau et de sécurité (services) en même temps.

Fondamentalement, si vous déplacez une application qui a été optimisée au fil des années à l’aide de services d’application hébergés sur le réseau sans ces services d’application, vous perdez ces optimisations. Oh, il existe cette croyance erronée selon laquelle le simple fait d’être là-bas, dans le cloud, offre un gain de performances car on est physiquement plus proche de la dorsale Internet et des utilisateurs qui interagissent avec elle, et c’est en partie vrai, mais pas entièrement. C’est parce qu’une grande partie des performances d’une application ne sont pas dictées par la latence du réseau. En réalité, la plupart des inefficacités d’une application qui entraînent de mauvaises performances sont liées à la taille et à la composition du contenu, à une mauvaise gestion des connexions et à l’incapacité d’ajuster correctement la pile réseau pour répondre aux besoins spécifiques de l’application.

Les problèmes de sécurité ne disparaissent pas non plus soudainement lorsque vous déplacez une application vers le cloud. Si l’application était vulnérable aux XSS ou SQLi dans le centre de données, vous pouvez parier qu’elle est toujours vulnérable lorsque vous la transférez vers le cloud*.  Si ces préoccupations étaient traitées dans le centre de données avec un pare-feu d’application Web ou des artefacts de sécurité déployés sur un proxy programmable, il serait alors préférable de lever le pare-feu d’application et le proxy et de les déplacer avec l’application.

Vous pouvez « déplacer » une architecture entière, et pas seulement l’application, ce qui explique en partie le succès grandissant du cloud colocalisé. Vous économisez aussi par rapport à une infrastructure sur site, tout en conservant un meilleur contrôle que dans le cloud classique. Mais ce qui rend vraiment attrayante l’option cloud colocalisé, c’est la capacité à déplacer une architecture complète et profiter d’un « cloud à côté ». Parfois, vous souhaitez rapprocher la source de données des applications cloud pour éviter la latence qui tue les performances quand il faut revenir jusqu’au centre de données de l’entreprise. Parfois, votre entreprise veut étendre le front-end sans interrompre le back-end (pour réduire encore la latence). Opter pour un fournisseur cloud colocalisé signifie que vous pouvez faire cela, car le cloud est juste là, connecté par une interconnexion très rapide, compatible avec les standards des centres de données.

Quelle que soit l’approche du cloud (co-lo ou public), la clé d’un transfert réussi vers le cloud est de transférer et de déplacer autant d’éléments d’architecture que possible. Quelles que soient les options de services cloud, il est important de conserver les services d’application critiques avec son application tout au long de sa transition pour garantir que les performances et la sécurité ne soient pas compromises par la relocalisation. 

* Également appelée loi de Hoff qui, bien que n'étant pas vraiment une loi, reste une observation aussi précise aujourd'hui que lorsqu'elle a été observée pour la première fois en 2009