Why serverless newbies should use a deployment framework

As a developer building your first app with a new technology, successfully deploying a working end-to-end solution can be highly satisfying. But before you get there, you need to learn the fundamentals of the tech.

To optimise your learning process, it seems wise to stick to the core technology and its out-of-the-box tools. If you wanted to build Ruby on Rails web apps, you would learn plain Ruby before learning Rails. If you wanted to build rich front-end experiences, you would skill up on pure React before looking at React-Router, Redux or Webpack. The cognitive burden of having to pick up supplemental tools and frameworks in parallel can be overwhelming. They will slow you down or even cause you to give up altogether.

And in most cases, I agree with this approach. However, if your goal is to build your first serverless web app using AWS Lambda and API Gateway, I make an exception.

Writing the Lambda function code is (generally) the easy part. But I see so many newbie serverless developers hit roadblock after roadblock as soon as it comes to configuration and deployment of the function and its connected services. Some people have even cited such stumbling blocks as a deal breaker for them adopting serverless. Most of these developers are using the AWS console or CLI with home-rolled configuration code to manage their functions and related resources.

The solution I almost always recommend is a simple one—use a serverless-focused deployment framework which has already solved these problems for you.

I would go so far as to say that there is no minimum level of complexity under which you shouldn’t use a deployment framework. Even if you want to deploy a simple Hello World app, you should use a deployment framework to do it. You will jump through fewer hoops all while using the same mechanism you would to deploy a much more complex app with many moving parts.

Pains that deployment frameworks ease

If you decide not to heed this advice and instead stick with the AWS Console or CLI to manage and deploy your serverless app, here is a taster of some issues you can expect to spend time resolving…

• Working out what IAM permissions you need to invoke your function and integrate it with triggering or downstream services
• Jumping through hoops to set up API Gateway with Lambda to act as a simple REST API
• Manually zipping your Lambda code and package dependencies
• Setting up dead letter queues (and requisite IAM permissions) for failed Lambda invocations
• Coming up with your approach for managing environment-specific configuration
• Debugging CORS issues when invoking your API Gateway
• Connecting your Lambda to a VPC

But by choosing to use a deployment framework instead, almost all these “just work” either by default or with minimal configuration.

What framework should I use?

I personally recommend the Serverless Framework (yes, it’s somewhat confusing that it has the same name as the architectural concept). I’ve used it on many projects, find it very easy to understand and is extremely flexible with its plugin model. It has been around for several years and I believe is the most popular deployment framework used in the serverless community today. Safe to say that it’s a solid choice for newbie serverless developers to make.

Another notable mention goes to AWS’s own SAM (Serverless Application Model) framework. I won’t go into the other options now but you can go here for a comparison of the most common frameworks in use.

Less friction = the “serverless way”

A common maxim of the serverless movement is that developers get to focus more on their application code by minimising the need for infrastructure management and scaling concerns.

Lambda removes the pain of managing servers and orchestrating complex container clusters to handle load. API Gateway takes away the need to worry about load balancing and throttling HTTP requests. AWS (and other cloud providers) have done a great job of providing such powerful service primitives to enable a serverless architecture.

But if developers still need to write a lot of plumbing code/config to wire these services together into an app and deploy them, then that’s just unnecessary friction. I don’t think we should rely on the cloud providers to give us a blueprint for tying together our apps. This should be the role of specialised frameworks which sit across all the services.

There will always be those who shun all tools of convenience in favour of a long slog to get something working while jumping through as many hoops as possible just to be able to say they know all the inner workings of the tech.

But for the rest of us who just want to get on with shipping apps to our users, we can use a deployment framework and look under-the-hood only when we absolutely need to.