There is quite a bit of chatter around deploying Serverless platforms on-premises either on their traditional virtualized infrastructure or private cloud. Does Serverless on servers in your own data center make any sense? Does it defeat the very idea of Serverless? In this post, we will take a look Serverless from the point of view of both public cloud services and on-premises.
First things first: Serverless has servers
One of the most meaningless debates in the Twitterverse is Serverless has servers. In fact, Serverless is a very bad term to describe the abstraction leading the debates in an orthogonal direction much like the DevOps-NoOps debate of the past. Finally, it is about the developer abstraction and who is responsible for managing the underlying compute resources needed to deploy the abstraction and the pricing model (about which we will discuss below). This debate is no different from the public vs private cloud or PaaS vs private PaaS of the past. Keeping this “Serverless has servers” talking point aside, let us take a look at both public cloud service and on-premises deployment to understand the differences.
Serverless on Public Clouds a.k.a Functions as a Service
I am a big believer in developer level abstractions and have argued that PaaS is the future of cloud services circa 2010. My argument then is that if cloud computing is about abstracting away the complexities of infrastructure provisioning, then it makes sense to abstract away the complexities of even the runtime, middleware, database provisioning, etc.. A real cloud, in my opinion then, should offer an interface for developers to push their code and everything underneath is abstracted away through automation. The pricing model should be more utility like and should not involve complex calculations like provisioning IaaS. PaaS was attractive, but it was not attractive enough to get everyone to using the abstraction at the platform level, part of which was driven by the difficulty in the pricing model. Heroku came closer to a simpler pricing model, but it was not enough.
Fast forward today, we have Functions as a Service (FaaS) as the right level of abstraction with an invocation based pricing which is more efficient than PaaS. Some reasons for the success of FaaS are:
- First, and foremost, reason is the simplicity of the developer interface. The ease with which developers can deploy the functions code, either with a simple zip file or docker containers or through webhooks to source repositories or other cloud storage services, is the single biggest reason for the success of FaaS. We have spoken with developers at both startups and enterprises and developer experience is cited as the main reason for adoption
- Second reason for the success is in the modularity of the application architecture it enables. Microservices was fast gaining mind share as the right architecture for cloud (with its distributed nature and ease with which the architecture could enable DevOps) and it helped FaaS getting traction because it fits right well with the Microservices architectures. The adoption of this architectural pattern in both startups and enterprises paved the way for friction free adoption of Serverless functions
- The third reason is the pricing model. FaaS has a much more efficient pricing model than PaaS. The invocation based pricing makes FaaS a very attractive candidate for many use cases. However, caution is required in how the functions use storage, invocations and duration of processing but, in most cases, this is much more efficient than IaaS or PaaS pricing
The success of FaaS, like cloud, is mostly developer driven. Developers are focussed on the efficient way to solve a problem and the abstraction provided by FaaS fits right into those needs.
If you look at the history of (cloud) computing, the abstraction that gains traction in the public clouds (IaaS, PaaS, DBaaS, BaaS, XaaS) gets replicated on-premises, mostly driven by legacy enterprise vendors wanting to compete with the web scale cloud providers. In that context, Serverless coming to on-premises is not entirely surprising. As more and more enterprises embrace the fail fast philosophy for continuous innovation, FaaS is attractive for them in the dev-test environment because it allows them to experiment without having to wait for CFO’s nod. When their experiments succeed, they want to bring it on-premises for production deployment. This has lead to proliferation of Serverless inside the enterprise data centers (yes, I said proliferation because it is already deployed on-premises and you can also see it from the Twitter poll below).
Serverless on-premises initially gained industry attention when IBM announced OpenWhisk project (which was donated to Apache Foundation later). As Kubernetes gained traction inside the enterprise, many Serverless platform based on Kubernetes has come into the market. Projects like Kubeless, Nuclio, OpenFaaS, etc. are good examples of Kubernetes based Serverless offerings (see this Github repo for a more exhaustive list). In the case of On-Premises offerings, it is about bringing the abstraction to the enterprise customers not comfortable with public clouds. We have seen it happen with Red Hat OpenShift and Pivotal CloudFoundry for PaaS and we are seeing the same story repeats for Serverless.
Clearly, the adoption of Serverless on-premises is not driven by pricing but, rather, due to the developer abstraction. The invocation based pricing model will not apply because the costs of underlying infrastructure are not trigger based and the pricing model for the platform will be mostly socket or node based. CFOs and some enterprise decision makers might prefer the predictability of costs and are comfortable with the pricing models of on-premises offerings
Serverless On-Premises – Does it make sense?
— Krish Subramanian (@krishnan) April 24, 2018
The success of FaaS is driven mostly by the seamless developer experience and the invocation based pricing made the bottoms up adoption possible. The adoption in on-premises Serverless platforms are driven by the IT’s need to provide a developer abstraction that enables event driven functions and the comfort of predictability in the costs. The Serverless market is still in early stages. Large-scale mainstream adoption is expected to happen in the next 3-5 years.