Cinq questions qui manquent dans ton évaluation de la plateforme

Il y a quelques années, j’ai assisté à une évaluation de plateforme avec un client qui a passé quarante-cinq minutes de la réunion à se concentrer sur une seule chose : son système de gestion de contenu PHP personnalisé.

Il avait des opinions sur ce CMS. Des opinions bien arrêtées. Il avait des benchmarks, un plan de migration, une preuve de concept. Il avait un schéma. Il avait des questions sur le pipeline de déploiement de ce CMS qui, pour une seule application, étaient plus approfondies que les stratégies d’infrastructure globales de la plupart des organisations.

Plus tard dans la réunion, quelqu’un a demandé, presque en passant, ce qu’il en était du reste de leur stack.

Et là, on a découvert qu’ils avaient trois cents autres applications. Sur site, sur AWS, sur Rackspace, certaines tournant sur des serveurs que personne n’avait touchés depuis des mois. Pas de contrôle de version sur la plupart d’entre elles. Des correctifs de production hebdomadaires. Une page wiki quelque part qui était censée répertorier tous les environnements et qui avait été modifiée pour la dernière fois en 2018.

L'évaluation sur laquelle on travaillait concernait ce CMS. L'éléphant dans les quatre pièces voisines, c'était les trois cents autres applications.

J'ai assisté à suffisamment de réunions de ce genre pour remarquer une tendance. Les questions qui déterminent si le choix d'une plateforme résiste à l'épreuve du temps sont rarement celles qui apparaissent dans l'évaluation. En voici cinq qui devraient figurer dans ta prochaine évaluation de plateforme.

1. Quel pourcentage de ton application peut réellement fonctionner sur la plateforme ?

Pas « la plateforme prend-elle en charge ce framework ? » Ni « dispose-t-elle d’une intégration pour ta base de données ? ». La question précise est la suivante : si tu dressais une carte de tes applications, quelle part de cette carte pourrait être gérée par la plateforme que tu évalues, et quelle part est intégrée via des connecteurs du marketplace, connectée par ton équipe DevOps, ou hébergée dans un compte cloud que la plateforme ne voit pas ?

La plupart des plateformes couvrent une partie identifiable. Cette partie comprend généralement le runtime de l’application, le pipeline de déploiement et une couche de calcul gérée. Tout le reste : bases de données, files d’attente, workers, tâches en arrière-plan, services dans des langages que la plateforme ne prend pas en charge, se trouve ailleurs.

Le pourcentage de l'application sur la plateforme correspond à la part de l'application qui bénéficie réellement des avantages de la plateforme. Le reste reste à ta charge pour l'exécution ou la gestion.

2. Lorsqu’un réviseur ouvre une URL de prévisualisation, les données sous-jacentes sont-elles les mêmes qu’en production ?

Les environnements de test sont la partie porteuse de l'expérience développeur moderne. S'ils fonctionnent, les bugs sont éliminés lors de la révision. S'ils ne fonctionnent pas, les bugs sont éliminés devant les clients.

Le test ne consiste pas à vérifier si « l’URL de prévisualisation se charge ». Toute plateforme compétente y parvient. Le test consiste à vérifier si les services et les données derrière la prévisualisation correspondent suffisamment bien à la production pour qu’un réviseur puisse répondre « est-ce que ça marche ? » sans avoir à deviner. Pour la plupart des équipes sur la plupart des plateformes aujourd’hui, la réponse honnête est « le code fonctionne, les données non, et bonne chance pour repérer la différence ».

3. Si un client te demandait de déployer sur un cloud ou une région spécifique, combien de temps ce projet prendrait-il ?

Pas aujourd’hui, peut-être. À un moment donné, si ta feuille de route inclut des clients soumis à une réglementation, des achats d’entreprise, des exigences de région souveraine ou un directeur financier qui souhaite que les dépenses cloud soient imputées à un contrat d’engagement d’utilisation, quelqu’un te posera la question. « Peux-tu fonctionner sur eu-west-1 ? » « Peux-tu ne pas utiliser AWS, car notre plus gros client est en concurrence avec Amazon ? » « Pouvons-nous payer cela via notre engagement Azure Marketplace ? »

Si la réponse est « il faudrait changer de plateforme », la conversation suivante portera sur la question de savoir si l’accord vaut la peine d’une migration qui prendrait un trimestre. C’est une conversation qu’il vaut mieux avoir avant que l’accord ne soit sur la table plutôt que pendant.

4. Quel est le périmètre de ton prochain audit de conformité, et qu’est-ce qui s’y rattache ?

Les certifications de conformité sont des déclarations de périmètre. La question n’est pas « avons-nous la certification SOC 2 ? ». La question est de savoir quels contrôles s’appliquent à quels systèmes, et où se situe la limite.

Les plateformes régissent ce qu’elles gèrent. La limite de gouvernance pour la plupart des plateformes est la couche de calcul gérée. Si ton application est plus grande que ça, ce qui est le cas pour la plupart, les parties situées en dehors de la limite de la plateforme sont régies par tout ce que l’équipe a mis en place, audité séparément, ou tout simplement pas audité du tout.

Le périmètre de l'audit doit correspondre au schéma d'architecture. Si ce n'est pas le cas, c'est l'écart entre les deux qui rend l'audit coûteux.

5. Si tu embauchais un nouvel ingénieur la semaine prochaine, combien de systèmes de déploiement devrait-il apprendre à maîtriser ?

C'est une question de culture. C'est aussi une question de recrutement, d'intégration et de fidélisation, dans cet ordre.

L'équipe front-end a presque toujours un processus moderne. L'équipe back-end n'en a souvent pas. L'équipe données n'en a généralement pas. L'équipe ML n'en a certainement pas. Si un nouvel ingénieur doit apprendre trois modèles de déploiement différents pour livrer sa première fonctionnalité, le choix de la plateforme n'est pas seulement une décision technique. Ça façonne l'expérience développeur de tous ceux que tu vas embaucher au cours des trois prochaines années.

Un processus unique pour chaque runtime est autant une décision d’équipe qu’une décision technique.

Le test pour chaque question

Pour chacune des cinq questions, il y a un test simple. Peux-tu répondre clairement à la question, sans dire « ça dépend », en moins de trente secondes ?

Si oui, tu sais où tu en es. Si non, la question est de savoir où se trouve le travail. Ce n’est pas une crise. C’est simplement l’objet de ta prochaine conversation interne, avant que le choix de la plateforme ne se cristallise en quelque chose de plus difficile à changer.

Le client qui évaluait ce CMS, celui qui avait trois cents autres applications, n’a pas abordé ces cinq questions lors de la réunion à laquelle j’assistais. Ils les ont abordées plus tard, à contrecœur, après qu’un membre de leur propre équipe ait contesté la portée du projet. Le CMS a obtenu une bonne plateforme. Les trois cents applications ont obtenu un projet pluriannuel pour migrer hors de la feuille de calcul des correctifs. La décision concernant le CMS était bonne. Ce n’était simplement pas la décision qu’ils devaient réellement prendre.

La plupart des évaluations de plateformes concernent l’application qui est dans la pièce. Les cinq questions concernent les trois cents autres.

Choisis tes semaines.

Lectures complémentaires

Si ça t'a interpellé, le prochain article de cette série approfondit la deuxième question : pourquoi les environnements de test qui semblent corrects ne le sont souvent pas, et ce que le clonage octet par octet change réellement dans le processus de révision.

Références

• Présentation de la plateforme Upsun
• Environnements Upsun et clonage octet par octet
• Documentation de la plateforme Vercel
• Sécurité et conformité Vercel