Fünf Fragen, die bei deiner Plattformbewertung fehlen

Vor Jahren war ich bei einer Plattformbewertung mit einem Kunden dabei, der 45 Minuten des Meetings damit verbrachte, sich auf eine Sache zu konzentrieren: sein maßgeschneidertes PHP-Content-Management-System.

Er hatte eine Meinung zu diesem CMS. Eine sehr ausgeprägte Meinung. Er hatte Benchmarks, einen Migrationsplan, einen Proof of Concept. Er hatte ein Diagramm. Er hatte Fragen zur Deployment-Pipeline für dieses CMS, die für eine einzelne Anwendung gründlicher durchdacht waren als die gesamten Infrastrukturstrategien der meisten Unternehmen.

Später im Meeting fragte jemand, fast beiläufig, nach dem Rest ihres Stacks.

Wie sich herausstellte, hatten sie dreihundert weitere Anwendungen. On-Prem, AWS, Rackspace, einige davon liefen auf Servern, auf die seit Monaten niemand mehr zugegriffen hatte. Bei den meisten gab es keine Versionskontrolle. Wöchentliche Hotfixes in der Produktivumgebung. Irgendwo eine Wiki-Seite, die angeblich alle Umgebungen auflisten sollte und zuletzt 2018 bearbeitet worden war.

Bei der Evaluierung, die wir gerade durchführten, ging es um dieses eine CMS. Der Elefant in den nächsten vier Räumen waren die anderen dreihundert Apps.

Ich habe schon genug solcher Meetings mitgemacht, um ein Muster zu erkennen. Die Fragen, die darüber entscheiden, ob sich eine Plattformwahl langfristig bewährt, sind selten die Fragen, die bei der Evaluierung auftauchen. Hier sind fünf, die in deine nächste Plattform-Evaluierung gehören.

1. Wie viel Prozent deiner Anwendung können tatsächlich auf der Plattform laufen?

Nicht „Unterstützt die Plattform dieses Framework?“ Nicht „Gibt es eine Integration für deine Datenbank?“ Die konkrete Frage: Wenn du eine Karte deiner Anwendungen zeichnen würdest, wie viel davon könnte von der Plattform, die du bewertest, verwaltet werden, und wie viel ist über Marktplatz-Konnektoren integriert, von deinem DevOps-Team verkabelt oder befindet sich in einem cloud-Konto, das die Plattform nicht sieht?

Die meisten Plattformen decken einen erkennbaren Teil ab. Dieser Teil umfasst in der Regel die Anwendungslaufzeit, die Bereitstellungspipeline und eine verwaltete Rechenebene. Alles andere – Datenbanken, queues, Worker, Hintergrundjobs, Dienste in Sprachen, die die Plattform nicht ausführt – befindet sich woanders.

Der Prozentsatz der Anwendung auf der Plattform ist der Prozentsatz der Anwendung, der tatsächlich von den Vorteilen der Plattform profitiert. Den Rest musst du weiterhin selbst betreiben oder verwalten.

2. Wenn ein reviewer eine Preview-URL öffnet, sind die zugrunde liegenden Daten dann dieselben wie in der Produktivumgebung?

Vorschau-Umgebungen sind das tragende Element der modernen Entwicklererfahrung. Wenn sie funktionieren, werden Fehler bei der Überprüfung beseitigt. Wenn nicht, treten die Fehler vor den Augen der Kunden auf.

Der Test lautet nicht: „Lädt die Vorschau-URL?“ Jede kompetente Plattform macht das richtig. Der Test ist, ob die Dienste und Daten hinter der Vorschau gut genug mit der Produktivumgebung übereinstimmen, dass ein reviewer ohne zu raten antworten kann: „Funktioniert das?“ Für die meisten Teams auf den meisten Plattformen lautet die ehrliche Antwort heute: „Das Programm funktioniert, die Daten nicht, und viel Glück beim Erkennen des Unterschieds.“

3. Wenn ein Kunde dich bitten würde, auf einer bestimmten cloud oder in einer bestimmten Region zu laufen, wie lange würde dieses Projekt dauern?

