Rendre le simple trivial et le complexe possible

Ceci fait partie d'une série sur certains de nos principes de conception et, plus généralement, sur l'infrastructure composable.

Je commencerai par une liste tirée textuellement d'un document de conception auquel j'ai contribué en travaillant sur Upsun il y a quelques mois :

Pour être clair, il s'agissait davantage d'un rappel à moi-même que d'un ordre transmis. Le travail sur Upsun a été fascinant pour moi. Pour la première fois depuis très longtemps, nous étions capables de nous libérer des chaînes d'un autre article de foi , Never Break BC.

Ce dernier, la compatibilité ascendante, est probablement le plus important lorsque vous vous souciez de la robustesse et du temps de fonctionnement. Et c 'est ce que nous faisons.

Mais Upsun est un nouveau produit. Il n'y a pas encore de clients en production. Nous pouvons faire des folies.

Des choses qui fonctionnent

En tant que PaaS, une grande partie de notre travail se concentre sur la création d'une infrastructure qui fonctionne tout simplement et qui est livrée avec un tas de cloches et de sifflets - des fonctions auxquelles nos utilisateurs n'auront plus jamais à penser. Par exemple, s'assurer que les sauvegardes peuvent réellement être restaurées. Qu'un service qui ne devrait pas être exposé à l'internet ne l'est pas. Et qu'un service qui devrait l'être l'est. Ou que tout fonctionne et s'adapte.

Tout cela constitue la ligne de base invisible. Si vous faites bien votre travail, les utilisateurs n'y prêteront plus attention. C'est le plus dur. Les opérations du deuxième jour. Et plus que tout, c'est ce qui nous importe.

Mais une partie du travail consiste à faire de la magie à un autre niveau, celui de l 'accueil initial.

Je sais à quel point j'ai apprécié la première fois que j'ai tapé vagrant et que j'ai eu une VM qui tournait une minute plus tard. Et même si cela m'a fait mal au début, le fait de taper une URL GitHub brute dans bash sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)", et d'avoir une belle configuration de ZSH avec tout ce que vous pouviez espérer, était une expérience alléchante.

Mais comme toujours avec les logiciels, tout a une contrepartie. Dans un prochain billet, je parlerai de la malédiction des valeurs par défaut. Pour l'instant, je dirai simplement que nous avons choisi de créer plus de frictions lors de l'intégration. Non pas parce que nous aimons torturer les gens, mais parce que nous préférons que les utilisateurs fassent un peu plus de travail en amont et beaucoup moins de travail en aval.

Nous avons donc choisi de configurer explicitement l'application. Vous ne pouvez pas simplement taper upsun up. Les utilisateurs doivent ajouter un fichier de configuration - un fichier qui définira explicitement le comportement de l'infrastructure qui sera déployée - au dépôt, le valider et le pousser.

Voici le YAML

Maintenant, nous ne sommes pas de mauvaises personnes, donc la chose la plus minimale qui serait déployée n'est pas si complexe.

.upsun/config.yaml

applications : app : type : nodejs:20

Cela ne fera pas grand chose cependant. Vous pouvez pousser ceci et vous aurez un conteneur fonctionnant dans l'éther. Mais il ne servira aucune requête http. Pour avoir un peu de joie, vous devriez ajouter :

.upsun/config.yaml

applications : app : type : nodejs:20 web : locations : '/' :
 index : - index.html

Voilà. Si vous avez un index.html à la racine de votre repo, lorsque vous le pousserez vers Upsun, vous obtiendrez une URL en retour. Elle sera en ligne. Et tout se passera bien. Au fait, si vous êtes trop fatigué (je sais que je le suis souvent) pour écrire YAML à la main, vous pouvez aussi utiliser "upsun ify" et le CLI en générera un pour vous. Comme je l'ai dit, nous ne sommes pas méchants.

A partir de ce petit extrait, vous pouvez déjà comprendre pas mal de choses. Et peut-être encore plus sur la raison pour laquelle nous aimons l'explicitation.

• Les applications sont un pluriel. *
• Une application a un nom explicite et un type explicite.

