Infrastructure logicielle négligée, applications peu performantes

Gilles Knoery
Directeur général de Digora

Neuf fois sur dix, lorsque la performance et les temps de réponse d’une application se dégradent, les équipes techniques adoptent le même reflexe : elles rajoutent de la puissance. Dans un contexte où les ressources serveurs n’ont jamais été aussi facilement accessibles et bon marché, on les comprend. Le cloud et la virtualisation se banalisent, le prix des mémoires et des CPU est en chute libre, les « appliances » (solutions matériels prêtes à l’emploi incluant matériel et logiciel) de big data fleurissent ici et là…

Le problème ? Les entreprises abusent de ces ressources faciles. Non seulement la course à l’armement n’enraye pas à long terme la chute des performances, mais surtout elle fait grimper dangereusement la facture. Et pour cause, la plupart du temps, ces dysfonctionnements ne sont pas imputables, comme on le croit à tort, à une faiblesse des serveurs, de la base de données ou du réseau. Ils résultent d’un mauvais ajustement entre les couches d’infrastructure et les logiciels.

La majorité des développeurs n’a pas conscience des architectures techniques qui font tourner leurs applications. Conséquence : ils ne maitrisent pas l’impact des plans d’exécution de leurs requêtes. En raison d’une requête mal paramétrée, un simple bouton utilisateur (« récupérer une facture » ou « ouvrir une fiche client ») mettra ainsi à genou la performance globale d’un système. Soit parce qu’il génère jusqu’à 3 000 lignes de code SQL, soit parce qu’il entraîne le balayement systématique et continu d’une base de 100 teraoctets.

La problématique de la performance des applications est donc d’abord celle d’un code ignorant les infrastructures en présence. Ce constat s’inscrit malheureusement dans la tendance actuelle de banalisation, voire de négligence des couches basses. Et ce au profit des seules applications, jugées plus critiques. L’absence de formations autour de SQL illustre cette désaffection pour le « middleware » (couches logicielles intermédiaires).

Une situation paradoxale

Car la prise en considération de ces éléments d’infrastructure n’aura jamais été aussi nécessaire. Surtout depuis les dernières versions, particulièrement enrichies, des bases de données. Celles-ci offrent par exemple nativement des modes « multi-tenant » : une seule et même base sait faire tourner plusieurs instances totalement isolées les unes des autres (un environnement pour la production, un autre pour les tests, un troisième pour la formation…). De la même façon, les bases de données parviennent aujourd’hui à remonter le temps, et à rejouer l’ensemble des transactions. On leur demande également de tourner 24 heures sur 24 sans jamais s’arrêter…

Ces enrichissements du « middleware » ne sont pas sans conséquence. Ils complexifient de plus belle l’alignement des applications sur les infrastructures. Peu permissives, ces nouvelles fonctions exigent, côté applications, des normes de développement et une qualité de code bien plus importantes que par le passé. De quoi contredire l’idée selon laquelle les couches basses se banalisent.

De quoi également tordre le cou à une autre contre-vérité, liée cette fois aux DBA (administrateurs de bases de données). Avec les nouveaux environnements « plug and play » des bases de données, certains voyaient leur métier menacé. Il n’en est rien : la prolifération des fonctions avancées de ces mêmes bases rend au contraire les DBA indispensables pour garantir un paramétrage optimal. Le niveau d’acquisition de leurs connaissances devient d’ailleurs de plus en plus élevé.

Le cloud et la virtualisation permettent bien aux entreprises de s’abstraire des couches d’infrastructure. Mais en partie seulement. Des compétences seront toujours nécessaires pour ajuster les applications et leur niveau de service attendu, aux architectures techniques. Sans quoi ces applications ne répondront jamais totalement à leurs promesses.