Migration von Serverless Framework zu AWS CDK: Teil 1 - Warum Wechseln?

Letzten November ließ unser CTO eine Bombe in der All-Hands-Besprechung platzen: "Wir geben 2.400 Dollar pro Monat für Serverless Framework-Lizenzen aus, und das wird sich mit unseren Wachstumsprognosen verdreifachen. Wir müssen eine Entscheidung treffen."

Ich hatte das Serverless Framework vier Jahre lang verwendet. Es war bequem, vertraut, und unser 12-köpfiges Ingenieursteam kannte es in- und auswendig. Aber als ich auf eine projizierte 7.200-Dollar/Monat-Rechnung für Deployment-Tools starrte - mehr als wir für unsere gesamte AWS-Infrastruktur ausgaben - wurde mir klar, dass wir ein Problem hatten.

Das ist die Geschichte, warum wir unsere 47 Lambda-Funktionen, 12 DynamoDB-Tabellen und 2,8M Dollar ARR-Plattform vom Serverless Framework zu AWS CDK migrierten. Kein theoretischer Vergleich, sondern der echte Entscheidungsprozess, die Finanzanalyse und technischen Trade-offs, denen wir gegenüberstanden, als unsere Infrastructure-Tooling-Kosten unsere tatsächlichen AWS-Ausgaben zu übersteigen drohten.

Diese sechsteilige Serie dokumentiert die komplette 4-monatige Migrationsreise:

• Teil 1: Warum migrieren? Die Trade-offs verstehen (dieser Beitrag)
• Teil 2: CDK-Umgebung und Projektstruktur einrichten
• Teil 3: Lambda-Funktionen und API Gateway migrieren
• Teil 4: Database-Ressourcen und Umgebungsmanagement
• Teil 5: Authentifizierung, Autorisierung und IAM
• Teil 6: Migrationsstrategien und Best Practices

Das 2,4M Dollar Entscheidungs-Framework#

Wenn du für Infrastruktur verantwortlich bist, die 2,8M Dollar ARR bedient, benötigt jede Entscheidung eine ROI-Analyse. Hier ist das Spreadsheet, das unseren Vorstand davon überzeugte, die Migration zu genehmigen:

Die Echte Kostenanalyse (November 2024)#

Aktuelle Serverless Framework-Kosten:

• 4 Umgebungen × 12 Services = 48 Deployments/Tag
• 1.440 Deployments/Monat bei

$2.880/Monat

• Projiziertes Wachstum: 150% bis Q2 2025 = $7.200/Monat

Versteckte Kosten, die wir entdeckten:

• Plugin-Wartung: 15 Stunden/Monat ($3.250 Engineering-Zeit)
• YAML-Probleme debuggen: 8 Stunden/Monat ($1.200 Engineering-Zeit)
• Cross-Team Dependency-Blocker: 12 Stunden/Monat ($1.800 Engineering-Zeit)
• Gesamte monatliche Kosten: $12.450

CDK-Alternative:

• AWS CDK: Kostenlos (Teil der AWS CLI)
• Migrationskosten: $45.000 (3 Monate × 3 Ingenieure × $5K/Monat)
• Laufende Wartung: 5 Stunden/Monat ($750 Ingenieurzeit)
• Break-Even-Punkt: 4,2 Monate

Die Zahlen waren klar, aber Zahlen erzählen nicht die ganze Geschichte. Lass mich teilen, was diese Entscheidung wirklich antrieb.

Die Drei Production-Vorfälle Die Das Geschäft Besiegelten#

Während der finanzielle Fall überzeugend war, machten drei spezifische Production-Vorfälle das technische Argument für die Migration:

Vorfall #1: Der YAML-Tippfehler Der 12K Dollar Kostete (September 2024)#

Unser Senior-Ingenieur deployierte, was wie eine Routine-Konfigurationsänderung aussah:

# serverless.yml - Der 12K Dollar Tippfehler
provider:
  environment:
    STRIPE_API_KEY: ${env:STRIPE_API_KEY}
    STRIPE_WEBHOOK_SECRET: ${env:STRIPE_WEBHOOK_SECRE}  # Fehlendes 'T'

