Serverless Framework'ten AWS CDK'ya Geçiş: Bölüm 1 - Neden Geçiş Yapalım?

Serverless Framework ve AWS CDK, örtüşen sorunları farklı felsefelerle çözer: Serverless Framework, Lambda merkezli bir deploy birimi üzerinde YAML güdümlü, sağlayıcıdan bağımsız bir soyutlamadır; CDK, CloudFormation üzerinde typed, AWS-native, programatik bir sentez katmanıdır. Serverless Framework ücretli lisans modeline geçtiğinde, migrasyon kararı varsayılan olmaktan çıkıp aktif bir dengeye dönüştü ve iki araç arasındaki seçim aslında lisans maliyetinden çok, ekibin buyurucu ve bildirimsel altyapıyla ne kadar rahat ettiğine, type safety gereksinimine ve daha derin native kapsama karşılığında AWS’e kilitlenmeyi kabul edip etmediğine bağlıdır.

Bu altı bölümlük seri, Serverless Framework’ten CDK’ya pratik migrasyonu ele alır. Bu ilk bölüm mimari dengeleri, migrasyon kapsamının değerlendirilmesini ve production’ı çalışır tutan stack-by-stack planı kapsar.

Bu altı bölümlük seri tüm geçiş sürecini kapsıyor:

• Bölüm 1: Neden migrate? Trade-off’ları anlama (bu yazı)
• Bölüm 2: CDK environment ve proje yapısı kurulumu
• Bölüm 3: Lambda fonksiyonları ve API Gateway migrate etme
• Bölüm 4: Veritabanı kaynakları ve environment yönetimi
• Bölüm 5: Authentication, authorization ve IAM
• Bölüm 6: Migration stratejileri ve Best Practice’ler

Geçiş Motivasyonlarını Anlamak

Infrastructure araçlarını migrate etmek sadece lisans maliyetleri ile ilgili değil. İşte ekipleri tipik olarak CDK’ya yönlendiren temel faktörler:

Doğrudan Maliyet Değerlendirmeleri

Serverless Framework lisanslama (Pro özellikler kullanan ekipler için):

• Deployment başına fiyatlandırma modeli
• Ekip büyümesi ile artan maliyetler
• Ücretli seviyeler arkasındaki ek özellikler

CDK yaklaşımı:

• Lisans ücreti yok (AWS CLI’nın parçası)
• Infrastructure standart uygulama kodu olarak
• Native AWS servis desteği

Gizli Operasyonel Maliyetler

Her iki araçla çalışmak birkaç operasyonel farklılığı ortaya çıkardı:

• YAML bakımı: Konfigürasyon syntax’ı karmaşık hale gelebilir
• Plugin bağımlılıkları: Üçüncü taraf plugin uyumluluk sorunları
• Cross-service referanslar: String-based referanslar vs. tip güvenli objeler
• Debugging: Runtime vs. compile-time hata algılaması

Bu faktörler çoğu uygulama için doğrudan maliyetlerden daha önemli.

Önemli Teknik Farklılıklar

Pratik deneyim ile, geçiş kararını etkileyen birkaç teknik farklılık belirginleşti:

1. Konfigürasyon vs. Kod

Serverless Framework yaklaşımı (YAML konfigürasyonu):

# serverless.yml
provider:
  environment:
    STRIPE_API_KEY: ${env:STRIPE_API_KEY}
    STRIPE_WEBHOOK_SECRET: ${env:STRIPE_WEBHOOK_SECRET}

CDK yaklaşımı (TypeScript kodu):

// Environment variable'lar compile time'da validate ediliyor
const webhookSecret = process.env.STRIPE_WEBHOOK_SECRET;
if (!webhookSecret) {
  throw new Error('STRIPE_WEBHOOK_SECRET environment variable gerekli');
}

Ana görüş: Konfigürasyon typo’ları YAML ile production’a ulaşabilir, TypeScript sorunları compile time’da yakalar.

2. Plugin Bağımlılıkları vs. Native Entegrasyon

Serverless Framework gelişmiş özellikler için community plugin’lere dayanır:

plugins:
  - serverless-webpack
  - serverless-offline
  - serverless-step-functions

custom:
  webpack:
    webpackConfig: webpack.config.js

CDK AWS servisleri için native construct’lar sağlar:

// Native bundling ve servis entegrasyonu
const bundling = {
  target: 'node20',
  minify: true,
  sourceMap: true,
};

Öğrenilen: Plugin uyumluluğu Node.js güncellemeleri sırasında bakım yükü haline gelebilir.

3. Cross-Stack Referanslar

Serverless Framework CloudFormation export’ları ve string interpolation kullanır:

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

CDK tip güvenli obje referansları sağlar:

// Compile-time validation ile doğrudan obje referansları
const authStack = new AuthStack(this, 'AuthStack', {
  userTable: databaseStack.userTable, // TypeScript bunun var olduğunu garanti eder
});

Fayda: Bağımlılıklar açık ve tip-kontrollü olduğunda refactoring daha güvenli hale gelir.

TypeScript Infrastructure Avantajı

YAML konfigürasyonundan TypeScript koduna geçmek birkaç avantaj getirir:

Serverless Framework (YAML konfigürasyonu):

# 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 (TypeScript kodu):

// 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,
  },
});

// Tip güvenli entegrasyon
const api = new RestApi(this, 'UserApi');
api.root.addResource('users').addMethod('POST',
  new LambdaIntegration(createUserFn)
);

Faydalar şunları içerir:

• Compile-time hata algılaması
• IDE otomatik tamamlama
• Refactoring desteği
• Tip güvenli environment variable’lar

