Re,
aimer son métier et ce que sa boite produit. Quand on voit les ravages des startups bigdata enfermées chez Amazon dans le sens où les frais de sortie s'élèvent à plus cher que ce que la boite a gagné en 5 ans ...
Big data = own infra... et je connais bien le sujet :) Sinon effectivement les coûts sont largement supérieurs à ce que tu peux faire toi-même (on avait calculé).
Ajouté au fait que des DB aas et du code aas c'est autant de données en libre service même chiffré car le code lui saura y accéder.
Tu peux faire de l'auth, quand même... je ne vois pas la différence.
Serverless sur une stack logiciel que l'on peut déployer où l'on veut sur sa propre infra (cloud, premise, cloud privé) oui là ok.
C'est ca qui est bien... à partir du moment où tu peux déploy du serverless sur aws/ovh/other,
l'enfermement du code chez un prestataire. Je refais pas le schéma du prestataire qui tousse, qui change ses conditions de vente / norme de code / ... et vous avez du jour au lendemain une boite qui ne tourne plus.
J'ai tendance à faire confiance aux gens pour sortir des libs multi-plateformes. A l'image des scripts de déploiement multi-cloud ou même de ce que fait
existe dans nombre de solutions existantes. Le travail ensuite c'est de définir les bons seuils sur les bonnes métriques, comme on faisait sur un nagios-like.
Oui les métrics apportent beaucoup plus de données mais une alerte type nagios du genre check_http en état failed = alerte est relativement simple. Après la multitude des données fait que l'on est noyé sous le nombre d'alertes potentielles qui peuvent être créées.
Le cas OVH est relativement particulier sur la partie hosting/PaaS/IaaS dans la mesure où une grande partie de leurs services et monitorable en mode passif (métriques) + pings. Mais ils ont de plus en plus de services sur lesquels on veut monitorer et l'état et la QoE (qualité d'expérience, ie : ça rame/ça rame pas). Avec les langages à GC (Java/C#) et les archis micro-services en cascade (très adaptées au monde agile), on peut très bien avoir un HTTP qui répond (genre HEAD / ou port 80 open) et un service qui est complètement dans les choux (gros lag de 2s), c'est pour cela que le bon mix c'est les checks actifs, de la corrélation de logs (via Kafka, Logstash, etc) ET les métriques dans le code et l'infra (error codes HTTP, latence de chaque requête, fonction, etc). On vit une époque formidable pour la data, elle n'a jamais été aussi importante et on n'a jamais eu autant d'outils simples pour la traiter... :)
Cordialement,