The term “serverless architecture” is a recent addition to the technology lexicon, coming into common use following the launch of Amazon Web Services (AWS) Lambda in 2014. The term is both paradoxical and provocative: In fact, there really are servers backing “serverless” technology, but the term illustrates one of IT’s biggest headaches, server administration. Serverless architecture offers the promise of writing code without the worries of ongoing server administration.
But is the reality as sweet as the promise? The agency I work for recently put this question to the test when we deployed an app in production using a serverless architecture.
For our project, we opted for a serverless architecture using AWS Lambda, API Gateway, S3, and DynamoDB to power a website and chatbot application for a major entertainment company. A serverless approach was a natural fit because the app was expected to receive a significant amount of traffic during the initial few months, likely tapering off thereafter. Relying on AWS-managed components meant we could achieve scalability and high-availability without the cost or complexity of setting up redundant, load-balanced, auto-scaled, EC2 instances. More importantly, it meant the client only paid for actual compute time.
The end result was fantastic: The deployed application ran flawlessly. The journey to get there, on the other hand, was a bit more challenging.
Here are five key lessons for building a serverless app in the real world.
1. Allow sufficient time for Lambda and API Gateway configuration
The first thing to be aware of when building a serverless web app is that there is a lot of configuration involved with each Lambda function, including:
- Uploading the code
- Configuring the Lambda function
- Creating the API endpoint (e.g. specifying which HTTP methods it listens to)
- Setting up the IAM security role for the function
- Configuring the behavior of the HTTP request (e.g. how the request variables are received and transformed into Lambda function arguments)
- Configuring the behavior of the HTTP response (e.g. how return variables are sent back to the caller and transformed into an HTTP/JSON format)
- Creating the staging endpoint
- Deploying the API
It’s critical to factor in configuration time for each function when mapping out your project schedule. But as annoying as the amount of configuration may seem, remember that Lambda functions are nanoservices, and their configuration is part of the deployment process itself. It wouldn’t seem strange to spend this amount of time configuring and deploying an API microservice. And on the flip side, it makes life real easy for IT operations.
2. Documentation is light, so be prepared for some detective work
The real challenge is less about the number of configuration steps per se and more about the lack of documentation in general. Error messages are often cryptic and the number of configuration options is large, making diagnosis time-consuming. Making matters worse, documentation and community support is still immature, so there isn’t a huge corpus of community knowledge to draw from. This situation will undoubtedly improve over time as serverless technology gains popularity.
3. Find the right balance between tight cohesion and loose coupling
One of the more difficult questions we faced was how to structure the application itself. Prior to the advent of serverless architecture, functions were assumed to exist within a larger cohesive application with shared memory and a call stack. In contrast, there is a notable dearth of published design patterns for serverless applications. Even Lambda’s close cousin, the microservice, operates much like a traditional application internally with shared memory and a call stack, so the design patterns for microservices didn’t provide much help either. With AWS Lambda, you are literally deploying a single function, outside the context of a larger…