L'histoire d'Upsun : l'évolution d'un PaaS

Upsun est la nouvelle offre de Platform.sh, basée sur l'architecture existante basée sur les conteneurs du PaaS Platform.sh qui est actif depuis près d'une décennie, gérant plusieurs milliers d'applications pour ses clients dans le monde entier. Upsun s'accompagne d'un modèle de tarification à l'usage entièrement revu, conçu pour offrir la flexibilité nécessaire aux projets d'architecture découplée et composable. Pour notre équipe, Upsun est le lancement le plus important de Platform.sh depuis la création de l'entreprise et nous sommes impatients de le partager avec vous.

Platform.sh : remédier à la peur du déploiement

Avant de nous plonger dans le produit PaaS Upsun, revenons un peu en arrière et jetons un coup d'œil sur le parcours de Platform.sh. Au tout début de Platform.sh, il y a environ 10 ans, le cloud et l'infrastructure applicative empêchaient toujours les développeurs de réaliser ce qu'ils voulaient. Pour faire face à la concurrence et aux attentes toujours plus grandes des clients, quel que soit l'objectif de votre application, il est primordial d'itérer rapidement. Mais si l'itération signifie interrompre la production plusieurs fois par semaine, on en vient rapidement à craindre de ne pas le faire du tout. Nous avons donc voulu résoudre ce problème : la peur du déploiement. Nous avons entrepris de rendre le cloud aussi simple et robuste que possible en nous concentrant sur ce cas d'utilisation précis avec Platform.sh : de grandes applications de commerce électronique avec des sites web CMS à fort trafic et à fort contenu.

L'un des plus grands défis, quelque peu spécifique à ces cas d'utilisation, est que vous avez besoin d'environnements de prévisualisation pour avoir des données non synthétiques afin de faire des tests robustes. Tester une application riche en contenu ou une solution de commerce électronique avec un catalogue d'un million d'articles et des milliers de paniers d'achat simultanés n'est pas la même chose que de la tester avec quelques articles. De même, tester un énorme site web au contenu complexe n'est pas la même chose que tester quelques pages de Lorem Ipsum.

Nous avons donc créé notre technologie de clonage de clusters qui nous permet de fournir des environnements de prévisualisation à la volée, qui sont des copies parfaites de la production, en quelques minutes seulement. Nous l'avons conçue de manière à ce qu'elle fonctionne exactement de la même manière sur n'importe quelle infrastructure cloud sous-jacente. Aujourd'hui, Platform.sh fonctionne sur AWS, Google Cloud, Azure, OVH Cloud et Orange Cloud. Nous avons construit tout ce dont un grand site de contenu ou de commerce électronique aurait besoin, entièrement intégré dans notre offre. Un PaaS efficace, sécurisé et fiable qui permet aux développeurs d'intégrer et de déployer en continu sans crainte, même le vendredi.

Développement d'une série de technologies PaaS intéressantes

Au fur et à mesure de l'évolution du PaaS Platform.sh, nous avons développé une série de technologies innovantes. Notamment nos régions multicloud et hyperdenses grâce à notre WAF en streaming et à toutes les couches d'automatisation qui permettent aux entreprises d'exécuter des centaines d'applications simultanément tout en les maintenant à jour et en les sécurisant.

Nous avons également simplifié notre offre. Avec des plans clairs de taille de t-shirt disponibles : petit, moyen, grand, XLarge, et 2XLarge. Et si vous finissez par obtenir plus de trafic : il vous suffit de passer au niveau supérieur. Pas besoin de réfléchir à quoi que ce soit d'autre, tout fonctionne simplement.

Lorsque nous avons commencé à travailler sur Platform.sh, nous voulions faciliter la vie des développeurs de logiciels qui géraient l'infrastructure. Et peut-être en raison de nos racines, nous avons tout construit sur des abstractions de haut niveau. Les conteneurs avant même que Docker n'existe. L'infrastructure descriptive en tant que code (IaC) avant même qu'elle ne soit appelée ainsi. Tout cela signifie que très tôt, lorsque nos clients, en particulier les agences qui utilisent souvent différentes piles pour leurs différents clients, nous demandaient s'ils pouvaient utiliser Platform.sh pour Symfony, Node.js, Rails, Elixir ou Django- nous pouvions répondre oui, bien sûr.

