Techdays
Yann Schwartz
Moi jai une question. Y a des speakers aux techdays parmis vous ?Vincent
mathias kluba
Frédéric Fadel
Hello Mathias, salut tous,
chez Aspectize on utilise on utilise quasi exclusivement le storage d’Azure pour nos développements sauf si le client décide autrement, ce qui fait qu’on n’a ni base de données relationnelle, ni langage SQL mais on utilise, néanmoins, comme il se doit un modèle relationnel pour structurer les données. Maintenant est-ce bien du NoSql ? Je ne sais pas !
Pour les clients qui pour une raison ou une autre ne veulent pas de Azure, c’est le cas pour un de nos développements en cours, c’est sur Amazon mais avec du SQL Server, néanmoins, puisqu’on utilise notre technologie AaaS, il n’y a aucun manipulation d’SQL en tant que langage non plus ! je sais ça fait encore moins NoSql !
Concernant le « sharding », dans Azure les clés d’accès aux données sont « partitionnées » et on utilise selon le besoin plusieurs stratégies de partitionnement pour gérer soit le « multitenancy », soit les données temporelles…
Une difficulté qu’on rencontre avec le storage Azure c’est l’absence d’index secondaires, qui limite les « search » sophistiqués… du coup nous somme en train de développer ses index, plus d’info en mars quand ça sera complètement intégré à notre technologie.
Tous ça pour dire que non on ne fait pas de MapReduce, pour moi ça rentre dans la catégorie des détails algorithmique qui est pris en compte d’une façon ou d’une autre par Azure, Amazon, Google… mais on ne fait quasiment jamais de SQL (le langage) et de moins en moins SQL (le serveur) mais ça aussi c'est un détail.
Vincent Bourdon
Envoyé de mon iPhone
Hassen Boumaraf
Frédéric Fadel
Ce qui nous a poussé vers Azure ?
Chez Aspectize nous sommes intimement convaincus par le Cloud en général et le PaaS, en particulier par notre propre AaaS.
Je pense que le Cloud va dans le sens de l’histoire, comme toute techno, approche ou outil qui permet de huiler le cycle de création de valeur à travers le logiciel. Aujourd’hui le mouvement IaaS -> PaaS -> SaaS est un des moyens les plus robustes pour éliminer un grand nombre de complications de ce cycle.
Concernant le ROI, il y a deux points de vue qui me semblent pertinents, celui du développement et celui de la production.
Pour le développeur que je suis, la souplesse d’Azure n’a juste pas de prix.
On a besoin, parfois pendant des semaines de changer, modeler, retoucher la structure des données avant de la stabiliser ; avec le « storage Azure » c’est immédiat, avec une base de données c’est bien plus consommateur de temps.
Sinon on peut en quelques clics mettre en place des environnements de prod, preprod et test… à tel point que même pour les dev classiques (on premise ou avec une base de données) nous démarrons toujours les devs en Azure avec du storage et on bascule vers l’environnement final relativement tardivement, et tout cela pour quelques dizaines de dollars par mois.
Concernant le point de vue de production, la situation est plus complexe. Pour un SI ça peut être difficile de tracer une frontière entre le Cloud et la SI interne et le ROI peut ne pas être au rendez-vous aujourd’hui ; mais typiquement pour un éditeur de logiciel qui développe un produit en SaaS (c’est le cas de plusieurs de nos clients pour qui nous développons le logiciel en question) ne pas avoir d’administrateur system, de machines à mettre à jour, de base de données à backuper… et bénéficier d’un système de stockage pas cher et potentiellement infini, le calcul du TCO est vite fait.
J'espère que ça répond à la question et à+.
Mathias Kluba
Yann Schwartz
Je rebondi sur le sujet pour dire que chez vNext on a une équipe qui a mis en place un mongoDB sur Azure pour finalement avoir un SLA de 99,9%.Je sais pas si vous êtes intéressé par un retour d'expérience la dessus et si ils sont dispo mais je le dis au cas ou ;)Vincent b.
- utilisez-vous du NoSQL sur vos projets professionnel (si oui lesquels)
MongoDB et Redis.
- quel en est l'usage? (remplacement de SQL, complément, EventSourcing, audit, etc)
Clé/valeur en mieux, remplacement de SGBD pour les données à forte mise à jour, cache, etc.
Concernant MongoDB:- utilisez-vous le sharding/replication set ?
Oui pour le sharding et replicaset. Faire très attention aux réglages...
- faites-vous du MapReduce, pour quel usage ?
Dans hadoop. Analyse de données / reports. Pas de map reduce dans MongoDB (le map reduce mongodb marche pas bien sur les shards, n'est pas très gentil avec ses petits camarades en modèle concurrent, c'est d'ailleurs pour ça qu'à partir de la 2.2 MongoDB propose un modèle d'agrégation distinct de MR, pour ceux qui veulent juste faire un GroupBy (99% des usages de MR sous mongo ?)
- quels sont les difficultés rencontrées?
Yann Schwartz
Salut,Merci pour ton retour très instructif!Pour rebondir sur ce que tu dis, je pense aussi que le "no schema" des solutions NoSql, comme AzureStorage, est une des grosses raisons d'adoption de la techno.Par contre, si c'est une base "clé-valeur", cela devient plus complexe pour faire des requêtes: ça oblige de choisir judicieusement la clé ou de faire des indexes.Est-ce qu'une base document type mongodb n'aurait été pas plus adapté?
D'un autre coté, Microsoft ne propose pas de base document sur Azure, mongodb pour Azure est une preview (http://www.mongodb.org/display/DOCS/MongoDB+on+Azure) mais il existe du mongodb PaaS comme MongoHQ.Est-ce que vous l'aviez envisagé?Je suppose qu'il y a diverses raisons de ne pas choisir cette solution (mauvaises perfs car datacenter différents? prix en plus de celui de Azure?)
(et comme il n'y a pas que mongodb dans la vie, il y a couchdb sur https://cloudant.com/ mais je ne vois pas de ravendb :( )
Rui Carvalho
Frédéric Fadel
étant donnée que le principe PaaS était (au moins au début de Azure) (et je pense que c'était bien) de faire abstraction total des "vrai" machines... on n'a pas opté pour utiliser autre chose que ce qui existait nativement sur Azure... d'un autre côté personnellement, je suis « early adopter » que sur un nombre très limité de techno et j’ai déjà du mal à suivre ma sélection de techno de chez Microsoft, donc je ne pourrais répondre pertinemment à tes questions mais Yann comble bien mes défaillances…
Sinon petite précision notre techno AaaS c’est du « Architecture as a Service » qui permet de combiner le triple A : Azure, Ajax et Aspectize pour développer des appli full Ajax (production de HTML uniquement dans le browser, là ou il doit être) sans écrire beaucoup de code.
Typiquement pour une application SaaS, multitenant, dans Azure, avec un Modèle d’une trentaine d’entités, une quarantaine de relations, plus de 300 Vues une vingtaine de services serveur et une dizaine de services client on dépense moins de 3000 lignes de code (2100 C# et 800 Javascript).