Bei kleinen Webprojekten steht oft die Frage im Raum: Serverless oder lieber ein klassischer VPS (z. B. DigitalOcean Droplet)? In meiner Praxis als Entwicklerin und Digitalstrategin habe ich beides ausprobiert — von statischen Seiten über kleine APIs bis hin zu Prototypen mit Datenbank-Anbindung. In diesem Artikel teile ich meine Erfahrungen und gebe konkrete Entscheidungshilfen: wann DigitalOcean (Droplets) sinnvoll sind, wann AWS-Serverless (Lambda, Fargate, App Runner) passt — und welche Kompromisse du eingehen musst.

Was meine ich mit "Serverless" und "Droplet"?

Serverless bedeutet hier: du schreibst Code, deployst ihn in eine verwaltete Umgebung (z. B. AWS Lambda, AWS Fargate, AWS App Runner, Vercel, Netlify) und kümmerst dich nicht um die darunterliegende Server-Instanz. Vorteile: automatische Skalierung, kein Server-Patching, nutzungsbasiertes Abrechnungsmodell.

Droplet steht stellvertretend für klassische VPS (Virtual Private Server), wie sie DigitalOcean anbietet. Du erhältst eine VM mit vordefinierten Ressourcen (CPU, RAM, Disk), installierst Services (NGINX, Node, PostgreSQL) und verwaltest das System selbst — oder mit Tools wie Docker und Ansible.

Die wichtigsten Entscheidungsfaktoren

