Avoiding Lock-in Risks With Serverless

One of the concerns for serverless is vendor lock-in and we have seen many FUD regarding how serverless platforms can lock you in. While vendor lock-in is a legitimate cobern for serverless platforms, it is not something that should deter you from using these platforms. In this post, we will discuss lock-in considerations for serverless platforms and highlight how it can be managed.

Open Source Platforms

Let us address the elephant in the room first. There is a widespread belief that using open source serverless platforms will avoid lock-in risks. While open source reduces the risks due to infrastructure and platform lock-in, it does add a considerable operational burden and could impact the developer productivity. The operational overhead necessary to deploy and manage the open source serverless platforms like Knative, OpenWhisk, etc. makes it a difficult option for many smaller organizations. While larger enterprises might have IT teams that can manage these platforms, the operational overhead has an impact on the ROI. Plus, the consumption and scaling for developers may not be as seamless as those provided by cloud providers. This impacts the agility and developer productivity, further reducing the ROI. Many times, there will be additional operational burden on developers in terms of using other services needed by the application such as databases, messaging, etc.. While open source serverless platforms might provide a feel good factor on vendor lock-in, the impact on operational overhead and developer productivity cannot be ignored.

Managing Lock-in Risks

If you want to benefit from the advantages offered by the serverless platforms, you could mitigate some of the lock-in risks by focussing on the application architecture and switching costs. By minimizing the impact, the serverless platforms can be leveraged for many different applications.

  • Architectural considerations: Serverless platforms have the same level of lock-in risks that is associated with any cloud service. By picking the right architecture, these risks can be minimized. Some of the considerations for minimizing the risks are a) Avoid using hyperscaler native services for application dependencies like database b) Using a Portable API can help avoid some of these risks c) Use standards based querying (eg: database queries) wherever applicable
  • Disposable Applications: Another aspect of lock-in is the switching costs involved in moving from one provider to another. If the cost of rewriting your applications is much lower than the switching costs (disposable applications), then it makes sense to completely rewrite the applications. Since most applications deployed on serverless platforms are functions or microservices, the cost of rewriting or re-architecting them will be much lower than switching costs. So, any concerns about vendor lock-in is overblown and can be easily mitigated

Even though the concerns regarding lock-in are valid, it can be easily mitigated in the case of serverless applications. While using the open source platforms may make complete sense for large enterprises and organizations using multi cloud, it adds considerable operational overhead and impacts developer productivity. Unless there is a strong reason to use such open source platforms, most organizations can maximize ROI using hosted serverless platforms.

State of OpenWhisk

OpenWhisk is the first Serverless platform that gained community traction when IBM pushed the platform to Apache Foundation. Licensed under the Apache license, the platform allows developers to deploy event driven applications on any infrastructure. This implies there is an operational overhead in running the platform compared to platforms like AWS Lambda, Catalyst, Google Functions, Azure Functions, etc.. However, there are hosted Serverless platforms like Nimbella and IBM Functions which are based on OpenWhisk. We had a discussion with Knative community about their platform.

Today, at Rishidot Research, we hosted an online panel on the State of OpenWhisk with contributors from the community. The panelists are:

  • Dave Grove, IBM and Chair of OpenWhisk PMC
  • Michael Marth, Adobe
  • Rodric Rabbah, Nimbella
  • Bertrand Delacretaz, Adobe
  • Brendan Doyle, Qualtrics

While Knative has gained traction among Kubernetes community, we wanted to know if OpenWhisk is gaining traction. We discussed various topics including

  • the current state of the open source community and whether the Apache governance model is encouraging for vendors, users and individual contributors. This community has vendors, end users and individual contributors. We discuss how the community is shaping up.
  • the maturity of the platform and the use cases supported
  • what is the difference between OpenWhisk and Knative
  • is Apache way better than the Linux Foundation approach in building sustainable open source projects
  • future of the project

It was a great discussion which showcases the ground reality of OpenWhisk if your organization is considering the platform. Watch the video below.

Is Open Source Even Relevant In Serverless

