IaaS est génial jusqu'à ce qu'il ne le soit plus : le retour du PaaS

Les développeurs s'interrogent sur l'avenir de la plate-forme en tant que service (PaaS) et pour cause. Beaucoup d'entre eux ont créé des produits performants sur PaaS, mais lorsque leur application atteint une certaine échelle, ils en ont besoin de plus. Ils ne peuvent pas facilement déboguer les problèmes de performances en raison d'un manque de transparence et de fonctionnalités de boîte noire opiniâtres. Ils ne peuvent pas mettre en œuvre des contrôles de sécurité et de conformité entièrement configurables comme un pare-feu d'application Web. Ils sont coincés avec les modules complémentaires limités proposés par la plate-forme, s'ils sont même proposés. Des fonctionnalités telles que le stockage persistant, l'équilibrage de charge configurable et la mise à l'échelle automatique sont soit inexistantes, soit trop limitées pour une utilisation réelle sur PaaS.

Alors que font les développeurs ? Ils transfèrent leurs applications sur une infrastructure en tant que service (IaaS).

Ce n'est pas que IaaS est meilleur, mais qu'il n'a pas de limites de mise en œuvre. Les développeurs peuvent créer tout ce qu'ils veulent avec les fournisseurs IaaS. Le compromis en est un de temps, d'expertise et de personnel supplémentaire. Mais cela convient à la plupart des développeurs avec des applications PaaS réussies, car ils ont déjà traversé la partie difficile de la construction de quelque chose et de la recherche d'un produit adapté au marché. Ils ne sont pas aussi inquiets de la courbe d'apprentissage de la migration vers IaaS car à ce stade, ils ont une base d'utilisateurs, des revenus et une piste.

Il est probable que les développeurs ne porteraient pas leurs applications sur IaaS si PaaS était une option viable à grande échelle. Mais cela signifie-t-il que PaaS doit être considéré comme inférieur à IaaS ? À peine. L'avenir du PaaS est prometteur, bien plus prometteur que ne le pensent de nombreux développeurs. En fait, je pense que PaaS dominera l'avenir du développement logiciel. Le marché a soif d'une plate-forme « idéale pour démarrer, idéale pour évoluer » pour émerger et dépasser l'expérience et la valeur des développeurs d'aujourd'hui. Le PaaS prendra absolument en charge la livraison d'applications évolutives à l'échelle mondiale, mais il devra d'abord surmonter certains défis.

IaaS est génial jusqu'à ce qu'il ne le soit plus

La beauté de l'IaaS est qu'il offre des options de configuration et d'évolutivité presque infinies. Les fournisseurs d'IaaS ont suffisamment généralisé leurs produits pour prendre en charge pratiquement tous les cas d'utilisation à n'importe quelle échelle. Il est incroyablement puissant et rentable. De plus, les fournisseurs d'IaaS sont heureux d'accorder des crédits d'utilisation et des tarifs réduits pour favoriser l'adoption et rendre les équipes accros.

Cependant, il peut être extrêmement difficile de créer des configurations évolutives sans se tirer une balle dans le pied. Des changements de configuration incorrects peuvent avoir des résultats catastrophiques qu'il est presque impossible de dépanner et de corriger sans une expertise approfondie de l'infrastructure. Il n'y a pratiquement pas de support de plate-forme disponible (en dehors des engagements d'entreprise coûteux) et la documentation IaaS est notoirement incohérente et difficile à lire. Et ne me lancez même pas sur l'expérience utilisateur réelle des consoles IaaS.

Se lancer à fond dans l'IaaS signifie créer des équipes d'infrastructure coûteuses pour utiliser et gérer l'IaaS. Non seulement les experts en infrastructure font partie des personnes les plus demandées du secteur, mais il est extrêmement difficile de trouver les bonnes personnes qui savent comment répondre à des besoins de croissance uniques. À ces complications s'ajoutent les réalités d'un environnement de collecte de fonds plus serré, les équipes se voyant dire de « faire plus avec moins » et la complexité croissante des solutions IaaS. Le travail de l'équipe consiste à mettre en place et à entretenir l'infrastructure au fur et à mesure de sa croissance, et le travail n'est jamais « terminé ».

Le parcours typique des entreprises avec IaaS ressemble à ceci :

