Docker vs Podman
In der Welt der Containerisierung tritt der Industriestandard Docker gegen das daemonlose Podman an. Wer setzt sich in puncto Sicherheit, Unternehmenskonformität und Alltagstauglichkeit durch?
Compute, das mit V8-Isolaten global am Edge läuft — ohne VM-Kaltstart
Serverless Compute, das auf Firecracker-microVMs läuft und tief in das AWS-Ökosystem integriert ist
Es gibt keinen klaren Gewinner: Für kurze, latenzkritische, global verteilte Workloads (Auth, Routing, Personalisierung, API-Gateway, Webhook) ist Cloudflare Workers sowohl günstiger als auch mit weniger Kaltstart-Reibung verbunden. Bei lang laufenden, speicherintensiven oder VPC-internen AWS-Ressourcen-abhängigen Aufgaben liegt Lambda vorn: Die Obergrenzen sind großzügiger, der Zugriff auf private Netzwerke ist GA — bei Workers noch Beta. Das häufigste Produktionsmuster ist hybrid: Workers als dünne Schicht am Edge, Lambda für die schwere Arbeit im Hintergrund.
| Kategorie | Cloudflare Workers | AWS Lambda |
|---|---|---|
| Performance | 8/10 | 7/10 |
| Erlernbarkeit | 7/10 | 6/10 |
| Ökosystem | 6/10 | 9/10 |
| Community | 6/10 | 8/10 |
| Arbeitsmarkt | 6/10 | 8/10 |
| Zukunftssicherheit | 9/10 | 8/10 |
// Cloudflare Workers - API, die über Hyperdrive mit Postgres verbunden ist
import { Hono } from "hono";
import postgres from "postgres";
interface Env {
HYPERDRIVE: Hyperdrive;
}
const app = new Hono<{ Bindings: Env }>();
app.get("/api/users/:id", async (c) => {
// Bei jedem Request einen neuen Client zu öffnen ist schnell — Hyperdrive
// hält den Connection Pool bereits auf Plattformseite.
const sql = postgres(c.env.HYPERDRIVE.connectionString, {
max: 5,
fetch_types: false,
});
// Hyperdrive räumt die Verbindung nach Abschluss des Requests selbst auf; sql.end() muss nicht aufgerufen werden.
const id = c.req.param("id");
const rows = await sql`
SELECT id, name, plan FROM users WHERE id = ${id} LIMIT 1
`;
if (rows.length === 0) {
return c.json({ error: "not_found" }, 404);
}
return c.json(rows[0]);
});
export default app;
/*
wrangler.jsonc
{
"name": "edge-api",
"main": "src/index.ts",
"compatibility_date": "2026-09-01",
"hyperdrive": [
{ "binding": "HYPERDRIVE", "id": "<hyperdrive-config-id>" }
]
}
*/// AWS Lambda (Node.js) - Handler, der mit RDS Postgres in der VPC verbunden ist
import { Client } from "pg";
let client; // bleibt bei Container-Wiederverwendung (Warm Start) erhalten
export const handler = async (event) => {
const id = event.pathParameters?.id;
if (!client) {
client = new Client({
host: process.env.DB_HOST, // privater RDS-Endpoint (innerhalb der VPC)
port: 5432,
database: process.env.DB_NAME,
user: process.env.DB_USER,
password: process.env.DB_PASSWORD,
ssl: { rejectUnauthorized: true },
});
await client.connect();
}
try {
const result = await client.query(
"SELECT id, name, plan FROM users WHERE id = $1 LIMIT 1",
[id]
);
if (result.rows.length === 0) {
return { statusCode: 404, body: JSON.stringify({ error: "not_found" }) };
}
return { statusCode: 200, body: JSON.stringify(result.rows[0]) };
} catch (err) {
console.error(err);
return { statusCode: 500, body: JSON.stringify({ error: "internal" }) };
}
};
/*
template.yaml (AWS SAM) — VPC + Speicher + Timeout
Resources:
UsersFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: nodejs22.x
MemorySize: 512
Timeout: 15 # Sekunden (Obergrenze 900 = 15 Minuten)
VpcConfig:
SecurityGroupIds: [sg-xxxxxxxx]
SubnetIds: [subnet-xxxxxxxx, subnet-yyyyyyyy]
Policies:
- VPCAccessPolicy: {}
*/Es gibt keinen klaren Gewinner: Für kurze, latenzkritische, global verteilte Workloads (Auth, Routing, Personalisierung, API-Gateway, Webhook) ist Cloudflare Workers sowohl günstiger als auch mit weniger Kaltstart-Reibung verbunden. Bei lang laufenden, speicherintensiven oder VPC-internen AWS-Ressourcen-abhängigen Aufgaben liegt Lambda vorn: Die Obergrenzen sind großzügiger, der Zugriff auf private Netzwerke ist GA — bei Workers noch Beta. Das häufigste Produktionsmuster ist hybrid: Workers als dünne Schicht am Edge, Lambda für die schwere Arbeit im Hintergrund.
Kostenlose Beratung erhaltenDas hängt vom Workload ab und muss individuell berechnet werden. Der Workers-Paid-Plan enthält für 5 $/Monat Grundgebühr 10 Millionen Requests und 30 Millionen CPU-Millisekunden; bei Überschreitung kommen 0,30 $/Million Requests und 0,02 $/Million CPU-ms hinzu — Wartezeit auf I/O ist kostenlos. Lambda berechnet dagegen nach Requests plus GB-Sekunden (Speicher × Laufzeit); die kostenlose Stufe umfasst 1 Million Requests und 400.000 GB-Sekunden pro Monat. Bei kurzen, I/O-lastigen Aufgaben kann das CPU-Time-Modell von Workers günstiger ausfallen; bei langen, CPU-intensiven Aufgaben hängt das GB-Sekunden-Modell von Lambda stark vom jeweiligen Workload ab.