Native AWS Servis Entegrasyonu

Serverless Framework gelişmiş AWS servisleri için plugin gerektirir:

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

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

CDK tüm AWS servisleri için native construct’lar sağlar:

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';

// Plugin olmadan doğrudan servis entegrasyonu
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'),
});

Infrastructure Composition ve Yeniden Kullanılabilirlik

Serverless Framework include’lar ve variable’lar kullanır:

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

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

CDK gerçek object-oriented infrastructure sağlar:

// 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);

    // Kapsüllenmiş, yeniden kullanılabilir infrastructure kalıpları
    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);
  }
}

// Birden fazla stack'te kullanım
new ServerlessApi(this, 'UserApi', {
  apiName: 'users',
  routes: userRoutes,
  monitoring: productionMonitoring,
});

Infrastructure Test Etme

Serverless Framework test etme tipik olarak şunları içerir:

• Framework davranışını mocklama
• Deploy edilmiş kaynakları test etme
• Sınırlı unit test seçenekleri

CDK kapsamlı infrastructure test etmeyi sağlar:

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

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

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

test('Lambda doğru environment variable'lara sahip', () => {
  template.hasResourceProperties('AWS::Lambda::Function', {
    Environment: {
      Variables: {
        TABLE_NAME: { Ref: Match.anyValue() },
        STAGE: 'production',
      },
    },
  });
});

Her Aracın Üstün Olduğu Durumlar

CDK’yı Şu Durumlarda Seç:

1. Karmaşık AWS servis entegrasyonu - Step Functions, EventBridge, AppSync
2. Paylaşılan infrastructure kalıpları - Ekipler arası yeniden kullanılabilir construct’lar
3. İnce taneli kontrol - Custom CloudFormation kaynakları
4. Güçlü typing - Stack boyunca TypeScript
5. Infrastructure test etme - IaC için unit ve entegrasyon testleri
6. Büyük ekip koordinasyonu - Açık bağımlılıklar ve interface’ler

Serverless Framework ile Kal:

1. Basit Lambda + API Gateway - Temel CRUD API’ları
2. Mevcut plugin ecosystem - Community plugin’lere ağır bağımlılık
3. Ekip YAML tercihi - TypeScript konusunda rahatsız olan geliştirici
4. Hızlı prototip - Hızlı proof-of-concept’ler
5. Küçük uygulamalar - Minimal infrastructure karmaşıklığı

Migration Karmaşıklık Değerlendirmesi

Migrate etmeden önce, mevcut kurulumunu değerlendir:

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 'Düşük - 1-2 hafta';
  if (score < 60) return 'Orta - 2-4 hafta';
  return 'Yüksek - 1-2 ay';
}

Migration Karar Framework’ü

Her iki araçla deneyim temelinde, migration değerlendirmesi için pratik bir framework:

Teknik Değerlendirme

Mevcut infrastructure karmaşıklığı:

• Lambda fonksiyonları ve servislerin sayısı
• Custom kaynaklar ve CloudFormation kullanımı
• Cross-service bağımlılıkları
• Plugin bağımlılıkları ve bakım yükü

Ekip Hazırlığı

Beceri değerlendirmesi:

• TypeScript deneyim seviyesi
• Infrastructure as code aşinalığı
• Mevcut öğrenme zamanı
• Programmatik infrastructure ile rahatlık

Migration Planlaması

Risk azaltma stratejileri:

• Kademeli migration vs. tam geçiş
• Rollback prosedürleri ve test etme
• Geçiş sırasında paralel infrastructure
• Ekip eğitimi ve bilgi transferi

Beklenen Faydalar

Gerçekçi sonuç beklentileri:

• IDE desteği ile gelişmiş developer deneyimi
• Compile time’da daha iyi hata algılaması
• Basitleştirilmiş cross-service referanslar
• Infrastructure için gelişmiş test yetenekleri

Migration Hazırlık Listesi

Migration’a başlamadan önce bu faktörleri değerlendir:

Teknik Hazırlık

• Ekip TypeScript deneyimine sahip veya öğrenme zamanı var
• Mevcut infrastructure iyi dokümante edilmiş
• Plugin bağımlılıkları anlaşılmış ve değiştirilebilir
• Infrastructure değişiklikleri için test stratejisi mevcut

Organizasyonel Hazırlık

• Migration zaman çizelgesi iş hedefleri ile uyumlu
• Rollback prosedürleri tanımlanmış
• Bilgi transfer planı mevcut
• Migration karmaşıklığı ekip boyutu için uygun

Ne Zaman Migration YAPMA

Şu durumlarda Serverless Framework ile kal:

1. Sınırlı TypeScript deneyimi - Öğrenme eğrisi delivery’yi etkileyebilir
2. Basit, stabil uygulamalar - Migration yükü gerekçelendirilemeyebilir
3. Ağır plugin bağımlılıkları - CDK alternatiflerinin var olduğundan emin ol
4. Zaman kısıtlamaları - Migration odaklanmış çaba ve zaman gerektirir

Sırada Ne Var

Migration kararını verdikten sonra, asıl iş başlıyor: güvenli, kademeli migration’ı destekleyen bir CDK proje yapısı kurma.

Bölüm 2’de, başarılı migration’ı sağlayan pratik kurulum adımlarını ele alacağım. Geçişi yönetilebilir kılan proje mimarisi kalıplarını, geliştirme iş akışlarını ve environment konfigürasyonunu keşfedeceğiz.

Teknik migration genellikle süreç zorluklarından daha kolay - ekip çabalarını koordine etme, geliştirme hızını koruma ve geçiş boyunca production kararlılığını sağlama dikkatli planlama gerektirir.