Serverless web applications are among the most talked-about trends in the cloud engineering space and have been since the introduction of AWS Lambda back in 2014. Today, serverless architecture empowers teams to increase agility, scalability, and efficiency for customer-facing applications and critical workloads.
Of course, serverless web applications still run on servers, but many aspects of server management are AWS’s responsibility. You can focus on your application code and forget time-killing tasks like provisioning, configuring, and maintaining servers.
For DevOps teams working on small- and large-scale apps, serverless offers a ton of promise—but how can you harness this potential in reality?
Here are six things to know before you build your first serverless web app.
1. Make sure you're ready for serverless
Before you embark on your first journey into serverless, consider your experience. Serverless tools may be easy to get to “Hello world,” but they’re not targeted at beginners, and the deployment and monitoring tools will make more sense if you’ve already dealt with production web apps at scale.
The longer you have been working on self-hosted services, the more enjoyable you’re going to find the process of moving into serverless. That said, if you’re extremely reliant on tools like bash scripting or direct manipulation of your server environment, you’ll want to make sure that you’re ready to adopt a stateless, cloud-only model for managing your new services.
2. Plan for observability from the outset
Before you begin creating your first web application, plan for observability. Decide what you’ll log and how. What kind of metrics will you track? Where will you send these metrics? What kind of metrics tooling will you use?
It’s all too common for people in the early stages of serverless adoption to feel good about what they are doing but be entirely unsure of what’s going on inside their system.
Imagine you’re a chef. You’ve just cooked a brilliant pizza, but it took too long. Your customers got fed up and left. So, you need to speed up the production of your pizza. But, how can you do this without knowing how long each stage in the process took?
Maybe you could grate the cheese faster or simmer the tomato sauce for a shorter time. Could you bake it for fewer minutes, or is this stage already perfectly optimized?
The right observability platform—ideally one that automates a ton of instrumentation inside Lambda like New Relic—can give you this kind of insight. New Relic can help you monitor, visualize, troubleshoot, and alert on your serverless functions in a single experience.
3. There is a whole lot of configuration involved with each Lambda function
Be sure to allow sufficient time for both Lambda and API Gateway configuration. You’ll need to work through the following tasks for each function:
- Uploading the code
- Configuring the function
- Creating the API endpoint (for example, identifying the HTTP methods it must obey)
- Creating the IAM security role for the function
- Setting the HTTP request (for example, how the variables involved in the request are received and converted into Lambda function arguments)
- Configuring the HTTP response (for example, how the return variables are delivered to the caller and converted into HTTP format)
- Creating the staging endpoint
- Deploying the API
When mapping out your project timeline, it’s essential to account for the configuration time required for each function involved. While this may seem like a frustratingly long process, keep in mind that Lambda functions are nanoservices—the configuration is an embedded part of the deployment process. What’s more, the architecture makes things super easy for IT operations.
4. Minimal documentation may demand detective work
When creating a serverless web application for the first time, you might be surprised by just how little documentation there is in general. Error messages are less descriptive and more cryptic, and with so many configuration options available, troubleshooting can be challenging and time-consuming.
In some cases, attempts to diagnose an issue are made even more difficult by the lack of community support. On the upside, as serverless architecture gains popularity, documentation and community knowledge will mature.
5. You’ll need to find the right balance when determining the application structure
One more challenge you’ll likely face when building your first serverless web application is how, exactly, to design the structure. Before serverless hit the market, functions existed inside large, cohesive applications with a call stack and collective memory. On the other hand, with serverless, there is a significant lack of published, predetermined design architectures for web applications.
When using AWS Lambda, you are essentially deploying one single function without the context of a higher-level application. Shared functions and common configuration settings—those things that you take for granted—are no longer. Now what?
One solution is to expose every function in your application as a Lambda function—a sort of extreme version of nanoservices. In practice, however, this could prove to be quite a nightmare. You’ll face a significant amount of configuration work. A deployment tool like Serverless Framework or Stackery is a must if you want to deploy a Lambda for every single API route.
Another option is to deploy a Lambda function that behaves like a controller for the whole application, utilizing parameter values to handle the request correctly. While this approach does remedy the shared code problem, it creates one of its own: complexity. It takes no time at all for the controller function to become bloated and hard to manage.
Depending on the nature of your web application, you’ll probably want to land somewhere in between the two.
6. Create a development workflow
The development workflow for a serverless web application is drastically different from your stock-standard project. You don’t have a local development environment—everything is running on cloud-based components. Further, configuring and deploying each Lambda function is isolated, despite each function existing within the broader context of a cohesive application.
Functions need to access share code, but there is no one-size-fits-all way to share it.
To overcome these challenges, you’ll need to create an efficient development workflow that everyone on your team knows, understands, and, critically, follows. It may take some experimenting, but serverless is worth the initial effort once you’ve got a framework in place.
Are you looking to get started with serverless?
With the right knowledge and tools in your arsenal, serverless success is not only possible but also extremely beneficial. Our AWS Lambda monitoring solution delivers critical insights into managed service data, giving you a comprehensive view of your serverless application.
With this unified visibility into your serverless applications’ most detailed behaviors, you can deliver with confidence on serverless architectures.
Learn more about how you can function faster with New Relic Serverless for AWS Lambda, and sign up for free.
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.