On ne peut pas virtualiser cela !

En informatique, nous y sommes confrontés en permanence : un fournisseur nous affirme qu'un système ne peut pas être virtualisé. Les raisons invoquées sont nombreuses. Du côté de l'informatique, nous sommes toujours stupéfaits qu'un fournisseur puisse formuler une affirmation aussi extravagante ; et bien souvent, nous sommes tout aussi stupéfaits qu'un client (ou un responsable) y croie. Les fournisseurs ont travaillé d'arrache-pied pour perfectionner cet argumentaire de vente au fil des ans, et je pense qu'il est important de le décortiquer.

La cause profonde de ces problèmes tient au fait que les fournisseurs cherchent presque toujours des moyens de réduire leurs propres coûts tout en augmentant les profits qu'ils tirent de leurs clients. Cela explique une grande partie de ce qui, autrement, serait perçu comme un comportement étrange.

Une chose que de très, très nombreux fournisseurs tentent de faire est de limiter les scénarios dans lesquels leur produit sera pris en charge. Ce faisant, ils se préparent à pouvoir tout simplement ne pas fournir d'assistance – l'assistance coûte cher et n'est pas fiable. C'est une stratégie courante. Dans certains cas, elle est si agressive qu'aucun scénario de déploiement en production acceptable n'existe même.

