Serverless Platform Engineering : L'Abstraction Ultime

Le Platform Engineering se concentre souvent sur Kubernetes. Mais Kubernetes n'est qu'un outil, pas une fin en soi. L'objectif est de permettre aux développeurs de livrer du code. Le Serverless Platform Engineering pousse cette logique à l'extrême en supprimant totalement le besoin de gérer des clusters.

Déplacer la Frontière

Dans une plateforme basée sur Kubernetes, l'équipe plateforme gère les nœuds, le control plane et l'ingress. Dans une plateforme Serverless, la frontière se déplace : le fournisseur cloud gère l'infrastructure, et l'équipe plateforme gère l'Interface de Service.

Les Avantages du Serverless pour les Plateformes

1. Zéro Surcharge Opérationnelle : Plus de correctifs d'OS, plus de mises à jour de versions Kubernetes, plus de gestion fine du scaling.
2. Paiement à l'Usage : Les coûts d'infrastructure s'alignent automatiquement sur l'utilisation réelle.
3. Onboarding Ultra-Rapide : Les développeurs ne se soucient que de leur code et de quelques lignes de configuration.

Le Rôle de l'Équipe Plateforme dans un Monde Serverless

Même avec le Serverless, une plateforme reste nécessaire. Le focus de l'équipe se déplace vers :

• Standardisation des Contrats de Service : Définir comment les services communiquent et gèrent les erreurs.
• Sécurité et Conformité : Garantir que les fonctions Serverless respectent les politiques de sécurité de l'organisation.
• Observabilité : Centraliser les logs et les traces à travers des centaines de fonctions éphémères.
• Workflow Développeur : Fournir les outils de développement local et de CI/CD qui rendent le Serverless facile à tester et à déployer.

Ce qu'il faut toujours standardiser

Passer au Serverless ne supprime pas la complexité ; cela change surtout l'endroit où elle se cache. Une plateforme solide standardise notamment :

• Les patterns de déploiement : une façon recommandée de packager, versionner et publier des fonctions.
• Le réseau et l'identité : comment les fonctions accèdent aux bases de données, files, APIs internes (principe du moindre privilège).
• Les contrats d'événements : retries, idempotence, dead-letter queues et gestion de la backpressure.
• Les défauts opérationnels : dashboards, alerting, tracing et corrélation des logs.

Des garde-fous pour maîtriser les coûts et les risques

Le Serverless peut surprendre en coût et en sécurité si vous ne fixez pas de limites explicites :

• quotas/budgets et alertes (par équipe, par service)
• policy-as-code pour les permissions et l'exposition publique
• bibliothèques partagées pour le logging, le tracing et la gestion d'erreurs

Pièges fréquents

• Ignorer les cold starts : mesurer la latence et choisir le bon runtime / la bonne architecture.
• Prolifération distribuée : des centaines de petites fonctions demandent un bon naming, une ownership claire et une observabilité robuste.
• Vendor lock-in par accident : expliciter les services managés acceptés en échange de la vitesse.

Conclusion

Le Serverless est l'évolution logique du Platform Engineering. En faisant abstraction du cluster, vous permettez à vos ingénieurs de concentrer 100 % de leur énergie sur la création de valeur métier plutôt que sur la maintenance de l'infrastructure.

Le meilleur résultat n'est pas « tout est serverless », mais une plateforme qui propose le serverless comme une voie pavée, avec des contrats et des garde-fous clairs.