Heute vielleicht noch nicht. Aber irgendwann, wenn deine Roadmap regulierte Kunden, Unternehmensbeschaffung, Anforderungen für bestimmte Regionen oder einen CFO beinhaltet, der möchte, dass cloud-Ausgaben auf eine Committed-Use-Vereinbarung angerechnet werden, wird jemand fragen: „Kannst du in eu-west-1 laufen?“ „Kannst du AWS nicht nutzen, weil unser größter Kunde mit Amazon konkurriert?“ „Können wir das über unser Azure-Marketplace-Commitment bezahlen?“

Wenn die Antwort lautet: „Wir müssten die Plattform wechseln“, dreht sich das nächste Gespräch darum, ob der Deal die vierteljährige Migration wert ist. Dieses Gespräch sollte besser geführt werden, bevor der Deal auf dem Tisch liegt, als währenddessen.

4. Was fällt in den Umfang deiner nächsten Compliance-Prüfung, und was gehört dazu?

Compliance-Zertifizierungen sind Umfangserklärungen. Die Frage lautet nicht: „Haben wir SOC 2?“ Die Frage ist, welche Kontrollen für welche Systeme gelten und wo die Grenze verläuft.

Plattformen regeln, was sie verwalten. Die Governance-Grenze für die meisten Plattformen ist die verwaltete Rechenebene. Wenn deine Anwendung größer ist als das – was meistens der Fall ist –, werden die Teile außerhalb der Plattformgrenze durch das geregelt, was das Team sonst noch zusammengestellt hat, separat geprüft oder stillschweigend gar nicht geprüft.

Der Prüfungsumfang sollte mit dem Architekturdiagramm übereinstimmen. Wenn das nicht der Fall ist, wird die Prüfung genau an dieser Lücke teuer.

5. Wenn du nächste Woche einen neuen Ingenieur einstellen würdest, wie viele Bereitstellungssysteme müsste er lernen?

Das ist die kulturelle Frage. Es ist auch die Frage der Einstellung, der Einarbeitung und der Mitarbeiterbindung – in dieser Reihenfolge.

Das Frontend-Team hat fast immer einen modernen Workflow. Das Backend-Team oft nicht. Das Datenteam in der Regel nicht. Das ML-Team definitiv nicht. Wenn ein neuer Entwickler drei verschiedene Deployment-Modelle lernen muss, um sein erstes Feature zu veröffentlichen, ist die Wahl der Plattform nicht nur eine technische Entscheidung. Sie prägt die Entwicklererfahrung aller, die du in den nächsten drei Jahren einstellen wirst.

Ein einziger Workflow für jede Laufzeit ist ebenso sehr eine Teamentscheidung wie eine technische.

Der Test für jede Frage

Für jede der fünf Fragen gibt es einen einfachen Test. Kannst du die Frage klar und ohne ein „kommt drauf an“ in weniger als dreißig Sekunden beantworten?

Wenn ja, weißt du, wo du stehst. Wenn nein, ist die Frage, wo die Arbeit liegt. Das ist keine Krise. Es ist einfach der Umfang eures nächsten internen Gesprächs, bevor sich die Plattformwahl zu etwas verfestigt, das schwerer zu ändern ist.

Der Kunde, der dieses CMS evaluierte – der mit den dreihundert anderen Apps –, hat diese fünf Fragen in dem Meeting, an dem ich teilnahm, nicht durchgearbeitet. Sie haben sie später widerwillig durchgearbeitet, nachdem jemand aus ihrem eigenen Team den Umfang in Frage gestellt hatte. Das CMS bekam eine gute Plattform. Die dreihundert Apps bekamen ein mehrjähriges Projekt, um von der Hotfix-Tabelle wegzukommen. Die CMS-Entscheidung war in Ordnung. Es war nur nicht die Entscheidung, die sie eigentlich hätten treffen müssen.

Bei den meisten Plattformbewertungen geht es um die eine App im Raum. Bei den fünf Fragen geht es um die anderen dreihundert.

Such dir deine Wochen aus.

Weiterführende Lektüre

Wenn dir das einleuchtet, geht der nächste Teil dieser Serie tief auf Frage zwei ein: warum Preview-Umgebungen, die richtig aussehen, es oft nicht sind, und was das Byte-für-Byte-Klonen tatsächlich am Review-Prozess verändert.

Referenzen

• Upsun-Plattformübersicht
• Upsun-Umgebungen und Byte-für-Byte-Klonen
• Vercel-Plattformdokumentation
• Sicherheit und Compliance bei Vercel