Voxxed Days Microservices est un événement centré exclusivement sur les Microservices. Durant cette seconde édition, deux jours de conférences et un jour d’atelier (en option) auront lieu à Paris du 21 au 23 octobre 2019.
Les lecteurs d'InfoQ peuvent profiter d'une promo de 20% avec le code VXDMS19_COM_INFOQFR lors de l'inscription.
InfoQ s'est entretenu avec Guillaume Laforge au sujet de sa session intitulée "Cloud run, serverless containers in action".
Bonjour Guillaume, dis-nous qui tu es et qu'est-ce qui t'a conduit vers les microservices ?
Bonjour, je suis Guillaume Laforge, je suis un developer advocate pour Google Cloud Platform. Je me concentre sur les produits serverless tels que Google App Engine, Cloud Functions et Cloud Run. De plus, je suis également Java Champion après des années de travail avec Java et de co-création du langage de programmation Apache Groovy. Et je suis également l'un des co-animateurs du podcast technologique français Les Cast Codeurs.
Ainsi, après des années de consultance sur de grands projets monolithiques, allant parfois vers la communication de macro-services, je suis devenu de plus en plus convaincu que des services plus petits, centrés sur leurs propres tâches, avaient plus de sens. Cependant, ce n'est pas sans problèmes, car il peut également être plus difficile de faire travailler ensemble des dizaines de microservices, de les construire et de les déployer indépendamment, etc. C'est donc un moment intéressant dans l'histoire de notre architecture logicielle pour voir quelles sont les best practices et l'évolution des outils pour accompagner cette nouvelle ère.
De quoi parles-tu à Voxxed Days Microservices ?
Je vais parler de Cloud Run, un nouveau produit de Google Cloud, qui permet d'exécuter des conteneurs de manière «serverless», sur une infrastructure gérée (nul besoin de provisionner des instances, des serveurs, des clusters, des correctifs de sécurité appliqués de manière transparente, etc. .), où l'autoscaling vous permet de redimensionner vos microservices jusqu'à zéro (en payant également 0), jusqu'à plusieurs centaines voire plus lorsque votre service est fortement utilisé. Cloud Run s'exécute également sur Google Kubernetes Engine ou sur tout cluster Kubernetes sur lequel le projet Open Source Knative est installé, car la technologie Cloud Run s'appuie sur les API Knative.
Ici, je mets en exergue les mots à la mode «serverless» et «conteneurs», mais quelle est la relation avec les Microservices, qui est le thème de la conférence. Je pense que les conteneurs serverless constituent l'un des moyens les plus simples et les meilleurs d'exploiter vos microservices dans le Cloud. C'est pourquoi je me concentre sur cette pile de technologies. Vous n'avez pas nécessairement besoin d'être un expert de haut niveau sur Kubernetes pour pouvoir profiter des avantages des conteneurs pour vos microservices.
Le terme «serverless» est de plus en plus confus, car les fournisseurs de services cloud présentent des caractéristiques serverless (infrastructure gérée, capacités d'auto-scaling, paiement en fonction de l'utilisation, etc.). Cloud, conteneurs, serverless… Ne parlons-nous pas des mêmes choses ici ? Quelles sont tes définitions ?
Les microservices sont un style architectural dans lequel nous décomposons une application globale en composants plus petits communicants qui se concentrent sur une tâche clé. Nous n'avons pas toujours besoin de tout scinder en petits microservices, et c'est probablement un anti-modèle de se lancer tête baissée dans une architecture basée sur les microservices, quand un bon vieux monolithe pourrait bien faire le job.
Serverless indique certaines caractéristiques de certains produits.
Comme tu l'as dit, il s'agit généralement d'une infrastructure gérée, dans laquelle les développeurs n'ont pas besoin de provisionner des serveurs ou des clusters avant de pouvoir déployer quoi que ce soit, mais plutôt de déployer directement sur cette infrastructure avec certains outils (interfaces en ligne de commandes, CI / Plates-formes de CD, consoles graphiques…). Un autre aspect important de cette infrastructure gérée est que le fournisseur de cette infrastructure (qu'il s'agisse d'un fournisseur Cloud ou d'une équipe informatique sur site) s'occupe des couches sous-jacentes : application de correctifs de sécurité au système d'exploitation, par exemple.
La capacité d'auto-scaling et le paiement à l'utilisation vont généralement de pair, mais ce n'est pas obligatoire, car nous pourrions imaginer payer à l'utilisation avec des outils qui ne seraient pas serverless et nécessiteraient une infrastructure provisionnée, ou nous pourrions imaginez un produit qui demande des frais d'utilisation même si le fournisseur ne fournit pas les serveurs ou les clusters pour vos applications.
Si votre service coûte 1 euro pour fonctionner et que vous avez besoin de deux fois plus de capacité, vous payez généralement deux fois plus, c'est-à-dire proportionnellement à votre utilisation. Mais il est également intéressant d'avoir la possibilité de passer du scale-to-zero, où votre service ne fonctionne pas (plus aucun serveur n'est approvisionné et aucun ne s'exécute) et le coût est également ramené à zéro. Cela est important pour les charges de travail qui ne s'exécutent pas nécessairement 100% du temps : par exemple, pensez aux rapports mensuels ou trimestriels, ou à toute tâche exécutée à un intervalle de temps régulier, mais ne recevant pas nécessairement un flux quotidien de demandes entrantes.
Bon, à bientôt alors
Je suis vraiment impatient de rencontrer les conférenciers et les participants à la conférence pour entamer des discussions fructueuses sur les microservices, comprendre les besoins des startups et des entreprises en matière de microservices et de solutions serverless.
Mes coordonnées
Twitter : https://twitter.com/glaforge
Blog : http://glaforge.appspot.com/
LinkedIn : https://www.linkedin.com/in/glaforge/
GitHub : https://github.com/glaforge