Le 05/09/2017 à 12:49, Philippe Bourcier a écrit :
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é).
Donc on est bien d'accord que le code aas c'est une erreur monumentale si c'est pas sur ta propre infra.
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.
J'arrive pas à retrouver un superbe article qui parlait très bien de ce sujet qui disait en gros Amazon veut vos bases de données et où la personne expliquait comment même avec du chiffrement basé sur l'authentification des personnes distantes Amazon se servait dans les données.
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,
Pour le moment cette solution n'existe pas et c'est bien là le souci, donc clairement code aas est oublier pour le moment.
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
Oui ça viendra sans doute mais ça réglera pas le soucis de ne pouvoir installer cette infra sur ta propre archi.
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 est d'accord sur le fait qu'on peut sortir tellement mieux. De notre côté on a depuis longtemps des plugins Nagios qui check le contenu d'une page et qui nous sort des alertes en fonction du temps first byte, du temps total de la page, du coût ressources pour la requête. Là dessus je pense qu'on est en avance sur la méthode Nagios. Mais du coup aller chercher des métriques au delà c'est clairement du ML et je vois pas quelle boite a la possibilité de se lancer là dedans si t'es pas dans le bigdata déjà.
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... :)
Formidable, personnellement non, je fuis à présent tout ce qui laisse des données traînées et je fais en sorte de régulièrement demander et faire effacer mes données dans les entreprises. Faire du bigdata de ses propres métriques pour améliorer ses produits pourquoi pas, faire du bigdata sur les habitudes des gens je trouve ça horrible.