Technologies

Radar des technologies

Publié le : Auteur: Anteo Consulting Un commentaire
technologies

En mars dernier, ThoughtWorks a publié un nouveau rapport sur ce qu’ils considèrent être les technologies émergentes du moment en matière de développement logiciel au sens large : des techniques de gestion de projets à l’infrastructure de production, en passant par les langages et la gestion de la qualité.

Le principe en est simple : un comité de pointures (Martin Fowler, Neal Ford, ..) débat et positionne différents sujets qui font l’actualité (voir le buzz) sur une mire de radar :

  • Au centre de la cible, les technologies à adopter !
  • Autour de celles-ci, celles à essayer, sur un projet qui pourra se permettre une modeste prise de risque.
  • Puis viennent celles, parce qu’elles influenceront votre vision de ce monde et orienteront vos choix opérationnels ou simplement de développement personnel, qui gagneront à être découvertes.
  • Et en périphérie celles dont ils doutent, qu’elles soient encore immatures ou au contraire en déclin.

La cible est par ailleurs organisée en quatre quadrants, chacun se focalisant sur l’un des domaines suivant :

  • Les processus et techniques
  • Les outils et les frameworks
  • L’infrastructure serveur, physique et logicielle, les plateformes clientes, l’architecture des solutions distribuées
  • Les langages

 

Ces rapports sont en téléchargement libre sur ce site : http://www.thoughtworks.com/radar
Leurs classements ne sont volontairement que maigrement commentés afin de garder le document abordable, mais, et c’est là tout son intérêt, il offre une vision synthétique et structurante invitant à l’approfondissement et au débat.

