Dans un précédent billet, nous évoquions la notion de scalabilité, c’est à dire la capacité d’une application à maintenir son niveau de performance, par augmentation de la capacité de hardware, au fur et à mesure de l’augmentation de la fréquentation. La scalabilité verticale repose sur le changement de serveur pour un autre serveur plus puissant. La scalabilité horizontale, elle, repose sur l’augmentation du nombre de serveurs.

La scalabilité horizontale permet d’augmenter la capacité de l’application de manière quasi infinie. Mais que se passe-t-il lorsque la fréquentation diminue ? Lorsque la fréquentation est très irrégulière ? Lorsque que l’application devient plus efficace et nécessite moins de hardware pour soutenir la même charge ?

Du vécu : le gros arsenal attend la bataille

La scène se déroule autour d’une de ces petites tables rondes et haut perchées, que l’on trouve près des machines à café. Une développeur discute avec un copain de la ‘prod’.

Le copain de la ‘prod’

C’est quand même incroyable cette application. Tous les ans, on rajoute des serveurs. Et malgré tout, c’est pas toujours suffisant. L’année dernière, on croyait que ça allait passer. Mais 30 minutes avant la fin du délai, BOUM !

Le développeur, parlant des utilisateurs

C’est vrai. En même temps, ils sont de plus en plus nombreux à venir chaque année. Et en plus, ils font tous ça au dernier moment. Ils ont pratiquement 15 jours pour le faire, mais ils font ça le dernier jour. Non, c’est plutôt la dernière heure.

Le copain de la ‘prod’

Il y a une campagne de 15 jours tous les trimestres. Il nous faut 10 fois plus de serveurs pour tenir la dernière heure. Pendant pratiquement tout le trimestre, on a 20 serveurs qui ne font rien. Et pour tenir les 14 premiers jours, il suffirait de 3 serveurs.

Le développeur, se prenant à rêver

Ah ! Si on pouvait utiliser tous ces serveurs pour d’autres campagnes qui ont lieu en décalage …

Encore du vécu : réduire la consommation de hardware ne réduit pas les coûts ?!

La seconde scène se déroule dans une salle de réunion au sein d’une DSI.

Un consultant

Le nombre de serveurs d’applications semble très élevé en regard de la charge effective sur l’application Web. Avec un minimum d’optimisation et de refactoring, il devrait être possible de diviser le nombre de serveurs d’applications au moins par 2, voire par 4.

Le DSI

Quel intérêt ? De toute façon, nous avons déjà acquis les serveurs. Que nous nous en servions ou pas, ils coûtent le même prix.

Le consultant, quelque peu abasourdi, songe en lui même

Que répondre à ça ? Finalement, il n’a pas tort. Que pourrions nous faire des serveurs excédentaires ? Réattribuer les serveurs à d’autres applications ? Oui, mais vu le mode de coopération entre les études et la ‘prod’, faut pas trop rêver ! Pas le moment de faire la révolution.

Le consultant change alors habilement de sujet.

La scalabilité ne suffit pas

Dans l’un et l’autre cas, la scalabilité horizontale est pourtant là. Si l’on ajoute les serveurs qu’il faut, les applications tiennent bien la charge.

Oui, mais …

  • La première application dispose d’une capacité maximum figée, et bien que scalable, elle ne sait pas obtenir des serveurs supplémentaires pour tenir la dernière heure.
  • Et en cas d’activité plus faible, l’une et l’autre application ne savent pas restituer les serveurs excédentaires et les mettre à disposition d’autres applications.

Ce que nous serions en droit de vouloir ici pour nos applications s’appelle l’élasticité, c’est dire la capacité à octroyer et à restituer, à la demande, de la capacité hardware.

C’est l’une des caractéristiques du cloud. Mais, c’est une autre histoire …