Der Tippfehler führte dazu, dass unsere Payment-Webhooks 6 Stunden lang stillschweigend fehlschlugen. Als wir es bemerkten, hatten wir 12.000 Dollar durch fehlgeschlagene Abonnement-Verlängerungen verloren und weitere 8 Stunden mit der Reconciliation des Payment-Status verbracht.

Das CDK-Äquivalent hätte dies zur Compile-Zeit abgefangen:

// Das würde nicht kompilieren
const webhookSecret = process.env.STRIPE_WEBHOOK_SECRE; // Error: undefined

Vorfall #2: Die Plugin-Dependency-Hölle (Oktober 2024)#

Ein einfaches Node.js-Versionsupgrade von 18 auf 20 brach unsere Deployment-Pipeline. Das Problem? Unser serverless-webpack-Plugin war nicht mit der neuen Node-Version kompatibel, aber die Fehlermeldung war kryptisch:

Serverless Error: Cannot read property 'compilation' of undefined

Es dauerte 16 Stunden über 3 Tage für unser Team, die Grundursache zu finden. Während dieser Zeit konnten wir keine Fixes oder Features deployen. Unsere Velocity fiel auf Null.

Mit CDK kontrollieren wir die gesamte Toolchain:

// Keine Plugin-Dependencies, nur Standard-Node.js
const bundling = {
  target: 'node20',
  minify: true,
  sourceMap: true,
};

Vorfall #3: Der Cross-Stack-Reference-Albtraum (November 2024)#

Unser Authentifizierungsservice musste Outputs vom Datenbank-Stack referenzieren. Der Serverless Framework-Ansatz erforderte dieses fragile Setup:

# auth-service/serverless.yml
provider:
  environment:
    USER_TABLE_ARN: ${cf:database-stack-${opt:stage}.UserTableArn}

Als wir den Datenbank-Stack für bessere Organisation umbenannten, brachen 4 verschiedene Services gleichzeitig. Die Deployment-Reihenfolge wurde kritisch, und neue Ingenieure stolperten ständig über diese impliziten Dependencies.

CDK macht Dependencies explizit und typsicher:

// Direkte Objektreferenzen, keine String-Interpolation
const authStack = new AuthStack(this, 'AuthStack', {
  userTable: databaseStack.userTable, // TypeScript erzwingt, dass dies existiert
});

Warum TypeScript-Infrastruktur Alles Verändert#

# serverless.yml
provider:
  name: aws
  runtime: nodejs20.x
  environment:
    TABLE_NAME: ${self:service}-${opt:stage}-users

functions:
  createUser:
    handler: src/handlers/users.create
    events:
      - http:
          path: users
          method: post
          cors: true

CDK nutzt TypeScript sowohl für Infrastruktur als auch Anwendungscode:

// lib/api-stack.ts
import { RestApi, LambdaIntegration } from 'aws-cdk-lib/aws-apigateway';
import { NodejsFunction } from 'aws-cdk-lib/aws-lambda-nodejs';

const createUserFn = new NodejsFunction(this, 'CreateUserFunction', {
  entry: 'src/handlers/users.ts',
  handler: 'create',
  environment: {
    TABLE_NAME: userTable.tableName,
  },
});

// Typsichere Integration
const api = new RestApi(this, 'UserApi');
api.root.addResource('users').addMethod('POST',
  new LambdaIntegration(createUserFn)
);

Vorteile umfassen:

• Compile-Zeit-Fehlererkennung
• IDE-Autovervollständigung
• Refactoring-Unterstützung
• Typsichere Umgebungsvariablen

2. Native AWS-Service-Integration#

Serverless Framework benötigt Plugins für erweiterte AWS-Services:

plugins:
  - serverless-step-functions
  - serverless-appsync-plugin
  - serverless-plugin-aws-alerts

custom:
  alerts:
    stages:
      - production
    topics:
      alarm:
        topic: ${self:service}-${opt:stage}-alerts

CDK bietet native Konstrukte für alle AWS-Services:

import { StateMachine } from 'aws-cdk-lib/aws-stepfunctions';
import { LambdaInvoke } from 'aws-cdk-lib/aws-stepfunctions-tasks';
import { GraphqlApi } from 'aws-cdk-lib/aws-appsync';
import { Alarm } from 'aws-cdk-lib/aws-cloudwatch';