Quelques sujets notables de mon point de vue :

  • Au niveau de la forme tout d’abord, il est remarquable que l‘un des quadrants soit dédié au seul domaine des langages.
    Il est notoire que les langages de programmation sont légions et qu’il en apparait constamment de nouveaux, mais cette profusion cache une réalité plus tranchée avec 80% des débats se rapportant toujours aux mêmes 10 langages depuis des années et dans beaucoup de services informatiques des choix arrêtés (JEE/.Net/PHP/..) qui ne tolèrent que peu d’exceptions.
    Alors pourquoi un plein quadrant dédié au langage ? Est-ce à dire que le « Polyglot Programming » progresse dans les esprits ou que la récente ébullition autour des langages sur la JVM par exemple (Scala, Clojure, Ceylon, Kotlin, ..) est réellement amenée à fissurer l’hégémonie du langage Java au sein de la plateforme JEE ?
  • La persistence, également polyglote : Choisissez RDBMS et NOSQL (graphe, clef-valeur, etc) en fonction de chacun des besoins dans une application.
    On parle évidement là d’installations conséquences où les capacités de réplications de sessions via un mongoDB serait par exemple un plus. Pour le commun des mortels, et 99% des applications de ce bas monde, le surcoût induit par la complexification de l’environnement sur toutes les phases du développement et au final de celui de l’exploitation vous fera préférer la gestion de clefs-valeurs dans une bête table de votre RDBMS. KISS 🙂
  • L’utilisation d’un serveur embarqué en lieu et place d’un déploiement sur un serveur d’application.
    Leur constat est qu’aujourd’hui la consolidation se fait généralement via la virtualisation et que les serveurs d’applications ne gèrent finalement qu’une seule application chacun. Dans ces conditions, et à moins d’avoir des besoins spécifiques, il est plus simple d’embarquer le serveur et de livrer aux équipes d’exploitation des applications autonomes, éventuellement packagé nativement pour la plateforme.
  • Leur déclassement de maven, standard de facto du build java, qui paye son manque de flexibilité.
    Qui n’a jamais pesté sur la complexité extraordinaire de l’ajout d’une étape de génération, de la séparation des tests suivants plusieurs profils ou de la génération de multiples artifacts ?
    Sans parler de la verbosité de sa configuration : Le XML reflue partout, au profit des annotations et du CoC (Convention over Configuration, au sein de la plateforme J2EE par exemple), au profit de formats plus simples et/ou plus efficaces (JSON, Protocolbuffer, ..), à quand l’abandon de Maven ? Un retour à Ant et Ivy (Zut, c’est du XML aussi !).
    Leurs favoris s’appelle Gradle côté JVM, où l’on décrit/écrit ses scripts de  build en Groovy, et PSake côté .Net, scripté en PowerShell.
  • La mise en avant de l’isolation par conteneurs, une solution alternative à la virtualisation qui offre de bien meilleures performances.
    Le principe n’est plus d’émuler (le plus souvent avec l’aide du processeur) une machine complète pour chaque machine virtuelle, mais de faire tourner plusieurs systèmes dans des contextes isolés sur un même noyau. Une possibilité offerte de longue date par les zones Solaris et les jails FreeBSD. Sous Linux, le bal a été ouvert par les patchs VServer, le flambeau porté haut par des solutions comme OpenVZ (utilisé dans la distribution Proxmox par exemple), mais la solution « officielle » du noyau linux arrive et s’appelle LXC.
  • L’obsolescence programmée des technologies de RIA actuelles (Flash, Silverlight Flex).
    Parce qu’il s’agit encore globalement de solutions propriétaires et enfermantes, les solutions de RIA d’Adobe ne peuvent être choisies que pour répondre à des manques (de fonctionnalités, d’outillage, de compétences disponibles, ..) dans les technologies standard. Avec l’arrivée d’HTML5 et du CSS3, l’optimisation des moteurs javascript et le support de l’accélération graphique, les arguments en faveur d’un tel choix s’amenuisent et continueront à le faire.
  • La nouvelle jeunesse de la programmation fonctionnelle.
    Parce qu’elle répond à des problématiques très concrètes – la robustesse, la maintenabilité d’un code, sa testabilité – et qu’elle offre de nouvelles approches à la question toujours davantage d’actualité de la programmation multi-threadée, le paradigme fonctionnel sort de l’ombre… à nouveau !
    De nouveaux langages apparaissent, tels que F# sur la CLR ou clojure et scala sur la JVM, qui ménagent via une interopérabilité sans faille avec leur environnement la possibilité de leur adoption en douceur dans les contextes précis où ils brilleront le plus.
    Plus pragramatique encore, de nombreuses librairies apportent certains concepts clefs de la programmation fonctionnelle comme les fonctions d’ordre supérieur au sein de vos langages de prédilection (en java : Functional Java, TotallyLazy, LambdaJ).
    Un monde à (re-) découvrir parce le langage est le premier des outils du développeur, et qu’ils ne se valent pas tous, ni ne conviennent tous en toutes circonstances.

Au final et pour aller au delà des opinions que ThoughtWorks partagent dans ces publications, il sera aussi sans doute intéressant de s’essayer à l’une de leur recommandation : « Build your own radar » !

  • lbardon

    Je tempèrerais le point 2 concernant la complexification liée à l’introduction de technologies NoSQL.
    De mon point de vue, elles sont idéalement déployées spécifiquement pour certaines données, et combinées à une approche plus « traditionnelle » (SGBD) pour le reste de l’application ou du SI; l’idée étant d’utiliser le bon outil pour le bon usage plutôt que de mettre « tous les œufs dans le même panier ».
    Par exemple dans un projet agile avec des données volumineuses, peu structurées, et/ou dont le schéma change fréquemment, le côté schemaless de MongoDB apporte justement une flexibilité qui bénéficie à la fois aux phases de développement et d’exploitation (qui n’a jamais pesté contre une reprise de données bloquée ?). Sans compter les avantages au niveau de la scalabilité, et le fait que MongoDB sait faire bien plus que du clé-valeur…
    Ceci dit, effectivement, déployer Memcached/Redis + MongoDB (+ Hadoop pour de l’analytique ? allez, soyons fous…) suppose un projet dont les contraintes rendent nécessaire le recours à ce type d’outil. Histoire d’éviter d’écraser une mouche avec une enclume.