Open source has been intertwined with enterprise software for more than two decades and, with the increased adoption of cloud computing, the role of open-source software has only been increasing. If we look at the hype around containers, it is completely driven by open source. As Serverless gains traction, driven mainly by the higher-level abstractions, the key question in the minds of industry watchers. When the underlying nuts and bolts have limited meaning from the point of view of its end users, does open source have any meaning? Do developers even care about open source?

When cloud computing gained traction, driven by the success of AWS, there were questions about the viability of open-source software. We had open source projects like OpenStack, CloudStack, and Eucalyptus, competing against the Infrastructure as a Service offering from AWS. They failed miserably because the advantage of cloud computing was in the outsourcing of data center capital expenditure and operations. Open-source IaaS software didn’t provide this advantage and all they could offer was better resource utilization and programmatic access to the infrastructure. However, in the early days of cloud computing, the public cloud was not a runaway success among enterprise customers and the hybrid cloud was the path taken by these users.

Even though open source failed in providing an equivalent to AWS EC2, we saw the reverse happening in the PaaS layer. While Heroku, Google App Engine stagnated after getting initial developer mindshare, OSS offerings like OpenShift and CloudFoundry gained developer traction as well as enterprise adoption. Their success could be adopted to the fact that enterprise customers wanted to have a PaaS like abstraction that could span both on-premises as well as public cloud. This was followed by the huge success of Docker as the container engine and Kubernetes as the container orchestration plane. At this point, talking heads were so confident about the importance of OSS in cloud computing. But we need to keep in mind that the success of OSS in the PaaS layer was driven by two main reasons:

  • PaaS services in the public cloud had a legacy cost structure based on compute units similar to virtual machines
  • Hybrid cloud was still the focus of enterprise customers due to unnecessary concerns about moving to public cloud providers

In the last 2-3 years, we have seen a dramatic shift in the enterprise adoption of public clouds and most organizations are taking a cloud-first approach.

So, when AWS released AWS Lambda with a new pricing model based on service invocations, we saw a shift similar in importance to what happened when they released compute and storage as a service with a pricing model where user paid only when the service was used. Functions as a Service (FaaS) like AWS Lambda, Catalyst, Azure Functions, etc. provide a breakthrough in the cost model similar to the pay per use model unleashed by early cloud services like AWS S3 and EC2. This is what makes FaaS uniquely attractive to both developers and enterprises. A fundamental shift in a cost structure that lowers the barrier to adoption and the cost of innovation. FaaS levels the playing field for smaller companies to build innovative services to compete with large organizations with great financial muscle. This is entirely driven by the cost model of FaaS alone and the cost savings are the reason why FaaS is still attractive in spite of certain architectural limitations imposed by the abstraction.

The key question is whether open-source can compete with FaaS offerings in the cloud. There is no straightforward binary answer and it is a bit more nuanced. OSS cannot compete head to head with FaaS. Developers would rather not have any operational overhead than managing the open-source serverless layer. FaaS is a clear winner against open source equivalents just like how IaaS made open-source cloud infrastructure software irrelevant. However, open-source may still be important in some niche areas:

  • There could be higher-order developer frameworks on top of FaaS that could be open source in order to get developer mindshare. Serverless.com is a good example of this
  • Multi-cloud is fast becoming the de facto strategy for many organizations. Organizations may want to provide the same developer abstractions across multiple cloud providers. Open source serverless platforms will be relevant in this scenario. Data is spread out among multiple cloud providers and the compute for the applications using the data should lie closer to the data. Many organizations may want to provide a standardized developer interface to their developers. Open source serverless platforms will be useful in such scenarios. This is similar to the success of OpenShift and, to a lesser extent, CloudFoundry in the PaaS layer
  • Kubernetes is fast gaining traction among the enterprises for deploying containers. As organizations deploy apps using multiple encapsulations and deployment models like containers and FaaS, they may want to have a Kubernetes based serverless layer. Knative and serverless frameworks on top of Knative may be relevant in such scenarios

While it doesn’t make sense to use an open-source FaaS layer while using a single cloud provider for deploying the applications, it may still be relevant in multi-cloud scenarios and toolkits around FaaS. Thoughts?