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.

La capacité de « soulever et déplacer » une architecture, par opposition à la simple application, est l’une des raisons de la popularité croissante d’une option de cloud colocalisé. Il existe également des arguments en faveur des économies de coûts par rapport au sur site et d'un meilleur contrôle que dans le cloud, mais l'une des caractéristiques les plus attrayantes d'une option de cloud colocalisé est certainement la possibilité de soulever et de déplacer une architecture entière et de profiter du « cloud d'à côté ». Parfois, les organisations souhaitent rapprocher la source de données des applications déployées dans le cloud pour éviter la latence néfaste pour les performances nécessaire pour revenir jusqu'au centre de données de l'entreprise. Parfois, l’entreprise souhaite pouvoir faire évoluer le front-end sans perturber le back-end (et encore une fois, éviter la latence). Passer à un fournisseur de cloud colocalisé signifie qu'ils peuvent le faire, car le cloud est là, via une interconnexion très rapide de qualité centre 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