• Accueil
  • BYOD
  • Cloud
  • Data
  • Mobilité
  • Sécurité
  • DSI 2.0
  • show/hide menu
  • Accueil
  • BYOD
  • Cloud
  • Data
  • Mobilité
  • Sécurité
  • DSI 2.0
  • Applications Azure

    Développer des applications en noSQL : un changement de culture radical

    0

    Les bases de données noSQL cassent les limitations du modèle relationnel en termes de scalabilité, de volumétrie ou de montée en charge. Leur variété et leurs spécificités remettent en cause les habitudes des développeurs. 

    00914368_Size1024

    Selon IDC, le volume des données augmentera de quelque 40 % par an dans les prochaines années. De plus, avec l’évolution vers l’entreprise numérique, ces données seront consultées par un nombre croissant d’utilisateurs extérieurs à l’entreprise. Face à cette évolution, les moteurs de bases de données relationnelles sont à bout de souffle. Julien Simon, vice-président en charge de l’ingénierie chez Criteo, explique :

    « Longtemps idéal pour construire des applications critiques traditionnelles, ce modèle est mal adapté aux applications Internet car la scalabilité repose alors beaucoup sur la puissance unitaire du serveur. »

    En particulier, la notion de relation bride la montée en charge car elle sous-tend que toutes les données sont stockées au même endroit et sont organisées pour être interrogées de différentes façons. Ces limites sont difficilement conciliables avec les nouvelles applications Internet, qui imposent souvent de démarrer petit, de monter brutalement en puissance et de s’affranchir des contraintes géographiques. Les moteurs de base de données noSQL promettent de faire sauter ces verrous.

    Une façon différente d’organiser les données

    Pour parvenir à leur fin, les moteurs noSQL bousculent l’ordre établi. « En noSQL, on stocke les données autant de fois que nécessaire et en fonction des requêtes, sans chercher une cohérence globale », explique Benjamin Guinebertière, architecte Windows Azure chez Microsoft. De plus, il n’y a plus de schéma figé ni de notion de transaction. En contrepartie, la scalabilité est pratiquement infinie, puisqu’il suffit de répartir la base de données sur un nombre croissant de serveurs, qui peuvent être géographiquement distribués. Dès lors les bases noSQL sont aussi bien adaptées aux applications classiques ayant besoin de monter en charge, qu’aux applications Internet ou big data à très forte volumétrie, avec un grand nombre d’utilisateurs et manipulant des données structurées ou non structurées.

    Choisir parmi une grande variété de technologies

    « Le noSQL est un mouvement polymorphe comptant de nombreuses architectures et technologies, des plus simples au plus évoluées », explique Julien Simon. La première phase d’un projet consistera donc à choisir la bonne technologie. « C’est un gros travail à réaliser en amont, d’autant qu’une même application utilisera souvent différentes technologies, selon les types de données », affirme Fabrice Bonan, cofondateur de Talend. Les critères de choix seront le type d’application (cache, analytics, gestion de contenu, e-commerce…) ou les contraintes de production (haute disponibilité, scalabilité, volumétries, nombre et dispersion géographique des utilisateurs).

    Le choix sera compliqué par une offre encore pléthorique. Certains produits sont exclusivement dans le cloud (Microsoft Storage Table ou Amazon Dynamo DB). D’autres comme Cassandra, Memcache ou Big Table sont on-premise ou dans le nuage. Disponible en open source ou, par exemple, sur le PaaS Microsoft Azure, MongoDB figure parmi les moteurs noSQL les plus connus. « Cassandra est davantage un extraterrestre et sera plutôt dédié au stockage de très grandes quantités de données pouvant se compter en milliards d’éléments, avec une haute disponibilité », estime Julien Simon.

    Une intégration technologique simple

    Pour les développeurs, le saut technologique dépend du type de moteur noSQL. MongoDB a une interface en JavaScript. Cassandra est associé au langage CQL (Cassandra Query Language). Mais il faut souvent passer par des APIs plutôt que par un langage. « La courbe d’apprentissage de MongoDB est très rapide, que l’on travaille sous PHP, Java ou un autre langage. Les opérations sont peu nombreuses et bien plus simples qu’avec SQL », estime Aurélien Foucret, expert technique chez Smile. Mais si on adopte Cassandra ou Redis, l’impact sur l’application est très fort, notamment parce qu’il n’y a pas d’équivalent à SQL et que la base ne peut pas être requêtée.

    Conception des applications : un changement de culture

    L’aspect purement technologique n’est pas le plus complexe. Il faut surtout repenser la façon dont sont représentées les données. « Les gens ont été éduqués à faire plusieurs tables et à normaliser les données alors qu’en noSQL, elles seront souvent regroupées dans la même structure », donne en exemple Aurélien Foucret. Finalement, il faut désapprendre des réflexes anciens. Mais une fois cet investissement réalisé, le développeur bénéficiera aussi de facilités. Par exemple, la notion de transaction peut être simplifiée en regroupant dans un même document toutes les opérations à réaliser. De même, certains algorithmes, notamment dans le domaine de l’analytics, seront bien plus efficaces et faciles à paralléliser.

    Un impact sur l’organisation et les méthodologies

    D’autre part, la variété des technologies noSQL impose une réorganisation des équipes. « Des architectes de haut niveau ayant une vue globale du projet s’appuieront sur des compétences très pointues dans chaque technologie noSQL », estime Fabrice Bonan. De plus le noSQL fait évoluer la relation entre métiers, développement et production car il favorise les méthodes agiles et le  devops. « En supprimant les silos entre bases de données et développement, le noSQL est mieux adapté au développement itératif », affirme ainsi Julien Simon.

    articles liés

    Windows Azure, le Cloud au cœur de l'IT

    Windows Azure, le Cloud au cœur de l'IT

    Messagerie instantanée d'entreprise : La Poste Courrier opte pour Lync

    Messagerie instantanée d'entreprise : La Poste Courrier opte pour Lync

    Comprendre le cloud hybride, 3e épisode : Jean Ferré

    Comprendre le cloud hybride, 3e épisode : Jean Ferré