Gå til indholdet

05 — Google Cloud vs. Vercel + Convex

Hvor langt kan vi komme med Google Cloud i forhold til automatisk at bygge og deploye de samme ting, vi ellers ville bruge Vercel + Convex til? Fokus: kan GCP levere den samme AI-integrerbare "fabrik"?

Se også 06-isolation-hosting-og-overdragelse.md — bredere beslutningsgrundlag med isolation pr. kunde, priser (Vercel/Cloudflare/Cloud Run/Fly/Hetzner/K8s), AI-/MCP-styrbarhed og overdragelse/salgbarhed.

1. Kort svar

Ja — Google Cloud har en ækvivalent til hvert lag i Vercel+Convex-stakken, og på skalering og konsolidering er GCP stærkere. Prisen er udvikleroplevelsen: mere opsætning og drift, mindre "det bare virker" ud af boksen.

Til vores model — standardisere én fabrik og køre den igen og igen — taler konsolideringen (alt under ét cloud: hosting, DB, IAM, logging, BigQuery) for GCP på sigt. Men Vercel+Convex vinder klart på ren fart tidligt, hvor vi skal vise kunder noget hurtigt.

2. Lag-for-lag sammenligning

Lag Vercel + Convex Google Cloud-ækvivalent Vurdering
Frontend-hosting + auto-deploy fra git Vercel Firebase App Hosting (oven på Cloud Run) Tættest på Vercel. Git-baseret auto-deploy indbygget. Next.js SSR/App Router via nye deploy-adaptere (marts 2026) — lukkede Googles gamle svaghed.
Managed, reaktiv database Convex (reaktiv, TS-funktioner) Firestore (realtid) eller Data Connect (managed PostgreSQL) Firestores realtids-subscriptions ligner Convex mest; Data Connect giver "rigtig" Postgres. Begge har vector-search. Convex' TS-funktions-backend matches ikke 1:1.
Auth Convex Auth / Clerk / Auth.js Firebase Auth Modent, indbygget. Ingen reel svaghed.
Agent-orkestrering Vercel AI SDK 6 + Mastra Genkit Googles open source-framework (JS/Go/Python). Tool calling, structured output, RAG, human-in-the-loop og MCP. Ligeværdigt match.
Serverless compute / API Vercel Functions Cloud Run (+ Cloud Functions) Cloud Run mere fleksibel/skalerbar (containere, ingen framework-lock-in), men lidt mere opsætning.
CI/CD Vercel (indbygget) Cloud Build + git-triggers, eller App Hostings indbyggede Vercel nemmere; Cloud Build kraftfuldere/konfigurerbar.
Kodegenerering / prototyping v0 · Lovable · Bolt Firebase Studio ⚠️ Udfases 22. marts 2027; nye oprettelser lukket fra 22. juni 2026. Regn ikke med den.
Integrationslag MCP-server MCP via Genkit Begge understøtter MCP fuldt. Ingen principiel forskel.

3. Den vigtige advarsel: Firebase Studio

Googles "byg en fuld app automatisk med Gemini"-værktøj Firebase Studio (svarende til v0/Lovable/Bolt) udfases 22. marts 2027, og nye workspaces/signups er lukket fra 22. juni 2026.

Konsekvens: "generér app automatisk"-laget kan ikke baseres på Firebase Studio. Det skal komme fra generelle AI-kodeagenter (Claude Code / Cursor) oven på et template-repo — uanset Vercel eller GCP. Godt: agent + template er cloud-uafhængigt og fremtidssikret, hvor et enkelt leverandørværktøj kan forsvinde.

4. Hvor langt kommer vi med "byg og deploy automatisk"?

  • Byg + deploy: Næsten 1:1 med Vercel via Firebase App Hosting + Cloud Run + Cloud Build. Push → build → deploy. Next.js-adapterne (2026) gør server-side Next.js førsteklasses på GCP.
  • Backend + data + realtid: Dækket af Firestore / Data Connect inkl. vector-search (RAG i sync).
  • Agenter + MCP: Dækket af Genkit — den AI-integrerbare præmis holder fuldt på GCP.
  • Prototyping til salg: Brug v0/Lovable eller AI-kodeagenter — ikke Firebase Studio.

Hele "fabrikken" kan bygges på Google Cloud. Det manglende stykke er ikke teknisk kapabilitet, men den friktionsfrie udvikleroplevelse Vercel+Convex giver gratis.

5. Afvejning

Vercel + Convex vinder på: ren udviklerfart og zero-config (særligt tidligt), tættere integration mellem prototyping (v0), agenter (AI SDK) og hosting, lav mental belastning.

Google Cloud vinder på: skalering og prisstyring på volumen (Cloud Run, scale-to-zero), konsolidering (DB, hosting, IAM, logging, BigQuery ét sted), enterprise-troværdighed/compliance (salgsargument i visse nicher), ingen framework-lock-in.

Realistisk mellemvej: Vercel til frontend + Firebase/Google til backend, indtil volumen retfærdiggør at samle alt ét sted. Ikke alt-eller-intet fra dag ét.

6. Anbefaling for vores fabrik

  1. Start hvor farten er: Vercel + Convex (eller Vercel + Supabase/Neon) til de første pilotprojekter, hvor time-to-demo betyder mest.
  2. Hold stacken portabel: agenter med MCP + framework der findes begge steder i ånden (AI SDK/Mastra ↔ Genkit); forretningslogik i kode, ikke leverandør-specifikke træk → et senere skift til GCP bliver en portering, ikke en omskrivning.
  3. Overvej GCP som "skalerings-/enterprise-spor": ved enterprise-compliance, stor skala, eller når eget micro-SaaS vokser → Firebase App Hosting + Cloud Run + Firestore/Data Connect + Genkit.
  4. Brug aldrig Firebase Studio som fabrik-lag (udfases). Kodegenerering = AI-kodeagenter + template-repo.

7. Åbne spørgsmål

  1. Ét cloud eller to? Vercel+Convex for fart, GCP for konsolidering, eller bevidst hybrid?
  2. Postgres eller dokument-DB? Data Connect vs. Firestore på GCP (≈ Neon/Supabase vs. Convex på den anden side). Afgøres af de første projekters behov.
  3. Kompetence: GCP kræver mere DevOps-viden. Har/vil vi opbygge den, eller vejer Vercels enkelhed tungere for et to-mands-team?

Kilder