- L’outil de monitoring des flux regardés par les clients avait d’abord été construit avec AWS Step Functions afin d’être mis en œuvre rapidement
- Mais à mesure que le service a gagné en ampleur, des goulets d’étranglement et des problèmes de coûts sont apparus (appels de fonctions, bucket S3 pour le stockage temporaire des frames, etc.)
- Passage d’une forme de microservices distribués à une architecture monolithique
- Plus besoin d’utiliser un bucket S3
- L’architecture de niveau supérieur reste globalement la même
- Les coûts d’infrastructure ont été réduits de 90 %, et la capacité de montée en charge s’est aussi nettement améliorée
- En migrant vers EC2, il est aussi devenu possible d’appliquer les Compute Savings Plans (réductions avec engagement annuel)
- Les microservices et le serverless conviennent bien aux déploiements à grande échelle, mais leur adoption doit être décidée au cas par cas
6 commentaires
Dire que le serverless permet de réduire les coûts ne semble valable que dans les situations où l’on n’utilise pas la majeure partie des performances d’EC2 ou des VM en cluster.
Quoi qu’il en soit, il semble que cela revienne toujours au même : acheter un gros matériel, le découper en petites unités et les vendre plus cher.
Pour maximiser au maximum la marge, il faut forcément le découper en unités aussi petites que possible, donc je comprends aussi qu’on cherche à orienter vers le serverless.
Le FaaS est vraiment un gouffre financier...
C’est vrai si on maîtrise bien k8s. Mais il faut sans doute aussi prendre en compte le coût de mise en place et de maintien d’une équipe capable de bien gérer k8s...
C’est souvent le cas avec les services cloud : dans les premières phases de croissance rapide, une architecture virtualisée flexible est avantageuse, mais à mesure que l’expérience s’accumule, que le service se stabilise et que l’échelle augmente, il devient, comme dans cet exemple, plus intéressant d’optimiser en termes de coûts et d’exploitation.
Même lors du récent AWS Summit, l’accent était beaucoup mis sur la réduction des coûts grâce au serverless...
C’est surprenant de voir passer un article expliquant que migrer du serverless vers des conteneurs revient moins cher.
Bien sûr, j’ai récemment utilisé le serverless de façon assez légère, et il me semble effectivement coûteux...
Une API simple, qui peut être fournie sur un serveur unique autour de 10 dollars par mois après optimisation,
finissait par coûter plus de 100 dollars par mois en serverless simplement parce qu’il y avait beaucoup d’appels de requêtes.
J’ai immédiatement migré cette fonctionnalité vers un serveur classique. -_-
On sait bien que c’est moins cher que le serverless, mais le chiffre de 90 % et le fait que cet article vienne lui-même d’un service Amazon sont assez intéressants.
AWS voudrait sans doute vendre davantage de serverless, donc c’est assez drôle, haha.