De-Mystifying Serverless Terms
Written by Astasia Myers
FaaS. Serverless. BaaS. NoOps. Over the past few years a plethora of terms have been coined to describe solutions that help businesses externalizing server-side components they traditionally built or managed. While the jargon may appear foggy, what is clear is that this technology is the future.
Serverless is comprised of two core categories: 1) Function-as-a-Service (FaaS) and 2) Backend-as-a-Service (BaaS). Unlike VM or container-environments, FaaS architectures remove the host instance and application process to run functions that express application logic. Functions are stateless, event-driven code scripted by a developer. When the function is finished executing it is decommissioned.
Alternatively, BaaS solutions are third-party domain-generic components that leverage microservices architectures and are integrated using APIs. Since BaaS are off-the shelf externally managed products, BaaS manage state and don’t require an intermediary application server. The categories exhibit two commonalities: 1) developers no longer need to manage server hosts or processes and 2) services elastically scale.
We believe FaaS solutions are the natural, logical evolution of compute. Enabled by virtualization, developers began renting on-demand server instances from AWS EC2 allowing them to more quickly provision servers, reduce hardware risk, cut costs, and increase scalability, in turn improving business agility. Over time tech companies began providing managed services further up the stack. Heroku helped create the PaaS market while Platform9 offers a managed service for containers. FaaS takes the next step by abstracting the runtime away from the end user.
BaaS solutions that manage data components on a developer’s behalf raise the abstraction even further up the stack improving developer’s cycle time and quality by allowing them to focus on business logic. A BaaS solution offering a service to replace a repetitive task, like authentication, has an opportunity. Serverless mirrors the same benefits exhibited by earlier offerings by reducing labor, lowering risk, decreasing resource costs, increasing scalability, and shortening lead time.
Some claim the culmination of these benefits result in No Operations (NoOps), a situation where developers never need to interact with operations. We don’t think NoOps is realistic to expect in the near term. While bleeding edge serverless solutions are starting to be adopted, many businesses are just beginning their journey to decompose their monoliths into a service-oriented architecture and require the helping hand of DevOps. Even with the transition to serverless, DevOps will still be needed to help manage the multi-cloud environment including security, monitoring, and tracing. Over time, we think the DevOps role will shift from being primarily technically-focused to more business-minded as services are externalized to vendors. Finally, since serverless requires developers to consider the infrastructure resources, like data stores, when code is being produced, they will take on more operational responsibilities.