Unglaublich gründlicher und präziser Vergleich zwischen @aws und @vercel, basierend auf der Erfahrung mit der Migration einer Produktionsanwendung, die bereits in @aws betrieben wird und von Experten verwaltet wird. Während es offensichtlich schön ist, in diesen Vergleichen zu gewinnen, ist mein absoluter Lieblingsteil die Schlussfolgerung: > Letztendlich, nachdem wir ein paar Tests durchgeführt haben, um das Risiko zu minimieren, haben wir unsere gesamte Anwendung über ein Wochenende zu Vercel migriert und eine Menge überflüssigen Code gelöscht. Wenn wir uns jetzt unser Repository ansehen, sind 99% unsere Anwendung und 1% Infrastruktur. Das macht uns glücklich. Das ist die Kraft der Framework-definierten Infrastruktur (FdI). Der "Fehler", den die Clouds gemacht haben, ist, dass ihr Einstiegspunkt ins Bauen… ihre Infrastruktur wurde. Für @vercel sind es Frameworks. SvelteKit, Nitro, Next.js werden im Handumdrehen in Infrastruktur umgewandelt. Es ist in Mode, dass Anbieter den Begriff "Lock-in" verwenden, aber es gibt tatsächlich eine genaue Möglichkeit, dies zu messen. Sie müssen mir nicht glauben. Zählen Sie, wie oft Sie "importieren" oder runtime APIs, die spezifisch für Cloud-Anbieter sind, in Ihrem Code referenzieren (z.B.: Magic Objects, magic "env.*", magic "bindings", usw.) Wenn Sie sich an Framework-Code halten, können Sie die Arbeitslast verschieben, weshalb die '1%' oben so befriedigend ist. Zuletzt sind wir natürlich stolz darauf, auf den Grundlagen von @aws aufzubauen. EC2, S3 und sein globales Netzwerk sind unübertroffen. Ausfälle sind praktisch nicht existent. "POP-Umlenkung" ist kein Thema. Es gibt kein "Low-Tier-Netzwerk", nur das beste private Glasfasernetz, 24x7x365. Unser Engagement gegenüber unseren Kunden und der Community ist es, weiterhin Open SDKs zu entwickeln und die bestmögliche autonome Cloud für sie zu schaffen, auf der leistungsstärksten 'Hardware', die wir finden können. ⁰ ¹ ²