Getting the Most out of Your Serverless Architecture

Serverless (Function as a Service or FaaS) is not new anymore. In fact, it’s becoming a bigger and bigger part of the software development landscape. If you’re new to Serverless, the good news is that many early adopters forged their way through the darkness, making mistakes and documenting best practices from which we can all stand to benefit.

Why Go Serverless

If you’re still questioning why you might go Serverless, here are a few of the main benefits to you’ll experience

• No server management — No servers to provision or patch, no firewalls to configure to prevent access
• Flexible scaling — Your application will scale up and down automatically based on need
• High availability — HA and fault tolerance are built in as part of the service
• No idle capacity — Since Serverless is priced by invocation, you only pay for what you use. If no one uses your application for an hour, you pay $0

Once you’ve made the decision to embrace Serverless, there are a few best practices to take into consideration as you when start any Serverless project. As always best practices are good for most use cases, but there will always be exceptions.

Understand

Read your provider’s documentation on their implementation. Understand how it works so you can minimize re-work if and when you hit a limitation you didn’t know about. AWS has a lot of good information in their “Well Architected” document on Lambda here. You should be able to find similar resources that apply to the provider you’ve chosen.

For instance, in AWS if you put your Lambdas in a VPC you are limited by the CIDR block defined in your VPC and your account ENI limit. Having a successful app could cause all kinds of issues as you hit these limits, get throttled, and requests start generating errors for your users.

Simplify

Each function should do only one thing. Proxy functions are an anti-pattern, and having a function that has many responsibilities will make it difficult to scale later. I like to think of a Serverless function as a method in the object-oriented (OO) world and as such, it should do one thing really well but only one thing.

In an API sense, you would want to have a Serverless function for each REST endpoint. ‘GET/users’ and ‘GET/users/1’ should be separated. This makes deploying updates quicker and easier.

Queuing

Use queues as mediators for functions and do not call other functions from within functions as this increases complexity and makes debugging much more difficult.

For example, you could have a Serverless function that accepts an image upload, puts the image in an S3 bucket, and writes to a queue. Another Serverless function is listening to the queue and processes the image to create a thumbnail image.

Serverless is a perfect model for Command Queue Responsibility Segregation (CQRS), more here.

Frameworks

Why start with an empty IDE? There are frameworks out there than can help you get off the ground and into production much quicker. A couple of the more popular frameworks are:

• Serverless — Write your application code and as much infrastructure as you want/need to support it. Supports stages (Dev, QA, etc), environment variables, and a lot of what you need to write and deploy Serverless functions. It has a large plugin ecosystem to support things like local invocation and DynamoDB local.
• AWS SAM — Specifically for AWS Lambda, “you can build Serverless applications faster and further simplify your development of Serverless applications by defining new event sources, new resource types, and new parameters within SAM.”

Wrapping Up

Serverless is a great way to write applications with high availability, built-in scaling, and cost efficiency. However, you must understand your provider’s platform to avoid potentially costly mistakes. You need to keep your functions simple, allow them to do one thing and one thing only. Use queues to pass messages and data around instead of calling functions from functions. Make sure to look into frameworks to help you get started and have consistency across your functions and applications.

If you follow these best practices you’ll have a much better time working with a Serverless platform.