Terraform vs Serverless Framework, Concerns When Lambdas Increase

Dev
·Dante Chun

These days on AWS,

Terraform + Lambda + SQS combinations are often used for structuring.

Terraform remains the most trusted choice in terms of managing infrastructure as code.

Although CloudFormation is AWS native, I've felt that it has many shortcomings compared to Terraform in terms of readability, reusability, and maintainability.
So the standard of “infrastructure is Terraform” is quite firm.

But the problem is Lambda development experience.

When the number of Lambda functions is small, Terraform is sufficient.
But things change when the number of functions starts to increase to dozens.

  • zip build management

  • Handler directory structure

  • Repeating common configurations

  • Connecting event sources (SQS, SNS, etc.)

When you manage all of this with Terraform, the boundary between “is it infrastructure code or application code” becomes increasingly blurred. On the other hand, Serverless Framework has a very good development experience centered around Lambda.

  • The structure is clear on a per-function basis

  • Connecting events like SQS, API Gateway, and Cron is also intuitive

  • The deployment unit is also clean based on service

So naturally, this concern arises.

Terraform is better than CloudFormation,
but Serverless is better for Lambda development experience
Both are IaC tools... can we mix them?

Mixing is possible. A method of creating VPCs, networks, and common infrastructure with Terraform and managing only Lambda and events with Serverless Framework is also actually used a lot.

But from that moment on, another concern begins.

  • There are two sources of truth

  • Resource dependencies must be matched implicitly

  • As the team grows, the question “where is this managed?” increases

But unifying into one is also disappointing.

  • If you go with only Terraform, Lambda management is cumbersome

  • If you go with only Serverless, it's burdensome to entrust even large infrastructure

These days, I'm constantly thinking about where to draw the line between these two.
Rather than a “perfect tool,” it seems closer to the question of how much responsibility to assign.

I'm curious how teams operating similar structures are solving this problem.

다른 글