Das Einfache trivial und das Komplexe möglich machen

Dies ist Teil einer Serie über einige unserer Designprinzipien und, allgemeiner, über komponierbare Infrastrukturen.

Ich beginne mit einer Liste, die ich wortwörtlich aus einem Design-Dokument entnommen habe, an dem ich vor ein paar Monaten bei der Arbeit an Upsun mitgewirkt habe:

Um es klar zu sagen, dies war mehr eine Erinnerung an mich selbst, als dass ich etwas als Befehl weitergegeben hätte. Die Arbeit an Upsun war für mich faszinierend. Zum ersten Mal seit langer Zeit waren wir in der Lage, uns von den Fesseln eines anderen Glaubensartikels von Never Break BC zu befreien.

Dieser letzte Artikel, die Abwärtskompatibilität, ist möglicherweise der wichtigste, wenn man sich um Robustheit und Betriebszeit kümmert. Und das ist uns wichtig.

Aber Upsun ist ein neues Produktangebot. Es gibt noch keine Produktionskunden. Wir können uns austoben.

Dinge, die einfach funktionieren

Als PaaS konzentriert sich ein Großteil unserer Arbeit darauf, eine Infrastruktur zu schaffen, die einfach funktioniert und einen Haufen Schnickschnack mitbringt - Funktionen, über die unsere Benutzer nie wieder nachdenken müssen. So müssen wir beispielsweise sicherstellen, dass Backups tatsächlich wiederhergestellt werden können. Dass ein Dienst, der nicht dem Internet ausgesetzt sein sollte , dies auch nicht ist. Und dass ein Dienst, der es sein sollte , es ist. Oder dass alles brummt und skaliert.

All das ist die unsichtbare Grundlinie. Wenn Sie Ihre Arbeit gut machen, bemerken die Benutzer nichts davon. Das sind die schwierigen Dinge. Tag zwei des Betriebs. Und das ist es, was uns mehr als alles andere am Herzen liegt.

Aber ein Teil der Arbeit besteht darin, auf einer anderen Ebene für Magie zu sorgen - dem anfänglichen Onboarding.

Ich weiß, wie sehr ich es genossen habe, als ich das erste Mal vagrant eingegeben habe und eine Minute später eine VM lief. Und so sehr ich mich anfangs auch gegruselt habe, als ich eine unbearbeitete GitHub-URL in die Bash sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" eingegeben habe und ein wunderschönes ZSH-Setup mit allem, was man sich erhofft hatte, vorfand, war das eine verlockende Erfahrung.

Aber wie immer bei Software hat alles einen Kompromiss. In einem späteren Blogbeitrag werde ich auf den Fluch der Standardeinstellungen eingehen. Für den Moment möchte ich nur sagen, dass wir uns entschieden haben, mehr Reibung beim Onboarding zu erzeugen. Nicht, weil wir die Leute quälen wollen, sondern weil wir es vorziehen, dass die Benutzer im Vorfeld etwas mehr und später viel weniger Arbeit haben.

Deshalb haben wir uns für eine explizite Konfiguration der Anwendung entschieden. Man kann nicht einfach upsun eintippen. Die Benutzer müssen eine Konfigurationsdatei - eine Datei, die das Verhalten der Infrastruktur, die bereitgestellt wird, explizit definiert - zum Repository hinzufügen, übertragen und pushen.

Hier kommt die YAML

Nun, wir sind keine schlechten Menschen, also ist die minimalste Sache, die bereitgestellt werden würde, nicht so komplex.

.upsun/config.yaml

Anwendungen: app: Typ: nodejs:20

Das wird allerdings nicht viel bewirken. Sie können dies pushen und Sie haben einen Container im Äther laufen. Aber er wird keine http-Anfragen bedienen. Um etwas Freude zu haben, würde man hinzufügen:

.upsun/config.yaml

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

Voilà. Wenn Sie eine index.html in der Wurzel Ihres Repos haben, erhalten Sie eine URL zurück, wenn Sie sie zu Upsun pushen. Sie wird live sein. Und alles wird wunderbar sein. Übrigens, wenn Sie zu müde sind, um YAML von Hand zu schreiben (ich weiß, dass ich das oft bin), können Sie auch "upsun ify" verwenden und die CLI generiert es für Sie. Wie ich schon sagte, wir sind keine schlechten Menschen.

Aus diesem kleinen Schnipsel können Sie schon eine ganze Menge herauslesen. Und möglicherweise noch mehr darüber, warum wir Explizitheit mögen.

• Anwendungen ist ein Plural. *
• Eine Anwendung hat einen eindeutigen Namen und einen eindeutigen Typ.