Le commerce électronique et les CMS sans tête faisaient également fureur à l'époque et nous devions donc nous assurer que l'exécution de plusieurs services d'application dans un cluster était un domaine dans lequel notre PaaS était performant. Si les cas d'utilisation initiaux de Platform.sh ne concernaient que quelques applications - une tête statique avec un backend - les abstractions étaient importantes. Nous n'allions donc pas coder en dur une limite. Une application, deux, deux douzaines : les primitives sont les mêmes.

Grâce à nos origines dans le commerce électronique, nous savions très bien gérer la couche de persistance - du point de vue de la conformité, des performances et de la cohérence - et nous assurer que les sauvegardes permettaient aux utilisateurs de reprendre leurs activités rapidement. Nous avons constaté que ces capacités étaient très utiles à nos utilisateurs, quelle que soit la technologie qu'ils avaient choisie. Il semble que les personnes qui gèrent des backends de jeux se soucient de ne pas perdre un score élevé tout autant que les commerçants se soucient de ne pas perdre l'enregistrement d'une vente.

La simplicité n'est pas universelle : le début de l'évolution d'Upsun

Après quelques années de fonctionnement de centaines d'applications diverses avec Platform.sh, nous avons réalisé que notre approche simple, de la taille d'un t-shirt, était parfaitement adaptée à la plupart des projets de CMS et de commerce électronique. Cependant, nous avions besoin d'aller plus loin et d'offrir aux utilisateurs plus de flexibilité dans le processus d'allocation des ressources, en particulier pour les applications construites sur des architectures découplées et composables. Nous voulions leur permettre de mieux contrôler l'allocation des ressources pour chaque composant de leur projet et de faire évoluer ces composants de manière indépendante en fonction des besoins de leur projet.

Les plans que nous vendions avec Platform.sh étaient simples : un plafond basé sur la quantité maximale de CPU et de RAM pour l'environnement de production. Nous intégrions automatiquement la plus grande taille de chaque type de conteneur (dans les limites du plan) dans ces plans. Les environnements de développement de l'aperçu avaient un comportement différent. Au lieu de cela, nous avons simplement fait en sorte que chaque conteneur soit le plus petit possible. C'était simple. Et cela a fonctionné. La plupart du temps. Mais avec le temps, nous nous sommes rendu compte que pour certains types d'applications, ce plan commençait à ne pas fonctionner. Parfois, c'était juste un peu gênant et parfois cela signifiait qu'il y avait des charges de travail qui correspondaient techniquement mais que nous ne pouvions pas exécuter de manière raisonnable.

Nous avons découvert que la simplicité est difficile ; ce qui peut être simple dans un cas d'utilisation peut rendre un autre cas d'utilisation horriblement lourd. Les projets de CMS et de commerce électronique ont généralement une topologie très stable, de sorte qu'en tant que développeur de ce type d'applications, il n'est pas fréquent d'ajouter ou de supprimer des services. Et lorsque c'est le cas, notre système Platform.sh est simple. Il suffit de réaffecter les ressources entre tous les services. Mais cela signifie également que lorsque vous ajoutez un service à un environnement existant, les autres services peuvent automatiquement devenir plus petits. Et si vous ajoutez un service et qu'il dépasse les maximums, vous devez passer à la taille de t-shirt suivante, qui est le double. Si cette approche simple convient à un grand nombre de topologies - une application, une base de données relationnelle, un cache, un moteur de recherche -, elle n'est pas optimale pour de nombreuses autres applications.

De nombreux clients ont apprécié notre approche souple, qui consistait à essayer d'intégrer le plus de choses possible dans un plan. D'autres, en fonction de la typologie de leur projet, ont dû lutter contre le comportement par défaut de ces plans. Et après avoir vu de plus en plus de charges de travail qui sortaient des lignes d'un CMS ou d'un projet de commerce électronique, nous avons décidé qu'il était temps d'offrir un modèle de tarification alternatif.

Qu'est-ce qui rend Upsun si spécial ?

Alors que les projets monolithiques de type CMS représentent toujours une grande partie de notre marché, les générateurs de sites statiques et les projets d'architecture découplée et composable gagnent en intérêt et en part de marché chaque mois. Nous voulions qu'Upsun soit construit pour satisfaire les nouveaux cas d'utilisation que nous voyons apparaître dans l'écosystème du développement web et fournir la meilleure expérience du marché pour les développeurs. La nouvelle offre d'Upsun s'articule autour de sept fonctionnalités principales et d'un concept central : Vous avez le contrôle.