1. Embauchez 1 à 2 ingénieurs experts en back-end ou en infrastructure pour déterminer et mettre en œuvre l'architecture.
2. Développez l'équipe, faites l'expérience d'un certain roulement et l'architecture change de manière organique.
3. L'équipe qui maintient maintenant l'infrastructure n'est plus l'équipe qui l'a construite en premier lieu.
4. Quand quelque chose se brise, c'est un cauchemar à réparer. Personne ne se souvient pourquoi des décisions ont été prises, les connaissances tribales ont disparu et ce qui fonctionnait il y a des mois est maintenant un « héritage » parce que personne ne le comprend.

Entre les problèmes de financement et le manque de talents disponibles en matière d'infrastructure, il est difficile de recommander d'approfondir les investissements dans les travaux d'infrastructure et de plate-forme. Les fonctionnalités et capacités IaaS deviennent de plus en plus complexes, ce qui justifie davantage le besoin d'abstractions de niveau supérieur, tout comme celles fournies par PaaS.

IaaS souhaite pouvoir faire du PaaS

Les fournisseurs d'IaaS le savent, c'est pourquoi ils investissent dans des abstractions de type PaaS. Google fait du très bon travail dans ce domaine avec sa plate-forme cloud et Firebase , sa plate-forme de développement mobile. Amazon a essayé de créer des abstractions, mais leur expérience de développeur n'est… pas bonne. Néanmoins, il est clair qu'ils comprennent que les développeurs veulent (et méritent) de meilleures expériences, comme le chiffrement automatique des objets S3 et l'intégration RDS avec AWS Secrets Manager . Azure propose désormais App Service , qui permet un déploiement simplifié sur une infrastructure à mise à l'échelle automatique.

Les principaux fournisseurs de cloud s'améliorent dans les offres de type PaaS, mais ils se concentrent également sur les stratégies héritées de levage et de déplacement ou sur les fantasmes de science-fiction "Kubernetes sans serveur". Ils tirent la majeure partie de leur argent des entreprises, ce qui oriente le développement de leurs fonctionnalités vers davantage d'entreprises. Les startups et les entreprises de taille moyenne se croisent les doigts en espérant que leurs commentaires conduisent à des environnements de type PaaS plus faciles à utiliser et à construire qui ne nécessitent pas une expertise avancée en infrastructure pour être pleinement utilisés.

Raman Sharma a astucieusement observé qu'"au moins deux grands fournisseurs de cloud à grande échelle (Azure et GCP) ont commencé leur parcours cloud avec des produits PaaS, pour se rendre compte rapidement que l'argent réel (et des charges et des charges de muscle et de mémoire institutionnelle) était encore dans l'infrastructure . Donc, ils ont pivoté pour être centrés sur IaaS (comme AWS l'était à l'époque).

En d'autres termes, IaaS ferait PaaS si IaaS n'était pas si lucratif. Ils ne sont pas au service des startups, ils sont au service des entreprises.

IaaS n'est pas un avantage concurrentiel, c'est une distraction

La construction en IaaS offre beaucoup de liberté et d'opportunités, mais préféreriez-vous dépenser 150 000 $ pour un administrateur certifié AWS ou 150 000 $ pour un développeur capable de créer des fonctionnalités génératrices de revenus ?

Si vous n'avez pas à vous soucier de l'infrastructure, embaucher le développeur est une évidence. Malheureusement, il n'est pas rare que les entreprises obtiennent le pire des deux mondes : elles embauchent le développeur à 150 000 $ et l'obligent à faire également tout le travail DevOps. C'est beaucoup moins rentable.

Il n'y a vraiment aucun avantage concurrentiel pour les équipes produit qui passent du PaaS à l'IaaS, ni pour celles qui démarrent sur l'IaaS et évoluent. À un moment donné, il faudra inévitablement embaucher un architecte d'infrastructure cloud coûteux et expérimenté. Bien sûr, je n'ai rien contre les ingénieurs compétents en infrastructure cloud, mais lorsque je suis confronté à une pression financière croissante pour « faire plus avec moins », je ne suis pas très enthousiaste à l'idée d'augmenter mes frais généraux.

De plus, même si j'avais la meilleure équipe d'infrastructure cloud au monde et même si ce n'était pas aussi coûteux que je le craignais hypothétiquement, quel est l'avantage concurrentiel d'avoir cette équipe ? Quel avantage cela offre-t-il vraiment à une entreprise ? Pour être honnête, je préférerais de loin avoir une petite équipe de développeurs générant de la valeur plutôt que des administrateurs protégeant la valeur. Oui, je peux passer du temps et de l'énergie sur IaaS pour obtenir des disques persistants, une récupération ponctuelle sur mes bases de données, un équilibrage de charge configurable, une logique de déploiement bleu/vert et une mise à l'échelle automatique, mais je garantis que la plupart des développeurs préféreraient tout disponible avec une case à cocher dans une interface utilisateur bien conçue.

