It’s always fascinating to get a glimpse into what’s next in the world of technology. Recently, the Cloud Foundry Foundation -- a nonprofit that oversees an open source platform and is a collaborative project of the Linux Foundation -- conducted a global survey of over 250 users and found that 22% are already using serverless technology. Nearly half are evaluating it. This trend is supported by Cloudability's research (registration required), which suggests that serverless computing is growing rapidly.
The term “serverless” is frequently used to mean cloud services or platforms that allow developers to be completely free of concerns around an operating system and run code that is only instantiated as needed and billed based on execution time. Functions as a service (FaaS) are a subset of the broader serverless term, meaning a capability that supports running individual code functions (not entire applications). The most commonly used example of a serverless capability (an FaaS specifically) is AWS Lambda from Amazon Web Services.
We know that use of serverless technologies is still in its early days and, granted, Cloud Foundry users are typically a bit ahead of the game with their use of open source platforms as a service (PaaS). Still, this number surprised me -- especially as serverless is being adopted in a unique pattern we don’t typically see, which I’ll get into a little later in this post.
Recent conversations with industry analysts confirm what the survey showed: Companies are adopting serverless at a faster rate than anticipated and in two very distinct adoption patterns.
Why Does This Matter?
Digital transformation involves building, testing and iterating on applications faster than your competitors -- specifically to meet the personalized, always-available, digital customer experience that people expect from the companies with whom they do business. Serverless technologies are another way to help developers focus on writing code without having to worry about infrastructure -- and companies are able to pay for actual amounts of resources consumed by applications, rather than pre-purchased capacity. Of course, serverless computing uses servers (physical and virtual), but these are meant to be completely abstracted away from the user. This means developers spend more time focused on solving business problems (e.g., faster app deployment) -- which means happier customers and more market differentiation.
How Are New Technologies' Abstraction Levels Normally Adopted?
The conventional pattern of technology adoption, as described in Geoffrey Moore’s book Crossing the Chasm, consists of “pre-chasm” early adopters followed by an eventual shift to adoption based on business value. The “chasm” between technology-focused adoption and adoption based on business value is often considered the most difficult transition for any technology to make in the market, and many technologies fail to make the leap. Those that do are adopted widely in the market. The curve is a way to model the overall number of adopters during each phase of the technology’s evolution.
Serverless is being examined as a new abstraction for making business applications. This is the “expected” reason for considering the serverless model and would follow the traditional adoption curve -- meaning it would take time to make the shift to the mainstream. Once in the mainstream, we can expect an explosion of frameworks to develop around event-driven (or FaaS) abstractions and, from there, the industry to build up a set of best practices necessary for mainstream adoption.
How Is Serverless Adoption Different?
The main reason that serverless or, more specifically, FaaS is being adopted more aggressively is due to the utilitarian nature of its capability. Public cloud providers offer a wide range of options for building applications and systems. These options need to be tied together, and event-driven FaaS capabilities are perfect to serve as a “glue” between them.
When we think about a server’s operating system used to host applications, there is normally a large amount of “scripting” that is done to help operate the server, automate aspects of the application’s management and generally administer the environment. Public clouds have effectively become massive servers to host our applications, and the need to script various activities exists in this new context as well. FaaS serves that need by making it easy to run simple bits of code that respond to various events in the environment.
So that gives us two concurrent use cases for serverless technologies: business applications and platform-level glue code.
What Should Organizations Do About Serverless Technologies?
First and foremost, if you are using public clouds in any large or material way, it’s likely that the developers and admins in your organization are already using FaaS to some degree. This is a reality that should be understood and accepted. They are focused on getting the job done and using the tools made available to them.
Beyond that, you should be considering how a serverless model for application development may be beneficial to your application development teams. There are potentially huge gains to be had, but be aware that the industry overall hasn’t yet developed enough best practices. There will be much to learn, and practitioners will be exploring some relatively uncharted territory.
Another consideration is how reliant on a single cloud provider you want to be. If you’re already betting on a singular public cloud provider today, then that provider’s function-as-a-service (FaaS) offerings are worth adopting. If you’re currently using multiple public cloud providers, then it gets a little more complicated. Each provider has their own version of FaaS. In addition to the provider-offered FaaS platforms, consider one of the open source alternatives that provide the FaaS experience on whichever infrastructure you choose.
What Should Leaders Do?
Leaders should be aware that, if they are using a public cloud provider, they are likely already using serverless technologies to some extent. Take stock of this use, as it can be both an enabler and the cause of unexpected technical debt. They should also work with their development teams to determine if a more aggressive approach to serverless adoption would benefit their ability to deliver applications.