Mais on peut se poser la question. Pourquoi une configuration explicite ? Quand on y réfléchit, c'est simple. On ne peut pas le comprendre ? Je veux dire, "index.html", qu'est-ce que ça pourrait être ? "thingamebob.burp" ?

Il s'agit de rendre les choses aussi simples qu'elles peuvent l'être, mais pas plus.

• Si vous n'avez pas de runtime explicite, soit Node.js doit être bloqué à une version ancienne, soit vous risquez la casse lors d'une mise à jour implicite.
• Si vous ne donnez pas de nom à l'application, vous ne pourrez pas en déployer une deuxième dans le même environnement. Et vous ne pourriez pas avoir de règles de routage astucieuses pour votre configuration multi-applications/microservices.
• Et pourquoi un bloc de localisation? Peut-être qu'il pourrait y en avoir un par défaut. Ce n'est pas clair. Mais alors il faudrait que ce soit la racine du repo. Et cela semble être une valeur par défaut peu sûre. Nous péchons par excès de prudence. Dans les versions précédentes, vous n'aviez pas non plus d'itinéraires par défaut. Mais il semblait assez raisonnable d'imaginer que si vous ne déployez qu'une seule application, vous aimeriez probablement qu'elle ait une route d'entrée.

Il y a des valeurs par défaut qui sont définies ici. Et vous verrez tout ce que nous avons défini comme valeurs par défaut quand vous pousserez le repo :

• Par exemple "Comme aucune configuration de route n'a été détectée, une seule route par défaut sera déployée." Si vous aviez deux applications, nous ferions une erreur et vous forcerions à faire un choix de routage.
• Ou "Environment configuration : app (type : nodejs:20, cpu : 0.5, memory : 224)"

C'est l'autre côté de l'histoire de l'explicitation. Il est souvent bon de faire des choix raisonnables. Mais il est vital de donner à l'utilisateur un retour d'information sur ces choix. Ainsi, l'utilisateur sait qu'il peut passer outre.

Il existe encore d'autres choix possibles. Le bloc "locations" est une véritable bête. Vous pouvez y faire de la réécriture d'URL. Configurer la mise en cache des actifs statiques. Contrôler la mise en mémoire tampon et les en-têtes personnalisés (mieux servis avec les routes websocket). Mais c'est probablement pour le deuxième jour de configuration. C'est de cela qu'il s'agit lorsque l'on veut rendre la complexité possible. Lorsque vous disposez d'une configuration explicite, vous disposez également d'un moyen d'outrepasser tout comportement par défaut. Mais vous pouvez aussi reporter la complexité au moment où vous en aurez besoin.

Lorsque vous n'avez besoin que de simplicité, la configuration doit être triviale. Et, avec un peu de chance, le YAML ci-dessus n'est pas écrasant.

Mais lorsque vous voulez utiliser toute la puissance de la plateforme - exécuter plusieurs applications avec des relations complexes entre elles, faire fonctionner un tas de bases de données et de files de messages - nous voulons que cela soit aussi simple que possible. Nous devons trouver un équilibre.

Trop simple maintenant, c'est trop complexe plus tard

Si vous examinez un service où le déploiement d'une seule application ne nécessite aucune configuration, vous découvrirez également qu'il est impossible ou difficile de déployer plusieurs applications en une seule commande. Vous découvrirez que la création d'un environnement de prévisualisationcohérent - quicontient toutes les données de tous les services - est soit difficile, soit impossible. Parfois, l'apparente simplicité d'aujourd'hui est l'horrible complexité de demain.

Ces principes de conception sont nos guides. Nous essayons d'y adhérer. Faire en sorte que tout soit aussi simple que possible. Mais pas plus simple. Même s'il y a des frictions à payer. Nous pensons toujours au deuxième jour. Nous pensons toujours au jour suivant, à la façon dont nous rendons les choses telles que nous n'aurons jamais à casser la CB. Mais ces jours-ci, nous sommes encore en version bêta ! Nous avons donc encore le droit de faire des changements. Et nous serions ravis de recevoir vos commentaires sur la façon dont vous trouvez notre format de configuration.

Vous pouvez aller sur docs.upsun.com pour une description complète et détaillée - et rejoindre notre discord pour discuter avec nous.