La plate-forme en tant que service (PaaS) a été l’un des premiers modèles de fourniture de cloud public. Lorsque l’infrastructure en tant que service (IaaS) donnait le contrôle aux administrateurs, PaaS s’adressait directement aux développeurs grâce à sa simplicité, sa productivité et son évolutivité.

En 2008, Google a lancé App Engine, une plate-forme qui permet aux développeurs de déployer et de mettre à l’échelle des applications Web Java. Amazon a ajouté Elastic Beanstalk à son infrastructure informatique en tant qu’offre PaaS en 2012. Windows Azure, le premier avatar de cloud public de Microsoft, était tout au sujet de PaaS. Ce n’est qu’en 2013 qu’Azure a reçu la prise en charge des machines virtuelles Linux et Windows pour fournir un IaaS complet.

Au cours de la dernière décennie, le PaaS a augmenté sous la forme de Fonderie de nuages, Heroku, Parc de machines, et Red Hat OpenShift.

La principale promesse faite par PaaS était la possibilité d’apporter du code source et d’utiliser une URL pointant vers l’application. Les développeurs n’ont jamais eu à se soucier de fournir l’infrastructure, d’installer le système d’exploitation ou de configurer et sécuriser l’infrastructure. Vous venez de «pousser» le code et de quitter le reste de la plate-forme.

PaaS élargirait et réduirait automatiquement l’application sans intervention manuelle. Cette approche a libéré les développeurs de la gestion des opérations quotidiennes et leur a donné plus de temps pour se concentrer sur le code plutôt que sur l’infrastructure. Le PaaS a abouti à une intégration et une livraison continues (CI / CD) qui sont devenues la norme aujourd’hui. Les techniques de déploiement avancées telles que les déploiements bleu / vert, les changements de version et les versions canariennes ont été rendues possibles par PaaS.

La démocratisation des conteneurs gérés par Docker et l’essor de Kubernetes ont changé la dynamique des infrastructures et des plates-formes modernes. Les conteneurs sont rapidement devenus l’unité de base de la livraison, et Kubernetes est devenu l’orchestrateur pour la gestion de dizaines de milliers de conteneurs. Bientôt, les fournisseurs de cloud public ont commencé à proposer l’offre gérée de Kubernetes, Containers as a Service (CaaS), qui est devenue une alternative à IaaS et PaaS.

Alors que Kubernetes gagnait en popularité, PaaS a introduit Kubernetes pour permettre aux développeurs de réutiliser les blocs de construction – les conteneurs. App Engine Flex, Service d’application Azure, Fonderie de nuages et OpenShift peut exécuter des applications conteneurisées.

Red Hat a été l’une des premières sociétés de plates-formes à voir la puissance de Kubernetes, ce qui a permis à OpenShift de devenir une distribution Kubernetes entièrement conforme et conforme pour l’entreprise.

Contrairement à l’IaaS, où seuls les administrateurs et les opérateurs étaient censés créer et déployer des machines virtuelles, la conteneurisation a pris la responsabilité de l’empaquetage du code et de la création des images de conteneur pour les développeurs. Si l’application est déployée sur Kubernetes, les développeurs doivent également apprendre les blocs de construction du moteur d’orchestration pour empaqueter les images de conteneur dans des pods, les déployer, puis les exposer en tant que services.

Avec les conteneurs et Kubernetes, la frontière entre le développement et l’exploitation est complètement floue. Quelle que soit la personne – développeur ou opérateur – chaque membre de l’équipe doit tout savoir sur la gestion de l’infrastructure et du cycle de vie des applications.

Merci à eux Fondation Cloud Native Computing (CNCF) gère le projet open source et l’écosystème vivant Kubernetes normalisé pour exposer des API bien définies. La documentation et les ressources ont mis la technologie à la disposition d’un grand nombre de développeurs et d’opérateurs. Contrairement au PaaS, Kubernetes a apporté une clarté et une transparence extrêmes à la gestion du cycle de vie des applications.

Une chose que les développeurs manquent dans Kubernetes est la simplicité de PaaS. Examinons le flux de travail Cloud Foundry pour déployer une application.

Une fois que le développeur a testé l’application sur sa machine locale, il exécute simplement l’outil de ligne de commande pour déployer l’application et sa configuration. Dans les coulisses, Cloud Foundry s’occupe de tout, de la fourniture des ressources informatiques au démarrage ou à l’attribution de services supplémentaires tels que les bases de données et le cache, en passant par la transmission d’une URL de l’application au développeur.