Aber Sie könnten fragen. Warum eine explizite Konfiguration? Wenn man es sich ansieht, ist es ganz einfach. Können wir das nicht herausfinden? Ich meine "index.html" - was könnte das sein? "thingamebob.burp"?

Es geht darum, die Dinge so einfach wie möglich zu machen, aber nicht einfacher.

• Wenn Sie keine explizite Runtime haben, muss entweder Node.js auf einer uralten Version gesperrt werden oder Sie riskieren einen Bruch, wenn es implizit aktualisiert wird.
• Wenn Sie der Anwendung keinen Namen geben, können Sie keine zweite Anwendung in der gleichen Umgebung bereitstellen. Und Sie wären nicht in der Lage, raffinierte Routing-Regeln für Ihr Multi-App/Microservices-Setup zu erstellen.
• Und warum ein Standortblock? Vielleicht könnte es standardmäßig einen geben. Unklar. Aber dann müsste es das Stammverzeichnis des Repos sein. Und das klingt nach einer unsicheren Voreinstellung. Wir gehen eher auf Nummer sicher. In früheren Versionen gab es auch keine Standardrouten. Aber es schien vernünftig genug, sich vorzustellen, dass man, wenn man nur eine einzige Anwendung bereitstellt, wahrscheinlich eine Ingress-Route haben möchte.

Es gibt Standardwerte, die hier eingestellt sind. Und Sie werden alles sehen , was wir als Standardeinstellungen festgelegt haben, wenn Sie das Repo pushen:

• Zum Beispiel: "Da keine Routenkonfiguration gefunden wurde, wird eine einzelne Standardroute bereitgestellt." Wenn Sie zwei Anwendungen hätten, würden wir einen Fehler machen und Sie zwingen, sich für eine Route zu entscheiden.
• Oder "Umgebungskonfiguration: app (Typ: nodejs:20, cpu: 0.5, Speicher: 224)"

Das ist die andere Seite der Geschichte mit der Eindeutigkeit. Es ist oft in Ordnung, einige vernünftige Entscheidungen zu treffen. Aber es ist wichtig, dem Benutzer eine Rückmeldung über diese zu geben. So weiß man, dass man sie überschreiben kann.

Es gibt noch mehr Möglichkeiten, die Sie nutzen können. Der "Locations"-Block ist ein wahres Biest. Sie können dort URLs neu schreiben. Konfigurieren Sie die Zwischenspeicherung statischer Elemente. Pufferung und benutzerdefinierte Header steuern (am besten mit Websocket-Routen). Aber das ist wahrscheinlich für Tag zwei der Konfiguration. Genau darum geht es bei "Make the Complex Possible". Wenn Sie eine explizite Konfiguration haben, haben Sie auch die Möglichkeit, das Standardverhalten außer Kraft zu setzen. Aber Sie können die Komplexität auch auf den Zeitpunkt verschieben, zu dem Sie sie brauchen.

Wenn Sie nur Einfachheit brauchen, sollte die Konfiguration trivial sein. Und hoffentlich ist die obige YAML-Datei nicht überwältigend.

Aber wenn Sie die volle Leistung der Plattform nutzen wollen - mehrere Anwendungen mit komplexen Beziehungen zwischen ihnen, eine Reihe von Datenbanken und Nachrichtenwarteschlangen - dann soll auch das so einfach wie möglich sein. Wir müssen ein Gleichgewicht finden.

Was jetzt zu einfach ist, wird später zu komplex

Wenn Sie sich einen Dienst ansehen, bei dem die Bereitstellung einer einzelnen Anwendung keinerlei Konfiguration erfordert, werden Sie auch feststellen, dass es entweder unmöglich oder schwierig ist, mehrere Anwendungen mit einem einzigen Befehl bereitzustellen. Sie werden feststellen, dass die Erstellung einer konsistenten Vorschauumgebung, diealle Daten aller Dienste enthält, entweder schwierig oder unmöglich ist. Manchmal ist die scheinbare Einfachheit von heute die horrende Komplexität von morgen.

Diese Gestaltungsprinzipien sind unsere Leitplanken. Wir versuchen, uns an sie zu halten. Machen Sie alles so einfach, wie es nur geht. Aber nicht noch einfacher. Auch wenn es Reibungsverluste gibt. Wir denken immer an den zweiten Tag. Darüber, wie wir die Dinge so gestalten können, dass wir BC nie aufgeben müssen. Aber im Moment sind wir noch in der Beta-Phase! Wir dürfen also noch Änderungen vornehmen. Und wir würden uns über Feedback freuen, wie Sie unser Konfigurationsformat finden.

Ihr könnt auf docs.upsun.com eine vollständige, detaillierte Beschreibung finden - und unserem Discord beitreten, um mit uns zu chatten.