Ces géants du Web qui passent au Cloud 2.0

fmillot        07/05/2015 à 20:47      Les infrastructures convergées

Micro-services et containers sont aujourd'hui considérés comme l'architecture applicative du futur. Les grands sites Internet déploient les uns après les autres ces nouvelles technologies.

Les architectures SOA avaient montré la voie. Il s'agissait alors de découper les applications en services, baptisés web services. L'architecture a été adoptée par les éditeurs de progiciels, mais pour le Web, SOA s'est avéré inadapté et n'allait pas assez loin. Pour réellement pouvoir monter en charge, faire face à des pics de trafic de plusieurs dizaines de millions d'internautes, les géants du web ont créé les micro-services. Des services de plus petite taille, facilement instanciables en milliers d'exemplaires au besoin. Une architecture totalement dédiée à la haute disponibilité et conçue pour faire face aux montées en charge. Tout y est dynamique et massivement redondant, non seulement les composants applicatifs mais aussi les nœuds de stockage. Pour Eric Brewer, vice-président infrastructures de Google, les micro-services représentent l'architecture faite pour le cloud, la première architecture "Cloud Native".

La révolution des containers

Mieux, il devient possible de développer les composants sans obliger tous les développeurs à utiliser les mêmes langages. Une approche "polyglotte" qui devient de plus en plus fréquente : on choisit le meilleur langage pour développer tel ou tel service, chaque équipe peut être indépendante et mener ses développements sans remettre en cause l'architecture générale.

La technologie des containers a rendu possible le déploiement de telles architectures, mais il faut lourdement investir pour mettre en place ce type d'architecture. C'est le prix à payer. Un investissement qui ne porte pas sur l'achat de licences logicielles car dans cet écosystème tout est open source, mais sur les hommes et le temps permettant de maitriser puis déployer en production les nombreuses briques d'infrastructure que nécessite la mise en place ces architectures Cloud 2.0. Le prix à payer pour faire partie des géants d'Internet.

Google travaille sur la notion de containers depuis une dizaine d'années. C'est ce qu'a indiqué Eric Brewer, vice-président de l'infrastructure du groupe américain, en 2014 - lors de la conférence DockerCon. Le californien s'est intéressé au concept afin d'exploiter au mieux les infrastructures que se partagent ses différents services, notamment pour son moteur de recherche et ses traitements batch comme MapReduce. 

Google a annoncé son basculement sur Docker

L'américain a développé sa propre technologie de container, une solution baptisée non sans un certain humour LMCTFY (pour "Let Me Contain That For You"). La solution est publiée en open source et actuellement, la plateforme de production Google génère avec elle 2 milliards de containers chaque semaine. Google travaille sur une notion de groupes de containers, les pods. Chaque pod dispose de sa propre adresse IP. Les ingénieurs peuvent ainsi déplacer un groupe logique de containers en une seule manipulation, en cas de problème sur une machine par exemple.

Pour gérer ses containers et ses pods, Google a développé Kubernetes, une solution elle-aussi publiée en open source, ainsi qu'un petit outil, cAdvisor, qui permet de générer des statistiques d'utilisation de chaque container et éventuellement d'envoyer des alertes.

Aujourd'hui, Google standardise sa plateforme sur les containers Docker, privilégiant les standards ouverts du marché. Google a ainsi annoncé vouloir porter les fonctionnalités spécifiques de LMCTFY sur Docker, et standardiser ses développements de micro-services sur son langage "maison" : Go.

Twitter est bien connu pour avoir été développé à l'origine en langage Ruby. C'est vrai pour ses frontaux, pour le site web lui-même, mais son back office s'appuie désormais sur le langage Scala. Celui-ci s'exécute sur des machines virtuelles Java containérisées, et a aujourd'hui évolué vers une architecture de type micro-services.

Aurora pour contrôler l'architecture de micro-services

Pour gérer cette architecture en micro-services, Twitter utilise le système de gestion de cluster Apache Mesos. Ce fut le premier déploiement de Mesos sur une infrastructure de cette taille. Une solution à laquelle les ingénieurs de Twitter ont ajouté l'intelligence du framework Aurora. C'est cette couche open source qui s'assure que toutes les tâches de fond nécessaire au service Twitter fonctionnent correctement. En cas de panne sur une machine ou un cluster de machines, Aurora va redistribuer la tâche pour que Twitter ne tombe pas.

En termes de bases de données, les équipes de Twitter ont préféré développer leur propre base NoSQL à partir de Cassandra. Cette nouvelle base de données, Manhattan, a été créée pour présenter les plus faibles temps de latence face à la sollicitation des applications, tout en assurant la haute disponibilité et la capacité de montée en charge requises par ce type de service.

Entreprise 100% cloud, Netflix s'est doté d'une plateforme d'exploitation à base d'images Amazon Web Services exécutant des containers Docker. Netflix est probablement, avec Google et Amazon, l'entreprise qui est allée le plus loin dans le concept de micro-services. Pour mettre en place son architecture, l'américain a développé toute une série de briques logicielles, qui ont depuis étaient pour l'essentiel reversées en open source. Ses ingénieurs en ont ainsi publié plus d'une cinquantaine dans le cadre de ce que Netflix a baptisé le Netflix OSS (pour Open Source Software Center). 

