This post is sponsored by VMware. Learn about VMware virtualization and cloud solutions for small & mid-size business visit info.vmware.com



This article is available in other languages:

This article is available in other languages:

Germany Avantages dun système hybride cloud/virtualizationFrance Avantages dun système hybride cloud/virtualizationChina Avantages dun système hybride cloud/virtualizationNetherlands Avantages dun système hybride cloud/virtualizationEngland Avantages dun système hybride cloud/virtualizationPortugal Avantages dun système hybride cloud/virtualization

Dans notre dernier billet, j’ai évoqué certaines différences entre une application qui tourne sur une solution d’hébergement dans un cloud public, et la création d’un cloud privé pour y faire tourner l’application. J’ai aussi expliqué comment choisir entre les deux.

Aujourd’hui, je voudrais vous dire qu’on n’est pas forcément obligé de choisir. Quand j’ai expliqué comment choisir votre environnement d’hébergement, j’ai laissé de côté une hypothèse centrale, ce qui permettait d’en faire une alternative binaire : en réalité, la totalité de votre application a un ensemble hétérogène de performances, de disponibilité et de contraintes budgétaires.

C’est une hypothèse facile à faire, puisqu’en général, la plupart des applications sont développées de façon monolithique, avec une seule base de code, un seul environnement de développement standard, et enfin, un seul déploiement de production. En scindant votre application monolithique en composantes plus petites, vous êtes maintenant libre d’héberger chacune des composantes dans un environnement qui convient idéalement à ses contraintes particulières.

Architecture orientée service ou ressource

Quand on parle de ce processus qui consiste à scinder une application, on parle en général d’Architecture orientée service (Service Oriented Architecture, SOA) ou d’Architecture orientée ressource (Resource Oriented Architecture, ROA). Pour savoir quel nom utiliser, cela dépend de la manière dont vous découpez votre application, et pour l’instant, cela ne nous intéresse pas vraiment.

Dans cet article, je parle des avantages et des inconvénients de la SOA en ce qui concerne spécifiquement l’hébergement. La portée d’une évolution vers la SOA dépasse largement le cadre de cet article, et je vous recommande vivement d’en lire beaucoup plus sur le sujet avant de vous y engager.

Un exemple précis

Dans le dernier article, j’ai utilisé l’exemple du marché de contenus numériques, et de la manière de le faire passer du cloud à un environnement privé virtualisé, essentiellement parce qu’on voulait une performance accrue et plus de contrôle.

Avec le temps, alors que nous ouvrions de nouveaux marchés, le profil de charge de l’application a radicalement changé. Nous avions toujours le même flux stable de clients d’e-commerce qui exigeaient un service rapide. Mais avec chaque nouveau marché, de nouveaux types de fichiers était transférés, avec à chaque fois des besoins différents en post-traitement, et ceux-ci arrivaient lors de périodes très sporadiques.

À ce moment, notre environnement de production était trop occupé à « tout faire pour tout le monde ». Si on considérait que l’application était d’abord conçue pour faciliter autant que possible les achats, il était toujours recevable d’héberger notre application sur notre cloud privé. Cependant, si on considérait qu’elle était d’abord une plateforme pour que les gens y apportent du contenu (ensuite disponible à la vente) à grande échelle, mais avec un modèle de charge très imprévisible, alors la nature élastique du cloud public correspondait mieux à cette application.

Scinder l’application en deux

En raison du coût d’entretien d’une capacité de marge suffisante (pour prendre en charge les gros influx de nouveau contenu) et de l’augmentation de la complexité d’entretien du stockage de fichiers (pour tout contenir), nous avons scindé l’application et migré 100 % du stockage et du traitement des ressources dans le cloud.

L’environnement de production principal conserverait le contenu transféré assez longtemps pour le faire passer dans le stockage du cloud, et notifier le service de traitement des nouvelles ressources que du nouveau contenu était disponible. Le service des ressources ferait tout le nécessaire sur le fichier (validation, transformation, publication sur le CDN, etc.) puis notifierait le site principal que le contenu était prêt à être utilisé.

Avantages

Le premier gros avantage fut sur les profits. En réduisant la quantité de capacité de marge nécessaire dans notre cloud privé, et en faisant passer le travail sur le cloud public (où nous pouvions ajouter ou retirer des capacités en fonction des besoins), nous dépensions moins pour accomplir plus de « travail ».

Le deuxième fut la réduction de la complexité dans l’environnement principal. L’environnement principal était désormais consacré à 100 % au traitement du site, et comprenait moins d’éléments disparates à entretenir. La performance était au départ l’une des motivations principales dans le choix du cloud privé. La simplification de cet environnement nous a permis de réduire le nombre des goulots d’étranglement potentiels, et la gestion des problèmes au fur et à mesure est devenue bien plus simple.

Enfin, cela a simplifié le maintien d’une haute disponibilité pour nos clients. En préservant une séparation stricte entre le site et la gestion des ressources, il est devenu beaucoup moins probable que des problèmes de notre système de ressources affectent le site en aval.

Inconvénients

Malheureusement, tous les avantages ne sont pas gratuits.

Le premier inconvénient, c’est qu’en ayant différents composants dans différents datacenters, ou même dans le même datacenter (certains prestataires offrent à la fois des hébergements physiques et dans le cloud), on va introduire une latence dans le système général, et celle-ci va être très variable.

Il vous faudra consacrer une quantité non-négligeable d’efforts de développement pour que toutes les interactions entre les deux systèmes soient asynchrones et tolèrent les pannes. Entre les deux systèmes, il y a maintenant beaucoup de matériel réseau qui est hors de contrôle. Des paquets arriveront en retard, ou pas du tout. Si le site ne fonctionne que si l’autre service retourne rapidement les données, il va cesser de fonctionner.

Il y a aussi la question de la sécurité, puisque vos communications système qui étaient auparavant « internes » vont désormais passer par le grand méchant Internet. C’est une bonne chose de configurer un VPN ou bien, si vos communications inter-services se font via le protocole HTTP, de vous assurer que tous vos services disposent d’une authentification solide, et tournent en SSL.

Enfin, la complexité du développement et du déploiement augmente lorsqu’on passe d’une seule application monolithique à des services multiples hébergés indépendamment. À chaque fois que vous ajouterez de nouvelles fonctionnalités, il faudra faire preuve de coordination pour s’assurer que tous les services continuent à fonctionner ensemble.

Conclusion

Si vous avez du mal à savoir si votre application a besoin d’un cloud public ou privé, la réponse, c’est peut-être qu’elle a besoin des deux.

Observez attentivement votre application. Peut-être y a-t-il deux (ou plus) applications plus petites qui ne demandent qu’à être séparées, et lorsqu’elles le seront, il sera bien plus facile de trouver le bon environnement d’hébergement.