One of the key findings in the Datadog State of Serverless report was:
“Container users have flocked to Lambda. As of January 2020, nearly 80 percent of organizations in AWS that are running containers have adopted Lambda.”
After my review of the report, newsletter reader Luca Ingianni replied to me on this point, asking:
“What do you make of this? Are containers particularly well suited to integrating serverless components? Or is it a matter of containerised products being perhaps younger in general, and thus more likely to use other young technologies such as serverless?”
IMHO, I think that it’s a bit of both. The first point goes to the “how” of adopting serverless and the second goes to the “why”.
Let’s take the first point that containers are particularly well suited to integrating serverless components.
I would rephrase this slightly to say that microservice architectures are well suited to integrating serverless components, rather than containers specifically. But I’d be pretty confident that there’s a higher incidence of microservices architectures within container-backed systems than in more traditional EC2/VM/bare metal backed systems, so I think Luca’s assertion still holds.
Both containers and serverless work well in microservice-based architectures and both have strong tooling around distributed deployment. If you’re already using containers within a microservice architecture and want to dip your toe in the water with serverless, you can just create a small microservice that uses API Gateway and Lambda to see how it goes. It’s low risk, if it works for you, great! But you’re not betting the house on serverless.
Conversely, you can’t really do this with a monolithic architecture. You have to pick one approach at the outset and stick with it. If you change your mind later, you’ve now got a big job re-architecting everything. And so it’s a bigger risk for monolithic systems to introduce serverless.
To Luca’s second point about “containerised products being perhaps younger in general, and thus more likely to use other young technologies such as serverless”, I definitely think this is a big factor.
Forward-thinking companies will always be looking at how to build applications more effectively and efficiently for their users. Containers were a big improvement on this front over raw EC2 and VMs. Serverless is the next natural step in this progression in lowering the Total Cost of Ownership for their applications. They see the merit in cutting out all these undifferentiated tasks that aren’t core to their company’s value offering and are starting to make the transition.
In your place of work, are you using both containers and serverless? Are they both used within the same overall application or in separate systems? I’d love to hear any tips you have (either technical or governance/strategy related) on how you did this migration. Just hit reply and let me know.
Other articles you might enjoy:
Free Email Course
How to transition your team to a serverless-first mindset
In this 5-day email course, you’ll learn:
- Lesson 1: Why serverless is inevitable
- Lesson 2: How to identify a candidate project for your first serverless application
- Lesson 3: How to compose the building blocks that AWS provides
- Lesson 4: Common mistakes to avoid when building your first serverless application
- Lesson 5: How to break ground on your first serverless project