We are launching a new microservice with highly spikey traffic patterns. Should we go with AWS Lambda (Serverless) or stick to an auto-scaling EKS cluster (Containers) to minimize our monthly cloud billing?
3 answers
For unpredictable, spikey traffic, Serverless is almost always more cost-effective because of the "pay-per-invocation" model. With managed containers like EKS, you are paying for the underlying EC2 instances or Fargate vCPUs even when they are idle or scaling down. AWS Lambda scales to zero, meaning you pay nothing during quiet periods. However, be wary of "cold starts" if your application is latency-sensitive. If your "spikes" are actually consistent high-volume traffic, the per-request cost of Lambda eventually becomes more expensive than a well-tuned, reserved-instance container cluster.
How do you handle the vendor lock-in issues associated with Serverless when the entire backend logic is tied to provider-specific triggers and proprietary APIs?
We found that for our specific use case, Google Cloud Run was a perfect middle ground. It's serverless but uses containers, so we get portability without managing nodes.
Cloud Run is fantastic! It really solves that lock-in problem Alice mentioned because you’re just deploying a standard Docker image that can run anywhere.
Vendor lock-in is the hidden tax of Serverless, Jeffrey. To mitigate this, we use the Serverless Framework or AWS SAM to keep our deployments somewhat portable. We also try to keep the business logic in pure Python or Node.js functions, separate from the AWS-specific handler code. This makes it easier, though still not "easy," to migrate to another provider if we ever needed to.