Allocation explicite des ressources

Avec Upsun, chaque conteneur dans chaque environnement peut désormais être configuré avec ses propres paramètres de ressources informatiques (CPU et RAM).

Cela ouvre de nombreuses nouvelles possibilités pour votre environnement de production, notamment :

Garantir que toutes les applications et tous les services disposent toujours des ressources nécessaires pour répondre aux demandes entrantes.

Créez autant de travailleurs ou d'instances de bases de données que vous le souhaitez, ou ajoutez un nouveau micro-service en un clin d'œil sans affecter les conteneurs existants.

Ne développez que des applications ou des services spécifiques au fur et à mesure de l'évolution de votre projet, au lieu de l'ensemble du projet.

Gérer les pics de trafic en faisant évoluer rapidement les goulots d'étranglement spécifiques de votre application.

Cependant, les avantages ne se limitent pas à l'environnement de production. Cette flexibilité vous permet désormais de dimensionner vos environnements de prévisualisation comme vous le souhaitez et crée une variété de nouvelles opportunités pour nos utilisateurs qui le peuvent :

Dimensionner temporairement un environnement de prévisualisation avec les mêmes ressources que la production pour exécuter des tests de performance et de charge pour une fraction du prix.

Profiler les applications et identifier les goulots d'étranglement en modifiant les ressources allouées et en analysant les résultats avec Blackfire.

Exécutez de minuscules environnements de prévisualisation pour optimiser le coût et la consommation de carbone des instances temporaires.

Une tarification basée sur l'utilisation adaptée

Avec les nouvelles méthodes de définition et d'allocation des ressources, nous devions repenser la manière dont nous fixions le prix de notre valeur. Nous avons fait d'innombrables tentatives pour créer le modèle de tarification le plus efficace en gardant toujours à l'esprit trois objectifs :

La tarification doit être flexible pour s'adapter aux nouvelles possibilités offertes par l'allocation des ressources.

La tarification doit être juste et transparente.

La tarification doit être simple à comprendre pour tout le monde.

Une nouvelle équation tarifaire : séparer les ressources de notre valeur

Désireux d'être justes et transparents, nous avons décidé d'isoler les ressources - CPU, mémoire et stockage - de la valeur que nous fournissons - flux de développement et déploiement sûr et fiable.

Cela permet aux utilisateurs d'avoir une vision transparente de la manière dont les ressources seront facturées. Cela garantit que vous pouvez faire évoluer vos applications jusqu'à des centaines de CPU, si vous en avez besoin ou si vous le souhaitez, à un coût similaire à celui des fournisseurs IaaS que vous connaissez déjà. Certaines de nos régions nous coûtent plus cher que d'autres, mais nous appliquons toujours les mêmes prix. Notre objectif est de vous donner le contrôle sans que vous ayez à gérer une facturation IaaS trop complexe.

Comme pour AWS EC2 vs RDS, le prix de nos ressources de services gérés inclut l'automatisation et la supervision supplémentaires requises pour les bases de données, les files d'attente et d'autres services backend. Et comme nous souhaitons promouvoir une utilisation plus responsable du cloud, nos régions à faible émission de carbone bénéficieront également d'une réduction supplémentaire.

Valoriser votre temps et favoriser la collaboration

Platform.sh propose un grand nombre de fonctionnalités innovantes et de bonnes pratiques. Mais le principal avantage de l'utilisation de Platform.sh est la possibilité de regagner le temps que vous consacrez souvent à la gestion de l'infrastructure des applications. C'est tout aussi vrai pour Upsun.

Nous avons toujours veillé à ce que nos clients ne passent pas d'innombrables heures à mettre en place et à maintenir des infrastructures coûteuses chaque mois. Et plus il y a de personnes qui travaillent sur vos projets, plus le bénéfice est évident. C'est pourquoi nous avons décidé de centrer notre valeur sur les licences d'utilisation. Cette dimension est la meilleure expression du temps récupéré que vous gagnez.

Nous sommes convaincus que le fait que tous les membres d'un projet travaillent sur Upsun aux côtés des développeurs est la meilleure façon d'en tirer le meilleur parti. C'est pourquoi nous mettons en place des licences de visualisation gratuites. Les membres du projet qui ne voient que les environnements et les applications déployées peuvent profiter d'Upsun gratuitement. Invitez autant de parties prenantes, de clients et de réviseurs que vous le souhaitez sans aucun impact financier sur vos projets.