Bei der Wahl spielen mehrere Kriterien eine Rolle. Ich schaue immer auf:

  • Projektgröße und Komplexität
  • Traffic-Prognose und Skalierbarkeit
  • Betriebskosten und Abrechnungsmodell
  • Deployment- und Entwicklererfahrung
  • Sicherheits- und Compliance-Anforderungen
  • Vendor-Lock-in und Portabilität

    • Kurzüberblick: Vor- und Nachteile

    Serverless (AWS Lambda, Fargate...)Droplet (DigitalOcean)
    Skalierung Automatisch, praktisch grenzenlos Manuell / via Autoscaling komplexer
    Kostenstruktur Pay-per-use (günstig bei wenig Nutzung) Fixkosten (gut bei konstanten Lasten)
    Betriebsaufwand Minimal (Managed) Höher (Systempflege, Patches)
    Cold Starts Problematisch bei latenzsensitiven Anwendungen Keine Cold Starts
    Portabilität Höherer Lock-in bei Cloud-Funktionen Hohe Portabilität (Docker, Standard-Linux)

    Wann ich Serverless empfehle

    Ich greife zu Serverless, wenn eines der folgenden Szenarien zutrifft:

  • Du betreibst eine kleine API, die unregelmäßigen Traffic hat — z. B. ein Prototyp oder ein Hobbyprojekt. Bei wenigen Requests/Tag ist Lambda meist günstiger als ein 5‑$‑Droplet.
  • Du willst schnell iterieren und dich nicht um Server-Setup kümmern. Deploy via AWS SAM, Serverless Framework, Vercel oder Netlify geht schnell.
  • Du erwartest spiky Traffic (z. B. Kampagnen, saisonale Last). Serverless skaliert automatisch.
  • Du möchtest Infrastrukturkosten senken und nur für Nutzung zahlen.

    • Praxisbeispiel: Ich habe eine kleine API für QR-Code-Generierung mit AWS Lambda und API Gateway gebaut. Bei sporadischen Anfragen war das extrem kosteneffizient und ich musste keine VM pflegen. Trotzdem musste ich die Cold-Start-Problematik mit Provisioned Concurrency und schlanken Lambda-Paketen adressieren.

    Wann ich DigitalOcean Droplets bevorzuge

    Droplets sind oft die bessere Wahl, wenn:

  • Du eine dauerhafte, vorhersehbare Last hast (z. B. ein kleines Produktiv-Frontend + Background-Jobs). Fixkosten können günstiger sein.
  • Dein Stack benötigt dauerhafte Prozesse oder Stateful Services (z. B. Redis, PostgreSQL, Worker mit lang laufenden Tasks).
  • Du brauchst volle Kontrolle über das OS, spezielle Kernel-Settings, oder du betreibst Legacy-Software.
  • Du willst die Komplexität niedrig halten: Ein einfacher NGINX + Node auf einem 5‑$‑Droplet reicht oft fürs MVP.

    • Beispiel: Für einen Kunden betreute ich ein CMS mit konstantem Traffic und mehreren Cron-Jobs. Ein DigitalOcean Droplet mit Docker Compose war einfacher und kostengünstiger als die aufwendige Serverless-Architektur, die ich zuerst erwog.

    Kosten: Rechnen hilft

    Generell gilt: Serverless ist günstig bei weniger und unregelmäßiger Nutzung; VPS ist günstiger bei konstanter Nutzung. Ein paar Faustregeln, die ich nutze:

  • Bei weniger als ~1.000 bis 5.000 Requests/Tag kann Lambda billiger sein — je nach Ausführungszeit.
  • Wenn deine Anwendung dauerhaft CPU- oder RAM-intensiv ist (z. B. Bildverarbeitung), rechnet sich oft ein Droplet.
  • Berücksichtige Zusatzkosten: API Gateway, NAT, Datenübertragungen (bei AWS können diese teuer werden).

    • Cold Starts, Latenz und Benutzererfahrung

    Serverless-Funktionen starten manchmal "kalt" — das verursacht Latenz. Für APIs mit niedrigen Latenzanforderungen nutze ich:

  • Provisioned Concurrency (AWS Lambda) oder Always-On-Instanzen bei anderen Anbietern.
  • Edge- oder CDN-Lösungen (Cloudflare Workers, Vercel Edge) für extrem niedrige Latenzen.

    • Wenn du eine interaktive Web-App betreibst, die schnelle Antworten braucht, ist ein Droplet oder ein Container auf Fargate/App Runner häufig die bessere Wahl.

    Dev-Experience: Deployments und Tooling

    Serverless-Deployments sind heute sehr komfortabel: Serverless Framework, Terraform, AWS SAM oder GitHub Actions integrieren sich gut. Für einfache Projekte mag Vercel oder Netlify sogar die einfachste Option sein — Git push und fertig.

    Droplets geben Flexibilität, aber du musst mehr managen: SSH, Firewall, Backups, Monitoring. Tools wie Docker + Docker Compose reduzieren die Komplexität; für Skalierung kannst du DigitalOcean Kubernetes (DOKS) nutzen — aber das ist Overkill für viele kleine Projekte.

    Vendor-Lock-in und Portabilität

    Ich achte stark auf Portabilität: Serverless-APIs, die stark AWS-spezifische Features (DynamoDB Streams, API Gateway Integrations) nutzen, sind schwerer zu migrieren. Wenn du die Möglichkeit einer späteren Migration offenhalten willst, schreibe möglichst generische Code-Basen (z. B. Container-basiert) oder nutze Open-Source-Tools (Postgres, Redis) statt proprietärer Dienste.

    Konkrete Entscheidungen — meine Faustregeln

  • Statisches Frontend + Formulare: Vercel/Netlify (Serverless/CDN) — keine Droplets nötig.
  • Sporadische API/Prototyp: AWS Lambda / API Gateway oder DigitalOcean App Platform — Serverless bevorzugt.
  • Konstante Web-App mit DB und Hintergrundjobs: DigitalOcean Droplet (oder ein verwalteter DB + Droplet für App).
  • Image-/Videoverarbeitung oder lange Tasks: Droplet oder Container auf Fargate/App Runner.
  • Schnelle Time-to-Market ohne Betriebserfahrung: Managed PaaS (Render, Heroku, DigitalOcean App Platform).

    • Tools & Services, die ich empfehle

  • AWS Lambda + API Gateway — stark, aber komplex in Preisstruktur.
  • AWS Fargate / App Runner — wenn du Container willst ohne Server-Management.
  • DigitalOcean Droplets — günstig, überschaubar, ideal für kleine dauerhafte Projekte.
  • DigitalOcean App Platform — ein Mittelding: PaaS-artig, weniger Betrieb als Droplet.
  • Vercel / Netlify — perfekt für JAMstack und Frontends.
  • Cloudflare Workers — extrem niedrige Latenz an der Edge für kleine Serverless-Funktionen.

    • Beim nächsten Projekt wäge ich kurz Traffic-Prognose, Persistenzbedarf und meine Bereitschaft, Betrieb zu übernehmen, ab. Oft genügt ein 1‑vCPU Droplet für MVPs, und wenn es wächst, verlagere ich kritische Services in Managed-Dienste oder skaliere auf Container-Plattformen.

    Wenn du möchtest, kann ich dir anhand deines konkreten Projekts eine kurze Entscheidungsmatrix erstellen — inklusive grober Kostenabschätzung und Recommended Tech Stack (z. B. Node + Postgres auf Droplet vs. Lambda + Aurora Serverless). Schreib mir kurz, was du bauen willst (Requests/Tag, lang laufende Jobs, Datenbankbedarf) und ich rechne das durch.