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,
--
Philippe Bourcier
web : http://sysctl.org/
blog : https://www.linkedin.com/today/author/philippebourcier
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/