// Direkte Service-Integration ohne Plugins
const workflow = new StateMachine(this, 'UserWorkflow', {
  definition: new LambdaInvoke(this, 'ProcessUser', {
    lambdaFunction: processUserFn,
  }),
});

const api = new GraphqlApi(this, 'UserGraphQL', {
  name: 'user-api',
  schema: SchemaFile.fromAsset('schema.graphql'),
});

3. Infrastruktur-Komposition und Wiederverwendbarkeit#

Serverless Framework verwendet Includes und Variablen:

# serverless.yml
custom:
  userTableConfig: ${file(./config/tables.yml):userTable}

resources:
  Resources:
    UserTable: ${self:custom.userTableConfig}

CDK ermöglicht echte objektorientierte Infrastruktur:

// lib/constructs/serverless-api.ts
export class ServerlessApi extends Construct {
  public readonly api: RestApi;
  public readonly functions: Map<string, NodejsFunction>;

  constructor(scope: Construct, id: string, props: ServerlessApiProps) {
    super(scope, id);

    // Gekapselte, wiederverwendbare Infrastruktur-Muster
    this.api = new RestApi(this, 'Api', {
      restApiName: props.apiName,
      deployOptions: this.createDeployOptions(props.stage),
    });

    this.functions = this.createFunctions(props.routes);
    this.setupRoutes(props.routes);
    this.setupAlarms(props.monitoring);
  }
}

// Verwendung über mehrere Stacks
new ServerlessApi(this, 'UserApi', {
  apiName: 'users',
  routes: userRoutes,
  monitoring: productionMonitoring,
});

4. Infrastruktur-Tests#

Serverless Framework-Tests umfassen typischerweise:

• Framework-Verhalten mocken
• Deployierte Ressourcen testen
• Begrenzte Unit-Test-Optionen

CDK ermöglicht umfassende Infrastruktur-Tests:

// test/api-stack.test.ts
import { Template } from 'aws-cdk-lib/assertions';

test('API Gateway hat CORS aktiviert', () => {
  const template = Template.fromStack(stack);

  template.hasResourceProperties('AWS::ApiGateway::Method', {
    Integration: {
      IntegrationResponses: [{
        ResponseParameters: {
          'method.response.header.Access-Control-Allow-Origin': "'*'",
        },
      }],
    },
  });
});

test('Lambda hat korrekte Umgebungsvariablen', () => {
  template.hasResourceProperties('AWS::Lambda::Function', {
    Environment: {
      Variables: {
        TABLE_NAME: { Ref: Match.anyValue() },
        STAGE: 'production',
      },
    },
  });
});

Wann Migrieren#

CDK Übertrifft Wenn Du Brauchst:#

1. Komplexe AWS-Service-Integration - Step Functions, EventBridge, AppSync
2. Geteilte Infrastruktur-Muster - Wiederverwendbare Konstrukte über Teams
3. Feinkörnige Kontrolle - Benutzerdefinierte CloudFormation-Ressourcen
4. Starke Typisierung - TypeScript durch deinen Stack
5. Infrastruktur-Tests - Unit- und Integrationstests für IaC

Bleib beim Serverless Framework wenn:#

1. Einfache Lambda + API Gateway - Grundlegende CRUD-APIs
2. Vorhandenes Plugin-Ökosystem - Starke Abhängigkeit von Community-Plugins
3. Team-YAML-Präferenz - Entwickler nicht vertraut mit TypeScript
4. Schnelle Prototypen - Rapid Proof-of-Concepts

Bewertung der Migrationskomplexität#

Vor der Migration bewerte dein aktuelles Setup:

interface MigrationComplexity {
  functionCount: number;
  customResources: boolean;
  plugins: string[];
  environments: number;
  cicdIntegration: boolean;
}

function assessMigrationEffort(current: MigrationComplexity): string {
  const pluginComplexity = current.plugins.filter(p =>
    !['serverless-offline', 'serverless-webpack'].includes(p)
  ).length;

  const score =
    current.functionCount * 0.5 +
    (current.customResources ? 20 : 0) +
    pluginComplexity * 10 +
    current.environments * 5 +
    (current.cicdIntegration ? 15 : 0);

  if (score <30) return 'Niedrig - 1-2 Wochen';
  if (score <60) return 'Mittel - 2-4 Wochen';
  return 'Hoch - 1-2 Monate';
}