Plus je dois me concentrer sur le fait de garder les lumières allumées, moins je passe de temps à fournir des fonctionnalités exceptionnelles aux clients qui veulent dépenser de l'argent pour mes produits. Plus d'infrastructures, moins de valeur.

PaaS résout les problèmes d'IaaS

La principale raison pour laquelle PaaS existe en premier lieu est que IaaS est trop compliqué. Les développeurs veulent écrire et déployer du code. Ils veulent créer de nouvelles applications et fonctionnalités, voir comment le marché réagit et itérer. Et ils veulent le faire avec le moins d'obstacles possible.

Par exemple, si j'ai besoin d'une infrastructure conforme à la loi HIPAA pour créer un SaaS axé sur les soins de santé, je peux commencer par l'architecture de référence d'Amazon , qui est incomplète et complexe, et passer des semaines à la mettre en place et à l'exécuter. Ou, je peux créer une application sur Aptible en quelques minutes et savoir qu'elle est conforme à la loi HIPAA.

Il en va de même pour la conformité PCI. Stack Overflow et Reddit regorgent d'exemples et d'avertissements de la bataille difficile pour établir et maintenir une infrastructure conforme à la norme PCI dans l'un des grands clouds IaaS. Ou, vous pouvez trouver un PaaS conforme à la norme PCI et ne perdre aucun temps sur la configuration du pare-feu.

Voici le problème : personne ne choisit de commencer par une architecture et une mise en œuvre d'infrastructure complexes. Ils n'ont tout simplement pas beaucoup d'options ou ils ne sont pas conscients des choix existants. Tout développeur ou chef de produit choisirait le PaaS s'il était rentable et capable de répondre aux besoins d'évolutivité à long terme. PaaS n'a pas de problème de rentabilité, mais de se mettre dans le coin avec sa capacité à long terme à soutenir les entreprises en croissance. Si ce n'était pas le cas, PaaS serait une évidence pour démarrer et faire évoluer les applications.

Cela soulève la question : qui ne paierait pas une somme d'argent supplémentaire durable pour que tout « fonctionne correctement », une excellente documentation et un support intégré ?

PaaS doit résoudre ses propres problèmes

IaaS a fait un excellent travail en offrant une solution généralisée qui fonctionne dans tous les cas d'utilisation. Le PaaS n'en est pas encore là. Il y a trop de petites fonctionnalités manquantes et d'obfuscations qui poussent les équipes à quitter le PaaS. Il n'y a pas de PaaS unique capable de prendre en charge toutes les applications qu'une entreprise doit exécuter, et c'est un problème non négligeable.

De plus, les modèles de développement d'applications ont également évolué depuis que PaaS a commencé à prospérer en 2010. Heroku et ses semblables n'ont tout simplement pas suivi. Voici quelques-unes des « tâches à accomplir » courantes de l'équipe d'ingénierie qui sont essentielles à l'entreprise, mais qui ne sont pas couvertes par le PaaS :

• Stockage d'objets
• Calcul piloté par les événements (« sans serveur »)
• Entreposage de données
• Bases de données NoSQL et graphes
• Bases de données d'événements
• Bases de données de recherche

Les besoins sont clairement divers. Le monde PaaS a fait un excellent travail avec des plates-formes spécialisées qui se positionnent clairement comme les meilleures de leur catégorie pour une seule tâche, mais le monde a besoin d'un PaaS capable de prendre en charge un ensemble de fonctionnalités permettant aux entreprises.

Le PaaS doit prendre en charge des architectures d'applications plus diverses

Les applications PaaS ont tendance à être monolithiques afin de tirer parti des diverses capacités de la plate-forme d'infrastructure sous-jacente. Cependant, les produits en croissance devront probablement éventuellement se scinder en un ensemble de microservices dépendants.

À l'heure actuelle, les développeurs doivent passer par des contorsions pour qu'une architecture de microservices fonctionne correctement sur PaaS. Ils ont besoin de constructions telles que la découverte de services et la connectivité directe des conteneurs pour fonctionner efficacement. Celles-ci sont difficiles à trouver en tant que capacités natives dans le monde PaaS.

Il y a une dynamique problématique qui apparaît lorsque les applications deviennent plus complexes que le PaaS ne peut comprendre. C'est une des principales raisons pour lesquelles les développeurs passent à l'IaaS. Si un PaaS ne peut pas prendre en charge un entrepôt de données, il y a peu de raisons de garder quoi que ce soit d'autre déployé sur le PaaS.

