First impressions of the Serverless Container Framework
|
ICYMI, Serverless Inc. recently announced the Serverless Container Framework. It allows you to switch the compute platform between Lambda and Fargate with a one-liner config change. This is a game-changer for many organizations! It'd hopefully nullify many of the "lock-in" worries about Lambda, too. As your system grows, if Lambda gets expensive, you can easily switch to Fargate without changing your application code. To be clear, this is something you can already do yourself. It's not a "new" capability. For example, you can achieve the same level of portability by using the Lambda Web Adapter with a Lambdalith (i.e. a monolithic Lambda function running a web framework such as express.js). However, just because a solution exists doesn't mean it's widely known or easy to adopt. There is still a lot to figure out, for example:
I have seen many clients and students struggle to make it work. Those who succeeded also had to invest a lot of development time in figuring out these questions. The Serverless Containers Framework's value is that it eliminates the trial and error and allows you to focus on your application code. I have tried it out myself, and it works as advertised. But I'd like to point your attention to a few design choices and (possible) bugs. API only (for now).At the time of writing, the framework only supports API workloads. This is the most obvious place to start because portability is needed the most and is the easiest to implement. Thanks to batching, Lambda can be cost-efficient at processing background and asynchronous tasks at scale. Thus, such portability is less needed. Also, many services (e.g., Kinesis Data Stream) can deliver events directly to Lambda but not to Fargate. ALB instead of API Gateway.Because API Gateway can't connect to Fargate directly, the framework uses ALB instead. This way, when you switch from Lambda to Fargate, the URL of your API stays the same. Again, this is a sensible design choice. However, it's worth noting that, ALB's uptime-based pricing is more costly in low throughput environments. Conversely, at higher throughput, ALB is significantly more cost-efficient than API Gateway. But as I explained in this LinkedIn post, you need to consider the specific cost dimensions of a service. If your API processes large blobs of data, then you're likely to: a) run into ALB's 1MB payload limit for Lambda targets b) face much higher costs So while the choice for the Serverless Container Framework, you need to make sure it makes sense for your application too. No CloudFormation.Unlike the Serverless Framework, the Serverless Container Framework no longer uses CloudFormation for deployment. It's not clear to me why they made this choice. Perhaps because CloudFormation cannot manage some of the resources (e.g. the container images in ECR)? Whatever the reason, this makes it harder to understand all the resources that the framework has created. Which might be a problem because 👇 "remove" doesn't delete everything.Running "serverless remove" doesn't remove everything. It only removes the application - which seems to include the Lambda function and the Fargate task, not the VPC, ALB and Fargate cluster. Running "serverless remove --force" is supposed to remove all resources, but it doesn't! At the end of my test run, these resources still lingered behind after I ran "serverless remove --force":
Always two container images.By default, the framework always builds two container images - one for the Lambda function and one for Fargate. This makes deployments pretty slow when you have made code changes. However, when you're just switching compute platform, it's very fast! This feels like an odd choice to me. Performance-wise, it's sacrificing 99.999% of deployments for the one time when you need to switch compute platform without code change. Maybe it's the one use case that the Serverless Inc. developers saw every day as they worked on the framework. But it's not the norm for anyone who'd be using the framework. Is it worth the license fee?Finally, the new Serverless Container Framework requires the Serverless CLI v4. It's therefore covered under v4's pricing model, which applies to organizations making $2M+ in annual revenue. I have seen organizations waste tens of thousands dollars worth of engineering time trying to do this poorly. So, personally, I think the Serverless Container Framework is well worth its fee. However, your perceived value of the framework depends on your ability (and time!) to figure things out yourself and coming up with a suitable solution for your organization. That is, assuming you need the ability to switch between Lambda and Fargate to begin with! |
Master Serverless
Join 15K readers and level up you AWS game with just 5 mins a week.
Last week, we looked at 6 ways to version event schemas [1] and found the best solution is to avoid breaking changes and minimise the need for versioning. But how exactly do you do that? How can you prevent accidental breaking changes from creeping in? You can detect and stop breaking changes: At runtime, when the events are ingested; During development, when schema changes are made; Or a combination of both! Here are three approaches you should consider. 1. Consumer-Driven Contracts In...
Synchronous API integrations create temporal coupling [1] between two services based on their respective availability. This is a tighter form of coupling and often necessitates techniques such as retries, exponential delay and fallbacks to compensate. Event-driven architectures, on the other hand, encourage loose coupling. But we are still bound by lessor forms of coupling such as schema coupling. And here lies a question that many students and clients have asked me: “How do I version my...
During this week's live Q&A session, a student from the Production-Ready Serverless boot camp asked a really good question (to paraphrase): "When end-to-end testing an Event-Driven Architecture, how do you limit the scope of the tests so you don't trigger downstream event consumers?" This is a common challenge in event-driven architectures, especially when you have a shared event bus. The Problem As you exercise your system through these tests, the system can generate events that are consumed...