Netflix a totalement "containerisé" le stockage

Parmi les briques les plus importantes de cette architecture, on compte Edda et Archaius pour la gestion de configuration, Zuul pour le routage des données entre micro-services, ou encore Eureka. C'est le service de découverte et de gestion des micro-services sur la plateforme de production. Une fonction clé sachant que Netflix loue en moyenne en permanence des dizaines de milliers de machines virtuelles auprès d'Amazon Web Services. Cette fonction de supervision est complétée par le framework Ribbon qui assure l'équilibrage de charge entre micro-services.

Enfin, Netflix a totalement "containerisé" le volet stockage de son site. Retirer un nœud de stockage Cassandra dans son architecture n'a aucune incidence sur la production. Le nœud est immédiatement régénéré. Ici, la force des architectures à base de micro-services s'affiche tant du côté des nœuds de calcul que de celui du stockage.

Comme beaucoup des grands services Internet actuels, Groupon a démarré petit, avec une architecture simple, qualifiée de "monolithique". Un serveur web Nginx (en load balancing), des développements Ruby on Rails pour le service, et une base de données MySQL pour stocker les informations.

Une architecture qui a rapidement dû être découpée pour tenir la charge engendrée par le succès du site de couponing aux Etats-Unis, puis en Europe. Les ingénieurs de Groupon ont commencé par s'appuyer sur un réseau de diffusion de contenu (CDN) pour soulager les serveurs, puis ont scindé la base de données en de multiples serveurs puis les applicatifs. 

L'intégration continue déjà sous Docker

Depuis, Groupon a totalement redéveloppé ses applicatifs, passant de Ruby on Rails et Java à Node.js. D'une application unique, le site compte une vingtaine de composants aujourd'hui.

Groupon a aussi annoncé sa volonté de basculer sa plateforme de production sous containers Docker. Sa chaine d'intégration continue a déjà été containérisée. Dans la foulée de ce projet, ses ingénieurs ont publié en open source DotCi, un plugin pour l'outil de déploiement continu Jenkins qui permet la création d'un environnement de Build en quelques minutes.

Avec plus de 40 millions d'utilisateurs, Spotify s'est tourné vers une architecture constituée de micro-services pour assurer sa croissance. Plus d'une centaine de services ont été développés par ses développeurs, essentiellement en Java et Python. Ceux-ci s'exécutent sur plus de 5 000 serveurs de production répartis sur 4 sites, auxquels viennent s'ajouter des machines virtuelles sur le cloud Amazon Web Services.

Helios pour orchestrer les containers

Après avoir réalisé ses déploiements avec l'outil Puppet pour gérer ses configurations et SSH, le finlandais a créé un outil d'automatisation des déploiements ("Deployify"), puis s'est finalement tourné vers Docker pour faire face à l'inflation du nombre de serveurs dans ses data centers. Pour automatiser un peu plus les déploiements, les ingénieurs de Spotify utilisent la plateforme d'orchestration Helios. Un serveur maitre contrôle l'ensemble via un agent installé dans chaque container. Les configurations des machines sont gérées avec Apache Zookeeper.

Poids lourd du e-commerce mondial, eBay a évolué d'un site crée en Perl, vers le C++, puis vers une plateforme que les développeurs qualifient aujourd'hui de "polyglotte". Celle-ci met en œuvre des composants Java, C++ ; Node.js, Python ou encore Scala. Elle s'appuie sur des plateformes Linux, Ubuntu et Red Hat Enterprise Linux (RHEL).

Docker pour automatiser les déploiements

Dans sa stratégie DevOps, eBay avait pour philosophie de mettre en place un serveur Jenkins pour chaque nouveau projet, avec pour conséquence d'avoir des milliers de machines virtuelles utilisées à moins de 5% la plupart du temps.

Les ingénieurs d'eBay ont revu leur approche afin de mettre en place une architecture dédiée à l'intégration continue qui soit plus efficiente. Ceux-ci se sont tourné vers trois briques open source en complément de Jenkins : Apache Mesos pour gérer le cluster de serveurs utilisés par les développeurs, Marathon pour gérer les instances Jenkins, et enfin Docker pour automatiser les déploiements.

Gilt, leader américain des ventes privées, a repris des recettes proches de celles employées par Twitter pour sa plateforme. Celle-ci s'appuie sur des containers Docker déployés sur la plateforme Amazon Web Services : une architecture Cloud conçue pour faire face au pic de trafic qui ont lieu lors des ventes flash.

De multiples bases de données en containers

Les développements sont menés essentiellement en langage Scala et en Ruby. Point étonnant : les architectes de Gilt ont profité de l'isolation des micro-services non pas pour utiliser de multiples langages, mais pour libérer leurs choix en matière de bases de données. Gilt met ainsi en œuvre MongoDB, PostgreSQL, NoSQL Voldemort et Cassandra dans ce que les ingénieurs appelles des micro-DBS.

Chez Gilt, l'accent est mis sur la rapidité des développements. Pour cela, les ingénieurs du cybermarchand ont développé Ion- Cannon, une plateforme dédiée au processus d'intégration continue. Plus de 400 micro-services ont été aujourd'hui déployés sur la plateforme Gilt.

Sources de ce document sur ce lien