Un moyen très répandu d'y parvenir consiste à ne prendre en charge aucun système d'exploitation pris en charge, ce qui revient de fait à rendre obsolète le propre logiciel du fournisseur (par exemple, aujourd'hui, cela signifierait ne prendre en charge que Windows XP et les versions antérieures). Un autre exemple consiste à ne prendre en charge que des produits qui ne sont pas sous licence pour le cas d'usage concerné (par exemple, exiger qu'un produit comme Windows 10 soit utilisé en tant que serveur). Et l'un des cas les plus fréquents est l'interdiction de la virtualisation.

Ces scénarios placent les clients dans des positions difficiles, car d'un côté ils doivent respecter les meilleures pratiques du secteur, les directives de déploiement standard, leur outillage interne et leurs politiques ; et de l'autre, ils ont affaire à des fournisseurs qui interdisent souvent une conception, une planification et une gestion appropriées des systèmes. Ces exigences sont en contradiction les unes avec les autres.

Bien entendu, personne ne s'attend à ce que chaque fournisseur prenne en charge tous les scénarios possibles. Des limites doivent être appliquées. Mais il existe un gouffre immense entre la prise en charge de systèmes raisonnables et bien déployés et l'exigence active de déploiements inacceptablement mauvais. Nous espérons que nos fournisseurs se comporteront comme des partenaires commerciaux et partageront un intérêt commun pour notre réussite ou, à tout le moins, pour la réussite de leur produit, et qu'ils ne chercheront pas directement à saper ces deux objectifs. Nous espérons qu'au strict minimum, une assistance au mieux des efforts serait fournie pour tout scénario de déploiement raisonnable et qu'une assistance garantie serait vraisemblablement proposée pour des scénarios correctement conçus, conformes aux meilleures pratiques.

Imaginez un monde où respecter les limitations de vitesse et porter votre ceinture de sécurité annulerait la garantie de votre voiture, et où vous ne bénéficieriez d'une assistance que si vous conduisiez de façon imprudente et sans protection !

Il est nécessaire de bien comprendre certains points importants au sujet de la virtualisation. Le premier est que la virtualisation est une meilleure pratique de longue date dans le secteur et qu'elle est censée être utilisée dans tout scénario de déploiement en production de services. La virtualisation n'a rien de nouveau ; même sur le marché des petites entreprises, elle fait partie des meilleures pratiques depuis bien plus d'une décennie maintenant, et depuis plusieurs décennies dans le domaine des grandes entreprises. Nous avons largement dépassé le point où l'exécution de systèmes non virtualisés est considérée comme acceptable, et cela inclut les déploiements hérités en place depuis longtemps.

Il existe bien sûr toujours de rares exceptions à presque toutes les règles. Certains systèmes nécessitent l'accès à du matériel très particulier et la virtualisation peut alors ne pas être possible, même si, avec la transmission matérielle (passthrough) moderne, cela est aujourd'hui pour ainsi dire inconnu. Et certains systèmes à très faible latence ne peuvent pas être virtualisés, mais ceux-ci se limitent normalement aux plus grandes banques d'investissement internationales et aux fonds spéculatifs les plus agressifs, et même la majorité de ces cas d'usage traditionnels ont été éliminés par les améliorations apportées à la virtualisation, rendant même ces situations rares. Mais en fin de compte, si vous ne pouvez pas virtualiser, vous devriez le déplorer, et vous saurez clairement pourquoi c'est impossible dans votre situation. Dans tous les autres cas, votre serveur doit être virtuel.

N'est-ce pas important ?

Si un fournisseur ne vous autorise pas à suivre les meilleures pratiques standard pour des déploiements sains, que cela révèle-t-il de l'opinion que le fournisseur a de son propre produit ? S'il s'agissait de n'importe quel autre déploiement, nous nous demanderions immédiatement pourquoi nous déployons un système de manière aussi médiocre si nous comptons en dépendre. Si notre fournisseur nous contraint à agir de la sorte, nous devrions réagir de la même manière – si le fournisseur ne prend pas son produit aussi au sérieux que nous prenons le moindre de nos services informatiques, pourquoi le ferions-nous ?

Il s'agit d'une « inadéquation d'impédance », comme nous le disons dans les cercles d'ingénierie, entre nos besoins (des systèmes de production) et la façon dont le fournisseur qui fabrique ce système semble les considérer (des systèmes de loisir ou de divertissement). Si nous devons dépendre de ce produit pour nos entreprises, il nous faut un fournisseur qui adhère à cette vision et comprend les besoins des entreprises – qui a un état d'esprit orienté production. Si le produit n'est pas destiné aux entreprises ou n'est pas prêt pour elles, nous devons en être conscients. Nous devons nous demander pourquoi nous estimons devoir utiliser en production, en en dépendant et en exigeant une assistance, un service qui n'est pas censé être utilisé de cette manière.

Est-il pris en charge ? Est-il testé ?

Un aspect souvent négligé du point de vue des clients est de savoir si les ressources d'assistance nécessaires à un produit sont en place ou non. Il n'est pas rare que l'équipe qui prend en charge un produit se réduise, voire disparaisse, mais que l'entreprise continue de vendre le produit dans l'espoir d'en tirer le maximum, en pariant sur le fait de se débrouiller tant bien que mal face à un problème ou simplement de rembourser les clients si le fournisseur se retrouve dans une situation où il est tout bonnement incapable de l'assister.

La plupart des contrats logiciels stipulent que le dommage maximal pouvant être réclamé au fournisseur correspond au coût du produit, c'est-à-dire au montant dépensé pour l'acquérir. Dans un cas comme celui-ci, le fournisseur ne court aucun risque en proposant un produit qu'il ne peut pas prendre en charge – même s'il facture l'assistance au prix fort. Si le client parvient à utiliser le produit, tant mieux, le fournisseur est payé. Si le client n'y parvient pas et que le fournisseur ne peut pas l'assister, le fournisseur ne perd que de l'argent qu'il n'aurait de toute façon jamais obtenu. Le client assume la totalité du risque, et non le fournisseur.

Cela laisse bien sûr supposer qu'il n'existe que peu ou pas de tests continus du produit, ce qui devrait constituer une préoccupation supplémentaire. Le simple fait que le produit fonctionne ne signifie pas qu'il continuera de fonctionner. Mettre en service un produit non pris en charge, ou pire, impossible à prendre en charge, signifie que vous dépendez de plus en plus, au fil du temps, d'un produit dont le niveau d'assistance potentielle est susceptible de diminuer, se dégradant lentement avec le temps alors même que le besoin d'assistance et la dépendance au logiciel devraient, eux, augmenter.

Si un produit propriétaire est déployé en production et que la décision est prise de renoncer aux déploiements conformes aux meilleures pratiques afin de satisfaire aux exigences d'assistance, comment cela peut-il s'intégrer dans une matrice de décision ? Cela doit-il laisser entendre qu'une assistance appropriée n'existe pas ? Là encore, comme précédemment, cela traduit une inadéquation avec nos besoins.

 

Est-il toujours en cours de développement ?

Si les besoins de déploiement du logiciel reposent sur des pratiques anciennes et dépassées, ou exigent des logiciels ou une conception obsolètes (ou pas raisonnablement à jour), alors nous devons nous interroger sur la probabilité que le produit soit actuellement en cours de développement. Dans certains cas, nous pouvons le déterminer en observant le cycle de publication du logiciel pendant un certain temps, mais pas dans tous les cas. Il existe une crainte raisonnable que le produit soit mort, sans plus aucune équipe de développement travaillant dessus. Le code peut simplement être ancien, une dette technique vendue dans l'espoir de gagner les derniers dollars sur une base de code ancienne et abandonnée. Ce processus est en réalité bien plus répandu qu'on ne le croit souvent.

Les petits éditeurs de logiciels parviennent souvent à développer un premier produit logiciel, à le mettre sur le marché et à le proposer à la vente, mais n'ont pas les moyens de conserver leur équipe de développement ou de la reconstituer après la ou les premières versions. C'est en fait un scénario très courant. Cela laisse les clients avec un produit dont on s'attend à ce qu'il devienne de moins en moins viable au fil du temps, avec des scénarios de déploiement de plus en plus risqués et des données de plus en plus difficiles à extraire.

 

Comment peut-il être pris en charge si la plateforme ne l'est pas ?

Un paradoxe courant de certaines situations plus extrêmes concerne les logiciels qui, pour être considérés comme « pris en charge », exigent d'autres logiciels qui ne sont soit plus pris en charge, soit n'ont jamais été pris en charge pour le cas d'usage prévu. Des exemples courants en sont l'exigence qu'un système serveur soit exécuté par-dessus un système d'exploitation de bureau, ou l'exigence de versions de systèmes d'exploitation, de bases de données ou d'autres composants qui ne sont plus du tout prises en charge. Ce dernier scénario est terriblement fréquent. Dans une situation de ce genre, on doit se demander s'il peut seulement exister un déploiement dans lequel le logiciel pourrait être considéré comme « pris en charge » ? Si une partie de la pile est toujours hors de la prise en charge, alors la pile entière n'est pas prise en charge. Il y aurait toujours une raison pour laquelle l'assistance pourrait être refusée, quoi qu'il arrive. La raison même qui nous pousserait donc à exiger d'éviter les meilleures pratiques exclurait tout autant de choisir le logiciel lui-même en premier lieu.

Manque-t-on de compétences et de connaissances dans le secteur ?

Peut-être que le problème auquel nous sommes confrontés avec des difficultés de prise en charge logicielle de cette nature tient simplement au fait que la ou les équipes qui créent le logiciel ne savent tout bonnement pas comment on conçoit un bon logiciel et/ou comment on déploie de bons systèmes. C'est l'une des raisons les plus raisonnables et les plus valables susceptibles de nous conduire à cette situation. Mais, comme les autres hypothèses, elle nous laisse inquiets quant à la qualité du logiciel et à la possibilité qu'une assistance soit réellement disponible. Si nous ne pouvons pas faire confiance au fournisseur pour gérer correctement les parties les plus visibles du système, pourquoi nous tournerions-nous vers lui comme expert pour les parties que nous ne pouvons pas vérifier ?

Le grand problème

Le grand problème, le problème de fond, des logiciels dont les exigences en matière de pratiques de déploiement et de maintenance sont discutables en échange du déverrouillage d'une assistance autrement retenue, n'est pas, comme nous le supposons habituellement, une question de qualité globale du logiciel, mais bien une question de viabilité des pratiques d'assistance et de développement. Le fait que ces problèmes traduisent une préoccupation importante pour l'assistance à long terme devrait nous amener à nous demander avec force pourquoi nous choisissons ces produits en premier lieu tout en attendant d'eux une assistance solide alors que, dès le départ, nous avons des préoccupations très visibles et très sérieuses.

Il existe bien sûr des cas où aucun autre produit logiciel n'existe pour répondre à un besoin, ou aucun dont la viabilité soit plus raisonnable. Cette situation devrait être extrêmement rare et, si elle se présente, devrait être perçue comme une opportunité majeure de marché pour un fournisseur souhaitant entrer sur ce créneau particulier.

D'un point de vue commercial, il est impératif que les meilleures pratiques de l'infrastructure technique ne soient pas totalement ignorées en échange d'un suivi aveugle ou quasi aveugle d'exigences de fournisseurs qui, dans toute autre circonstance, seraient considérées comme imprudentes ou non professionnelles. Pourquoi négligeons-nous si souvent d'exiger l'excellence des produits essentiels dont nos entreprises dépendent de cette façon ? Cela met nos entreprises en danger, non seulement du fait de l'action elle-même, mais bien davantage encore du fait des risques qu'implique l'existence même d'une telle exigence.