Et nous avons gardé le meilleur pour la fin. Avec Upsun, les licences d'utilisation sont désormais basées sur l'organisation et non plus sur le projet. Cela signifie que vous n'avez pas à vous soucier de donner accès à un nouveau projet à un utilisateur réel.

Automatisation des projets

Pour chaque nouveau projet que vous créez, vous obtenez une variété de ressources incluses et vous ne serez facturé que si vous dépassez ces quotas inclus, qui sont :

10GB de bande passante Egress (sortante) & 500k requêtes entrantes

1GB de stockage dans tous les environnements

300 minutes de construction

Jusqu'à 100 noms d'hôtes et certificats TLS

Vous trouverez tous les détails sur la page des tarifs d'Upsun.

Support et accords de niveau de service

Comme le besoin de support augmente avec l'utilisation d'Upsun, nous avons décidé de déplacer le support au niveau de l'organisation, votre montant de support sera directement proportionnel à votre nombre de projets et d'utilisateurs.

Contrairement à Platform.sh, notre Uptime SLAs (99.9/99.99%) est par projet. Cela permet au sein d'une même organisation d'exécuter des applications non critiques à un coût optimisé en même temps que des applications critiques qui nécessitent ces garanties supplémentaires.

Une nouvelle expérience utilisateur centrée sur le CLI

Le CLI de Platform.sh a toujours été au cœur de l'expérience utilisateur et Upsun n'est pas différent. La nouvelle CLI d'Upsun est accompagnée d'une commande "project:init", rationalisant la création des fichiers de configuration YAML d'Upsun pour la migration ou la création de nouveaux projets.

Nous introduisons également la commande "scale", qui vous permet de définir les ressources de vos conteneurs d'environnement via l'interface de commande, puis de les augmenter ou de les réduire. Verticalement ou horizontalement.

Les applications peuvent être mises à l'échelle horizontalement dès le départ. Cela signifie que vous pouvez assurer l'évolutivité des applications sans état, sans limitation, et augmenter la fiabilité de vos applications.

Observabilité à tous les niveaux

L'observabilité est essentielle pour les applications web, car elle permet aux développeurs de comprendre le fonctionnement de leurs systèmes en temps réel. Les développeurs et les opérateurs peuvent surveiller leurs applications, détecter les erreurs et les anomalies, et identifier et résoudre rapidement les problèmes avant qu'ils ne deviennent majeurs grâce à l'outil d'observabilité d'Upsun.

Nos outils d'observabilité comprennent

Des métriques et des analyses au niveau HTTP.

Profilage continu des applications Go et Node.js.

Profilage étendu et surveillance des performances des applications PHP et Python.

Mesures de l'infrastructure et des ressources.

Grâce à l'observabilité à tous les niveaux, les développeurs peuvent prendre des décisions basées sur les données et obtenir des informations précieuses sur le comportement de leurs applications, ce qui leur permet d'améliorer continuellement leurs systèmes pour une performance et une efficacité optimales.

Upsun ne remplace pas le PaaS Platform.sh. C'est le meilleur du PaaS Platform.sh emballé dans un modèle de tarification entièrement revu et conçu pour répondre aux besoins des projets d'architecture découplée et composable qui étaient limités par le modèle de tarification "basé sur le plan".

Upsun est maintenant disponible en version bêta privée pour les prochains mois. Si vous avez un ou plusieurs projets qui bénéficieraient de ces nouvelles fonctionnalités, faites-le nous savoir via ce formulaire!

Rejoignez la liste d'attente dès maintenant ! Premier arrivé, premier servi !

Mise à jour : 07 décembre 2023

Amenez votre application et votre équipe à Upsun PaaS. Vous pouvez vous inscrire pour un essai gratuit en bêta ouverte*, où vous pouvez tester et évaluer Upsun dans un environnement de production, avec beaucoup de ressources.

Démarrer un essai gratuit

*L'essai gratuit de 5 jours comprend 1 organisation, avec 1 projet et 2 environnements en cours d'exécution ; un nombre illimité de conteneurs ; un nombre illimité d'utilisateurs ; et jusqu'à 4,5 CPU, 12 Go de mémoire et 20 Go de stockage réseau fonctionnant simultanément. À la fin de la période d'essai, votre projet sera suspendu jusqu'à ce que vous ajoutiez une méthode de paiement valide à votre compte. Voir les tarifs pour plus de détails.