More and more development teams are choosing to move parts of their infrastructure into the cloud and even opting for cloud-based or “serverless” architectures. Like all things technical there are several costs and benefits to going serverless. We’ve covered some of these in previous articles: Understanding Serverless Computing and The Cost of Abandoning Infrastructure. Functions as a Service (FaaS) is one of many approaches to serverless computing.
No Server?
A serverless architecture does not mean there are no servers involved. It just means the physical server (along with its setup and maintenance) is abstracted away from the customer. For example, Infrastructure as a Service (IaaS) provides a managed abstraction of lower level hardware resources including networking, computing and storage. Platform as a Service (PaaS) goes a step further by offering a fully managed development and deployment environment including operating systems, databases, middleware and other tools. Both of these can be scaled automatically and are priced based on usage. This cloud-based approach can save customers money that would be spent on underutilized hardware resources as well as countless man hours standing up and maintaining physical servers along with the software running on them.
Functions as a Service (FaaS) takes this abstraction a step further. Along with the hardware, os and middleware, FaaS abstracts away the runtime environment. Developers publish small blocks of code which are executed in containers on demand. These containers may have their own memory and processing specifications and can scale independently. Functions can be triggered by a variety of events (depending on the vendor) including schedule, file updates, message busses and http requests. They can also be combined with other cloud services including database storage, messaging, API calls, etc.
Benefits
Flexibility: The higher resolution of scalability allows development teams to be very specific about how their software should scale. For example, it may be very important that certain API endpoints respond as quickly as possible but not so important that all log events are handled instantly.
Cost: Scaling at the function level means that you don’t have to pay to scale up an entire server just because a few of the functions it provides are in demand. Since cost is determined by actual execution time, it becomes much more cost effective to create multiple development environments (dev, qa, prod or even by team, project or feature).
Simplicity: Each FaaS function should be relatively small and have a single responsibility. This makes each function easier to maintain and reason about.
Speed to Market: Modern vendors like Azure and AWS allow users to deploy new or changes to functions within minutes.
Continuous Integration: The atomic nature of FaaS functions can help facilitate automated deployment and testing.
Considerations
Lightweight functions: FaaS compute instances tend to have resource and execution time limitations that may make them unsuitable for heavy lifting.
Potential delays: Since code is executed on demand, compute instances are “spun down” when they haven’t been used for a while. This can lead to longer than usual execution times when a function is called for the first time.
Complexity: Because instances of code are executed independently and in parallel. there are more moving pieces to reason about. This also increases the potential surface area for attack. Developers will need to consider the minimum level of access an individual function needs to operate.
Debugging: In its current state, it is not trivial to debug within FaaS functions. Because the runtime is abstracted away, it may be difficult to replicate the exact runtime conditions of a function locally.
Dependency: At the end of the day “the cloud” is just someone else’s computer. All of the same risks apply. By moving toward a cloud-based infrastructure, a company must give up some control and depend on a third party. This may not be acceptable for some mission-critical systems.
FaaS Changes How You Code
In order to operate most efficiently, FaaS functions should be concise, stateless and assume parallelism. Development teams moving to FaaS will likely have to change the way they organize their code to make it performant. FaaS also demands a more holistic view of the solution from the earliest phases of feature development. In order to properly configure triggers and outputs of functions, developers must consider how new functions fit into the overall architecture of a system. Since security and performance capabilities are configured per compute instance, developers using FaaS will now have to consider those elements at the earliest phases of development. This can expose potential blockers that wouldn’t normally be revealed until code is deployed to a live environment. Finally, since the cloud is not infallible, it is wise for development teams to consider what would happen if (when) functions fail and develop fallback strategies to degrade gracefully.
Is FaaS for Me?
The answer to this question, like most in the tech world, is “it depends.” FaaS offers a lot of potential savings in terms of man-hours, headspace and cost while increasing the responsiveness, scalability and durability of a software system. On the other hand, it can mean a fundamental change in code architecture, internal processes and development approach. Fortunately, you can move towards FaaS incrementally making small changes to your architecture and processes, learning as you go.
