These two significant differences between real serverless vs container-based workloads (whether these container-based workloads are run serverlessly or not) lead to my general rule: Serverless is inherently more secure than containers.
Learn More about Serverless and Security from Cascadeo Field CTO JV Roig
JV Roig is a cloud technologist and the field CTO for Cascadeo, a public cloud managed services provider and IT Transformation partner.
In 2022, he was named an AWS ambassador. This program recognizes technical experts across AWS domains who develop thought leadership content like technical write-ups, blogs, and open source projects. AWS Ambassadors by nature hold multiple AWS certifications, and take initiative to educate customers and partners regarding AWS services.
In December, JV took 5 AWS certification exams in three days, bringing his AWS certification total to 19, cementing his expertise in all things AWS.
Learn more about serverless and security in the blog post below.
Why Serverless Is Inherently More Secure Than Containers
Although a serverless setup and a container setup will both provide a lot of beneficial abstractions compared to traditional VM-based workload setups, a container-based workload abstracts far less (i.e, through an orchestration tool, be it something like Kubernetes, Docker Swarm, or cloud-native ones like ECS and EKS in AWS). And the less is abstracted, the more work you still have to do yourself.
For example, in a typical container workload, you are pretty much still responsible for a lot of maintenance and patching — not just of your actual source code, but of the OS itself (i.e., the container image which has a base OS and necessary utilities and components, aside from just your code). Oh, yeah, you have to manage container images now, so you maintain not just a repository of code (like your GitHub repos), but also an image repository.
Yikes. In the real serverless world, you maintain the Git repo of your code, and that’s it. Image patching? Maintaining an image repository? Not your problem…