Niesamowicie dokładne i trafne porównanie⁰ między @aws a @vercel, z doświadczenia migracji aplikacji produkcyjnej już działającej w @aws, zarządzanej przez ekspertów. Chociaż oczywiście miło jest wygrywać w takich porównaniach, moją absolutnie ulubioną częścią jest jego konkluzja: > Ostatecznie, po przeprowadzeniu kilku testów w celu zminimalizowania ryzyka, przenieśliśmy naszą całą aplikację do Vercel w jeden weekend i usunęliśmy wiele zbędnego kodu. Kiedy teraz patrzymy na nasze repozytorium, to 99% to nasza aplikacja, a 1% to infrastruktura. To nas uszczęśliwia. To jest moc infrastruktury zdefiniowanej przez frameworki (FdI)¹. "Błąd", który popełniły chmury, polega na tym, że ich punkt wejścia do budowania stał się… ich infrastruktura. Dla @vercel to frameworki. SvelteKit, Nitro, Next.js są na bieżąco przekształcane w infrastrukturę. Modne jest, aby dostawcy rzucali terminem "lock-in", ale tak naprawdę istnieje dokładny sposób na jego pomiar. Nie musisz wierzyć mi na słowo. Policz, ile razy "importujesz" lub odnosisz się do API czasu wykonania, które są specyficzne dla dostawcy chmury w swoim kodzie (np.: Magic Objects, magiczne "env.*", magiczne "bindings", itd.) Jeśli trzymasz się kodu frameworka, możesz przenosić obciążenie, stąd satysfakcjonujące '1%' powyżej. Na koniec, oczywiście jesteśmy dumni, że budujemy na fundamentach @aws. EC2, S3 i jego globalna sieć są bezkonkurencyjne. Przerwy w działaniu są praktycznie nieistniejące. "Przekierowywanie POP" to nie jest problem. Nie ma "sieci niskiej jakości", tylko najlepsza prywatna sieć światłowodowa, 24x7x365. Nasze zobowiązanie wobec naszych klientów i społeczności to kontynuowanie budowy otwartych SDK² oraz stworzenie jak najlepszego autonomicznego chmury dla nich, na najwyższej wydajności 'sprzęcie', jaki możemy znaleźć. ⁰ ¹ ²