Comparatif
Plateforme vs Kubernetes maison
Kubernetes vous donne tous les réglages. La plupart des équipes n'en utilisent que quelques-uns et paient le reste en maintenance.
L'essentiel
- Déployez depuis un dépôt en quelques minutes, sans cluster à monter ni à mettre à jour.
- Autoscaling, TLS et réseau privé sont actifs par défaut, pas du YAML à maintenir.
- Vos astreintes portent sur votre produit, pas sur le plan de contrôle.
Côte à côte
Ce que vous gérez, et ce qui est géré pour vous
Les mêmes charges de travail, deux façons de les exploiter.
| Fonctionnalité | Plateforme | Kubernetes maison |
|---|---|---|
| Mise en place et déploiements | ||
| Délai avant le premier déploiement | Quelques minutes | Des jours, voire des semaines |
| Déploiement à chaque push | Inclus | Pipeline à construire |
| Déploiements sans interruption | Inclus | Rollout à configurer par service |
| Environnements de prévisualisation | Inclus | Non inclus |
| Exploitation | ||
| Mises à jour du plan de contrôle et des nœuds | Gérées pour vous | Votre équipe |
| Autoscaling | Inclus | Metrics server et réglages |
| Certificats TLS | Émis et renouvelés | Module à installer |
| Logs et métriques | Intégrés | Stack séparée |
| Équipe et coûts | ||
| Ingénieurs plateforme dédiés | Pas nécessaires | En général 1 à 3 |
| Tarification | Par instance, à la seconde | Nœuds plus marge inutilisée |
| Contrôle total de chaque réglage du cluster | Non inclus | Inclus |
Pourquoi les équipes changent
Ce qui change quand le cluster n'est plus votre travail.
Des heures regagnées chaque semaine
Plus de fenêtres de mise à jour, de redimensionnement de pools de nœuds ni d'API dépréciées à traquer.
Une prévisualisation par pull request
Chaque branche obtient son environnement de prévisualisation, sans une ligne de configuration de cluster.
Une mise à l'échelle qui fonctionne
Fixez un nombre minimum et maximum d'instances. La plateforme s'occupe du reste.
Sécurisé par défaut
Réseau privé, TLS géré et secrets chiffrés dès le premier déploiement.
Quittez votre cluster en trois étapes
La plupart des équipes migrent leur premier service en un après-midi et terminent en un sprint.
- Service web
- Service privé
- Worker
- Tâche cron
- Postgres
- Cache
- 01Récupération de l'image depuis le registre
- 02Import de 14 variables d'environnement
- 03Démarrage de 3 instances
- 04Contrôle de santé réussi
- 05Réseau privé connecté
- 06Le déploiement est en ligne
- Domaine personnalisé vérifié
- Certificat TLS émis
- Trafic basculé vers la plateforme
- Alertes connectées
- Anciens pools de nœuds vidés
- Cluster supprimé
“Nous avons géré nos propres clusters pendant trois ans. Passer à la plateforme a libéré deux ingénieurs pour le produit, et nos déploiements sont plus rapides.”
FAQ
Vous venez de Kubernetes
Ce que les équipes plateforme demandent avant de confier le cluster.
Contacter le support01Puis-je utiliser mes images de conteneur actuelles ?
Oui. Déployez depuis un Dockerfile de votre dépôt ou depuis une image de n'importe quel registre auquel vous pouvez vous authentifier.
02Et les charts Helm et les opérateurs ?
Les charts se traduisent en services, variables d'environnement et bases de données gérées. Les charges qui dépendent d'opérateurs personnalisés peuvent demander une autre approche, et nous vous dirons lesquelles pendant la revue de migration.
03Est-ce que je perds le contrôle du réseau ?
Les services communiquent par défaut sur un réseau privé. Vous choisissez ceux qui sont publics, et les espaces de travail Entreprise peuvent se connecter à leurs propres réseaux.
04Peut-on migrer progressivement ?
Oui. Faites tourner les deux en parallèle, déplacez un service à la fois et gardez le cluster jusqu'à la bascule du dernier.