Why AWS Lambda and .zip is a recipe for serverless success

How AWS Lambda runs your code

It’s relatively simple. You create an AWS Lambda function and specify a .zip file with the code in it. Yes there are various different runtimes and you need to get the .zip file structure correct, but the package received is simply a .zip file.

It’s just a .zip file.

And .zip files are simply a directory structure of files and folders that has been compressed into a standard format.

And that’s been around for a long time (1989 believe it or not).

That .zip file with code in it gets put into S3 and is linked to the Lambda function and at some point after it’s been uploaded, the Lambda function is invoked, and a cold start happens.

Then the magic happens (well it’s not actual magic, but it’s pretty clever).

In the background, we run an optimised execution environment for the runtime and version your function has specified, and we load your code into from the .zip file.

Then we execute your code (invoke the function) with the data in the event payload that has been sent to the function.

Simple isn’t it?

  1. Zip the function code up
  2. Create an AWS Lambda function
  1. Start an execution environment
  2. Execution environment gets function code (the data in the .zip file) and bootstraps the runtime
  3. Execute the code with the event data payload

So it’s a “container”

There’s an execution environment of some sort in there behind the scenes running your code and AWS talked about that in the very beginning when Lambda was in preview (back then it was called a container).

But why .zip files?

Because .zip files are easy to create, easy to read (programmatically) and easy to work with.

In fact, they are ridiculously simple. Every developer can write code and make a zip file in several different ways.

But not only that, they are quick to extract and use.

And thinking about the build and deploy process, it’s far far easier to have a build process that looks like:

  1. Test code
  2. .zip code
  3. Deploy code

Serverless needs containers, but we don’t need to worry about them

You know the joke about “Serverless — You know there are still servers right?”

There’s another one…

“Serverless — you know there are still containers right?”

You could say, we’re “containerless” just as much as we’re serverless.

Part of the purpose of serverless as a concept is that the whole team can stop worrying about the complexity and management of deployment and simply focus on development.

Containers definitely have their place and value, and don’t think that we in the serverless world are thinking that you’re all wrong and don’t know what you’re talking about. The serverless world wouldn’t exist without containers and it’s really important to understand that and realise that we know that too.

But the thing is that with AWS Lambda and serverless, we don’t even need to worry about what a container is, or why it matters. AWS does the creation, the optimisation, the securing, the provisioning, the scaling and the patching of those execution environments for us.

It also means that AWS could build and deploy improvements to that technology and give customers those improvements without having to make any changes.

Because it’s just a .zip file.

Serverless people simply don’t have to worry about what a container is, or how it really works.

Containers just don’t matter in the serverless world.

Because we write code.

And it runs on demand.

And it scales.

And it’s quick.

And if we ever needed a container, we could figure it out and run it on AWS Fargate.

Disclaimer

I currently work for AWS as a Senior Developer Advocate for Serverless based in the UK and working in EMEA.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Paul Johnston

Paul Johnston

ServerlessDays CoFounder (Jeff), ex AWS Serverless Snr DA, experienced CTO/Interim, Startups, Entrepreneur, Techie, Geek and Christian