Serverless architecture is projected to grow more than 15% annually for the next five years. The rise of serverless APIs could translate into higher quality code, greater productivity and even happier developers; but the transition can be rocky if it is not managed well.
A high-quality serverless application requires investment in two areas:
● Application design: Follow serverless architecture best practices for each application layer, including infrastructure, data and client API layers.
● Tools & practices: Equip your developers with tools and practices built for modern cloud and serverless architecture, especially ephemeral architecture.
When done right, serverless applications are lightweight and flexible. Developers will have the most success when their tools deliver the same.
Learn Your Way Around the Serverless Ecosystem
Realizing the benefits of serverless architecture and avoiding its pitfalls starts with understanding what it is and how it fits into the cloud computing ecosystem.
Below is a glossary of some important (and interconnected) terms related to serverless architecture. If you need more depth on cloud computing, check out the Cloud Native Computing Foundation (CNCF)’s glossary and courses.
Cloud Architecture
● An umbrella term for technology that allows users to run full-stack applications on remote server networks, replacing on-premise infrastructure.
● Most cloud applications use immutable infrastructure.
Ephemeral Environments
● A developer tool that provides temporary, simulated prod-like environments available on demand for feature development, debugging and testing.
● A SaaS solution for IaaS and FaaS developers allows rapid creation of cloud-like environments without allocating cloud resources.
Function as a Service (FaaS)
● The central technology in serverless architectures is a refinement of IaaS.
● Containers run single functions and deploy in response to triggers from application code, sometimes called event-based compute.
● Highly scalable, true ‘pay-as-you-go’ cloud capacity; configuration is declarative.
Infrastructure as a Service (IaaS)
● A common model of cloud architecture, sometimes called backend as a service (BaaS).
● Replaces on-premise infrastructure like servers and firewalls with managed services.
● Often used with conventional development tools like IDEs and data scrapers.
Immutable Infrastructure
● Infrastructure that can’t be changed once deployed. Often used in containers or virtual machines.
● More secure and reliable than conventional infrastructure.
● Closely connected to infrastructure as code (IaC). Configuration is declarative and checked into Git version control.
Managed Services
● Components of architecture or infrastructure (e.g., data warehousing, CRM, network monitoring, security services) provided by a third party, usually via API.
● Can be used with on-premise or cloud servers.
Platform as a Service (PaaS)
● A comprehensive model of cloud infrastructure that hosts your development environment and testing tools.
● Combines features of SaaS and IaaS.
Serverless Architecture
● Application design that uses FaaS for multiple components of architecture, including content delivery, data storage, message queues and API gateways.
● Segments of cloud resources are allocated at the function level rather than allocating a whole cloud server to an application.
Software as a Service (SaaS)
● A subset of managed services, usually cloud-hosted.
● Full-scale applications and tools available over an API.
Why Go Serverless?
While serverless architecture isn’t appropriate for every API or application, it has a broader range of use cases than you might think. Done right, serverless can offer multiple benefits such as enhanced scalability, simpler operations, better developer productivity, faster iteration and reduced costs. Serverless applications can also be quick to build. This is a good match for APIs since many are spun up quickly for short-term use, especially in microservices.
Reasons to like serverless architecture go deeper than use cases and basic efficiency. In two meaningful ways, serverless design gives developers greater control over their work and puts the focus back on high-quality, functional code.
Declarative Code is Good, Clean Fun for Developers
In the glossary above, you may have noticed ‘declarative’ popping up a couple of times — the alternative is ‘imperative’, a term you might hear developers use with some disdain.
These terms often describe two approaches to writing code. In imperative code, developers spell out, step by step, what the computer should do. In declarative programming, developers tell the system their desired end result and let the compiler determine the best way to get there.
You can view infrastructure similarly. Conventional on-premise infrastructure is imperative — you manually set parameters on each piece of equipment and connect machines and services. It takes a lot of expert knowledge and time.
Cloud infrastructure is declarative. You tell your cloud provider details like what services you need and how much traffic you expect, and the provider finds the best way to deliver that infrastructure capacity.
PaaS and FaaS are even more declarative than standard cloud architecture, which starts with a commitment to a specific server capacity and configuring your tenant yourself. PaaS and FaaS don’t require that. Instead, they tell the cloud to run a specific function and return a result, and the cloud service figures out how much capacity you need and how to access it — everything after the function call is up to the cloud provider.
Developers prefer their code as well as their infrastructure to be declarative for similar reasons:
● Less room for bugs: Devs rely on well-tested compiler or cloud server code to execute instructions.
● More energy to write good application code: Infrastructure details don’t take up bandwidth.
● Easier to envision and action new solutions: This is helped by what-you-see-is-what-you-get logic.
● More reliable development and production environments: Infrastructure is outsourced to third-party experts.
In short, declarative infrastructure, especially serverless architecture, makes it easier for everyone to focus on what they do best. DevOps teams can design more efficient systems without fiddling with hardware or worrying about implementation details. Developers get to dive deeper into application logic and write clean code that others can understand. The end result is a better API and a happier team.
Separation of Concerns, Cloud-Style
A second advantage of serverless architecture connects to another basic clean code principle. Think back to your early days in tech. You probably learned about separation of concerns somewhere around week 1 of your technology education — it is that fundamental.
Clean code makes the entire software development lifecycle (SDLC) smoother. You can easily separate and recombine application layers and functions with distinct purposes to serve different use cases. It is a particularly important principle for APIs designed to be flexible and front-end agnostic.
IaC and serverless architecture help achieve the separation of concerns in your infrastructure layer. They reduce connections between your application and infrastructure to discrete programmatic methods. It is hard to change cloud configurations accidentally — any infrastructure changes must be intentional and declarative.
Serverless architecture also helps deliver the benefits of functional programming for your API, making functions more independent. Serverless functions have no side effects, are typically declarative and are easy to combine in new ways to serve different purposes.
It all boils down to control: Immutable architecture means server configurations are a controlled variable, and serverless architecture means greater control over your cloud usage. With fewer variables, developers can translate ideas directly into code and clearly see their impact.
The net impact of a move to serverless architecture can be transformative for your organization. By reducing the need for infrastructure expertise and investment in physical assets, you free up resources to invest in application development. You also allow API and app developers to find more satisfaction and focus on their work; but all of that is only true if you also update your tools and practices to match.
Ephemeral Environments are a Best Practice
To make the most of immutable infra and serverless architecture, you need to modernize your development practices and tools to keep pace. You will find useful guidelines and reference architectures from cloud providers to help design your production API. Choosing tools designed for IaaS like API gateways and rapid API mocks can make your development teams more nimble and efficient.
One of the most useful things to support your teams is to adopt ephemeral environments during development.
Ephemeral environments make earlier phases of the SDLC more compatible with modern cloud practices. An ephemeral environment is a simulation of cloud infrastructure that runs locally so developers can mock, run and debug code under the same conditions as the production application without using cloud resources. Exactly how it does that takes some wizardry — but Blackbird, from Ambassador, actually uses some serverless code to make it happen.
Other names for this practice are production-like test environments and on-demand feature environments. These names suggest the benefits dev teams can gain from using ephemeral environments.
Why Devs Love Ephemeral Environments
At one time or another, every dev probably wished they could just push changes to production — but we have all heard enough horror stories to know better. But even code that has gone through unit testing and code reviews can sometimes cause unexpected chaos in production.
Standard testing and QA processes can feel pointless when you know deployment conditions will differ from your local environment.
Ephemeral environments create mirror images of cloud infrastructure and production data, so pushing to production is less of a leap of faith. If you can run and debug in production-like conditions from the earliest stages of development, you can shorten your entire CI/CD pipeline and get code updates released faster. That is a huge advantage for serverless architecture, where devs can push changes at the function level.
Why DevOps Might Love Them More
Ephemeral environments also offer significant advantages for your DevOps team. For one, they offer a better way to test potential infrastructure changes. Use them to test changes locally, rather than deploying an expensive cloud instance. Ephemeral is particularly useful for performance testing and understanding how your compute load will change, helping make the cost of cloud computing more predictable.
On-demand ephemeral environments also mean DevOps isn’t receiving constant requests from devs. Devs need to spin up prod-like environments quickly, which can add significant unbudgeted work to DevOps teams and disrupt focus on larger projects.
When developers have tools that give them more independence, DevOps gets more done, too.
Create Time and Space for Innovation
When done right, IaC and containerization make web services stable, scalable and iterable; they also reduce the overhead of maintaining on-premise systems. But realizing the ideal isn’t guaranteed.
You can’t get the full benefits if you only modernize production infrastructure. Developers are your most valuable resource, and you will only get meaningful bottom-line improvements if you can enable them to be more productive. Using ephemeral environments like Blackbird makes following best practices easier across your technical organization — a strong choice for any team looking to modernize their practices and maximize their resources.
Choose serverless and IaC if they are a good fit for your API — they will be for many teams. Regardless of architecture, teams should prioritize tools and practices that let people focus on their area of expertise. The right tools let developers write and debug code with fewer distractions, free up DevOps teams to take on meaningful projects and give everyone the space to do better work.