Das Migrations-Entscheidungs-Framework#

Nach 15 Jahren Infrastruktur-Entscheidungen, hier ist, wie ich große Migrationen bewerte:

Finanzielle Auswirkungsanalyse#

Alles quantifizieren:

• Direkte Lizenzkosten (offensichtlich)
• Versteckte Betriebskosten (Debugging, Wartung, Blocker)
• Migrationsinvestition (Ingenieurzeit, Opportunitätskosten)
• Langfristige TCO (5-Jahres-Projektion)

Unsere Ergebnisse: 4,2-Monate Amortisation, 140K Dollar jährliche Einsparungen bis Jahr 2.

Technische Risikobewertung#

Die harten Fragen stellen:

• Was passiert, wenn die Migration auf halbem Weg scheitert?
• Können wir schnell rollback, wenn etwas schiefgeht?
• Haben wir die Team-Expertise für Erfolg?
• Was ist der Blast-Radius, wenn etwas bricht?

Unser Ansatz: Blue-Green-Migrationsstrategie mit vollständiger Rollback-Fähigkeit.

Team-Bereitschafts-Bewertung#

Ehrliche Bewertung der Fähigkeiten:

• TypeScript-Kenntnisse: 8/12 Ingenieure komfortabel
• CDK-Erfahrung: 2/12 Ingenieure mit vorheriger Erfahrung
• Verfügbare Bandbreite: 3 Ingenieure für 3 Monate
• Lernkurven-Akzeptanz: Hoch (Team begeistert über moderne Tools)

Business-Alignment#

Technische Entscheidungen mit Business-Outcomes verbinden:

• Schnellere Feature-Lieferung (bessere Entwicklererfahrung)
• Reduzierter operativer Overhead (weniger Deployment-Probleme)
• Verbesserte Zuverlässigkeit (Compile-Zeit-Fehlererkennung)
• Bessere Sicherheitshaltung (explizite IAM-Berechtigungen)

Wann NICHT Migrieren#

Basierend auf unserer Erfahrung, bleib beim Serverless Framework wenn:

1. Kleines Team ohne TypeScript-Erfahrung - Die Lernkurve wird deine Velocity töten
2. Einfache Anwendungen mit seltenen Deployments - Die Tool-Kosten könnten nicht wichtig sein
3. Starke Abhängigkeit von Community-Plugins - CDK-Ökosystem ist kleiner
4. Risiko-averse Organisation - Warte auf mehr CDK-Adoption in deiner Branche

Die Go/No-Go-Entscheidung#

Unsere finalen Entscheidungskriterien:

• ✅ Finanzieller Fall: 4,2-Monate Amortisation
• ✅ Technische Vorteile: Compile-Zeit-Sicherheit, bessere Tests
• ✅ Team-Fähigkeit: 8/12 Ingenieure TypeScript-bereit
• ✅ Business-Alignment: Schnellere Entwicklung, weniger Vorfälle
• ✅ Risikominderung: Blue-Green-Deployment-Strategie

Ergebnis: Einstimmige Team-Abstimmung, mit der Migration fortzufahren.

Was Als Nächstes#

Die Entscheidung war getroffen. Jetzt kam der schwere Teil: tatsächlich eine Zero-Downtime-Migration eines Production-Systems durchzuführen, das 2,8M Dollar ARR bedient.

In Teil 2 führe ich Sie durch die Einrichtung der CDK-Projektstruktur, die es uns ermöglichte, 47 Lambda-Funktionen ohne einen einzigen Production-Vorfall zu migrieren. Wir werden die Projektarchitektur-Entscheidungen, Team-Workflows und Development-Environment-Einrichtung behandeln, die diese Migration erfolgreich machten.

Spoiler-Alert: Der schwerste Teil war nicht der Code - es war das Management von 12 Ingenieuren, die Aufrechterhaltung der Feature-Velocity und das Alignment aller während eines 4-monatigen Infrastruktur-Overhauls.

The#