Les utilisateurs IaaS aspirent à des abstractions de type PaaS

Une fois qu'une entreprise passe du PaaS à l'IaaS, paradoxalement, elle aspire à ce qui fait la grandeur du PaaS : une complexité réduite, une excellente expérience de développement, une excellente documentation et des coûts prévisibles. Lisez tous les rapports « State of DevOps » aujourd'hui et vous entendrez parler du mouvement « d'ingénierie de plate-forme » et de ses fondements philosophiques.

Mais les entreprises ne devraient pas avoir à réinventer la plateforme. C'est un coût majeur pour la productivité. Créer et faire évoluer une expérience de développeur de premier ordre est un travail suffisant pour devenir un secteur d'activité en soi. La construction d'abstractions sur IaaS aura probablement peu ou pas de retour sur investissement pour les entreprises en dehors du Fortune 50 (beaucoup moins pour leurs clients et actionnaires). C'est une proposition commerciale absurde.

PaaS a beaucoup de place pour se développer - et nous sommes optimistes

Le PaaS résout une grande partie des problèmes de l'IaaS :

• L'infrastructure est une distraction, pas un avantage concurrentiel
• Les entreprises et les équipes produit sont heureuses de payer pour que leurs gros problèmes soient résolus (ou externalisés vers une plateforme)
• Les performances, la croissance et l'échelle ne doivent pas nécessiter le stress de la construction, de l'exploitation et de la maintenance

Nous voyons une opportunité pour un SaaS à usage général qui ne met pas les développeurs dans un coin et nous sommes ravis. Nous prenons ce que nous avons déjà construit - le meilleur et le seul PaaS non Heroku qui s'adapte pour répondre aux besoins de l'entreprise - et le rendons plus facile et plus accessible pour commencer à créer des applications.

Voici comment nous nous attendons à ce que le marché réagisse (et comment nous l'abordons nous-mêmes) :

• Mise à l'échelle automatique et tarification simple : en dehors d'Heroku, il est difficile de définir des contraintes concernant la mise à l'échelle et les coûts PaaS. C'est le premier et le plus important domaine auquel les fournisseurs de PaaS doivent s'attaquer.
• Expérience de développeur et première expérience utilisateur : les fournisseurs de PaaS vont se concentrer sur l'aide aux développeurs pour créer et développer rapidement leurs applications. C'est là que la plupart des innovations ont été à ce jour - des efforts pour retrouver le sentiment de magie fourni par Heroku.
• Prise en charge des abstractions de développement modernes et de niveau supérieur : prise en charge des solutions d'infrastructure sans serveur tierces, des analyses opérationnelles, de l'IA, de la sécurité de la chaîne d'approvisionnement et des logiciels décentralisés.
• Réalisez des cas d'utilisation modernes : permettez aux entreprises d'effectuer des tâches d'ingénierie adjacentes telles que des sites Web statiques, le stockage d'objets, etc.

Alors qu'AWS et d'autres fournisseurs IaaS ajoutent de plus en plus de services à leur console, nous devons nous attendre à plus de complexité. Un nombre croissant de clients IaaS finiront par s'appuyer sur ce qui deviendra bientôt des architectures cloud et des paradigmes de développement hérités. Ces entreprises chercheront inévitablement un PaaS pour se libérer, ou même simplement pour éviter les complexités et les frustrations liées à la gestion de l'IaaS utilitaire.

Je terminerai en portant une attention particulière aux développeurs dans des équipes plus petites et relativement indépendantes au sein de grandes entreprises. Le mouvement "vous le construisez, vous l'exécutez" sera probablement un moteur pour une adoption accrue du PaaS. En fait, cela devient déjà "vous le construisez, vous l'exécutez, vous le sécurisez". Au fur et à mesure que les équipes de développement deviennent plus responsables de leur infrastructure, elles seront responsables de leur propre DevOps. Il n'y a pas beaucoup de choses qu'ils pourront gérer, donc le PaaS sera plus qu'attrayant. Le PaaS deviendra une nécessité.

Les gens peuvent être baissiers sur PaaS aujourd'hui, mais le jour viendra où ces équipes exigeront un véritable concurrent Heroku de niveau entreprise. Une plate-forme va tracer cette voie et elle se propagera plus rapidement que Heroku ne l'a jamais fait.

En 2023, Aptible montrera qu'il s'agit bien de cette plateforme.