Dans Kubernetes, tout commence par empaqueter le code dans une image de conteneur, qui est ensuite encapsulée dans un pod ou un objet de déploiement. Les services supplémentaires tels que les bases de données suivent le même flux de travail. Le développeur doit créer une carte de configuration et un secret afin que l’application Web puisse communiquer en toute sécurité avec la base de données. Afin de conserver les entrées de la base de données, elle doit également créer des volumes et des revendications de volume. Enfin, la base de données est mise à disposition en tant que service interne pour l’application Web, tandis que l’application accessible au public est connectée à un équilibreur de charge.

Comme vous pouvez le voir, le développeur travaille sur plus d’une douzaine d’objets Kubernetes pour configurer et déployer une simple application Web à deux niveaux.

Ce n’est pas seulement le processus de déploiement fastidieux et la courbe d’apprentissage abrupte, mais la vraie préoccupation est de savoir ce que le développeur doit comprendre avant de déployer une application. Dans un environnement IaaS ou PaaS traditionnel, une grande partie de cette tâche serait effectuée par les opérateurs.

Kubernetes ne fait pas de distinction claire entre les développeurs et les opérateurs. Quelle que soit la personne, chaque utilisateur doit connaître le fonctionnement interne du moteur d’orchestration.

L’écosystème cloud natif comprend clairement ce défi. Les fournisseurs de plates-formes ont adopté trois approches différentes pour ajouter des fonctionnalités de plate-forme à Kubernetes.

La première approche consiste à créer une plate-forme d’application open source basée sur Kubernetes. Red Hat est l’une des premières sociétés de plateforme à adopter cette stratégie. OpenShift, la plate-forme de conteneurs la plus populaire, a ajouté une gestion robuste du cycle de vie des applications à Kubernetes. Il imite le flux de travail PaaS via un générateur de conteneurs intégré, un registre d’images et un routeur d’applications.

Le deuxième mécanisme consiste à porter le PaaS existant sur Kubernetes tout en maintenant la compatibilité avec les outils et le flux de travail. Cloud Foundry pour Kubernetes est allé de cette façon pour rapprocher les développeurs du flux de travail PaaS bien connu.

La troisième approche crée une couche opaque au-dessus de Kubernetes qui cache complètement les bases du moteur d’orchestration. Render.com et Plateforme d’applications DigitalOcean sont des exemples de cette implémentation.

Cependant, chacune de ces approches a ses propres défis et limites. Red Hat OpenShift et son homologue communautaire, OKDsont trop difficiles à installer. Vous avez besoin d’au moins cinq ordinateurs pour exécuter une application Hello World de base sur OpenShift. Cloud Foundry est relativement nouveau pour les développeurs cloud natifs. Il a le potentiel de devenir la plate-forme de choix, mais il est trop tôt pour arriver à cette conclusion. Les implémentations commerciales PaaS telles que Render.com et DigitalOcean App Platform ne sont pas open source et portables.

Certaines des personnes clés derrière Kubernetes ont créé plusieurs blocs de construction qui facilitent la création d’une plate-forme. Google, IBM, VMware et Red Hat ont tous contribué Knative, un projet open source qui apporte la plate-forme sans serveur et basée sur les événements à Kubernetes. Microsoft y travaille Runtime de l’application distribuée (DAPR) et Mise à l’échelle automatique basée sur les événements de Kubernetes (KEDA) pour simplifier le développement, le déploiement et la mise à l’échelle des applications cloud natives.

Knative, Dapr et KEDA ne sont pas des implémentations PaaS complètes. Au lieu de cela, ils constituent la base de la création de plates-formes sur Kubernetes. Par example, Google Cloud Run, une plateforme de conteneurs sans serveur, est basée sur Knative. Cependant, Cloud Run n’est pas un projet open source exclusivement disponible pour Google Cloud.

Alors que la frontière entre le développement et les opérations devient floue, les développeurs natifs du cloud ont besoin d’une couche abstraite qui simplifie la gestion du cycle de vie des applications.

Il existe une possibilité claire de créer une plate-forme portable, cohérente et conviviale pour les développeurs pour Kubernetes. L’écosystème des développeurs a besoin d’un choix d’implémentations PaaS open source dans le cloud qui peuvent être installées dans n’importe quel cluster Kubernetes, y compris CaaS géré dans le cloud public ou dans Minikube fonctionnant sur un ordinateur portable.



Source link

Recent Posts