Un confronto incredibilmente approfondito e preciso tra @aws e @vercel, dall'esperienza di migrazione di un'applicazione in produzione già su @aws, gestita da esperti. Sebbene sia ovviamente bello vincere in questi confronti, la mia parte preferita è la sua conclusione: > In definitiva, dopo aver effettuato alcuni test per ridurre i rischi, abbiamo spostato l'intera applicazione su Vercel in un weekend e abbiamo eliminato molto codice superfluo. Quando guardiamo il nostro repository ora, è il 99% la nostra applicazione e l'1% infrastruttura. Questo ci rende felici. Questo è il potere dell'Infrastruttura definita dal Framework (FdI)¹. L'"errore" che hanno fatto le nuvole è stato che il loro punto di ingresso per costruire è diventato... la loro infrastruttura. Per @vercel, sono i framework. SvelteKit, Nitro, Next.js vengono convertiti in infrastruttura al volo. È di moda per i fornitori usare il termine "lock-in", ma c'è in realtà un modo esatto per misurarlo. Non devi prendere la mia parola per questo. Conta quante volte "importi" o fai riferimento a API di runtime specifiche del fornitore di cloud nel tuo codice (ad es.: Magic Objects, magic "env.*", magic "bindings", ecc.) Se ti attieni al codice del framework, allora puoi spostare il carico di lavoro, ecco perché l'1% sopra è così soddisfacente. Infine, ovviamente siamo orgogliosi di costruire sulle fondamenta di @aws. EC2, S3 e la sua rete globale sono senza pari. I guasti sono praticamente inesistenti. "POP re-routing" non è una cosa. Non c'è una "rete di basso livello", solo la migliore rete in fibra privata, 24x7x365. Il nostro impegno verso i nostri clienti e la comunità è di continuare a costruire Open SDKs² e creare il miglior cloud autonomo possibile per loro, sopra l'hardware di massima prestazione che possiamo trovare. ¹ ²