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

Serverless Framework ücretli lisanslama modeline geçtiğinde, birçok ekip alternatifleri değerlendirmeye başladı. Her iki araçla da çalıştıktan sonra, kararın sadece lisans maliyetlerinden daha derin olduğunu öğrendim - bu infrastructure as code felsefesi, tip güvenliği ve uzun vadeli sürdürülebilirlik meselesi.

Bu geçiş bana her aracın ne zaman üstün olduğu ve geçişin gerçekte neleri içerdiği konusunda değerli dersler öğretti. Başka bir teorik karşılaştırma yerine, bu seri pratik geçiş kalıplarına ve karşılaşacağınız gerçek ödünleşimlere odaklanıyor.

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.ymlprovider:  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 ediliyorconst 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 entegrasyonuconst 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.ymlprovider:  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.ymlprovider:  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.tsimport { 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 entegrasyonconst 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 entegrasyonuconst 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.ymlcustom:  userTableConfig: ${file(./config/tables.yml):userTable}
resources:  Resources:    UserTable: ${self:custom.userTableConfig}

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

// lib/constructs/serverless-api.tsexport 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ımnew 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.tsimport { 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.