

This series of blogs “What Every CIO Needs to Know about Serverless” is designed to help bring clarity and sanity to the sometimes confusing world of serverless.
In part 1 we covered why serverless matters to your digital transformation and we introduced a couple basic concepts. Part 2 broke down the difference between serverless, Functions as a Services (FaaS), and Knative.
Here, we introduce a way to compare the major FaaS and Knative managed serverless offers.
In the last 20 years, few technologies have seen a more meteoric rise than Kubernetes. The container orchestration platform was initially released in 2014, and a 2019 survey by StackRox found that more than 86% of organizations have adopted it, representing a 51% increase over the previous six months. Part of the appeal is users can run Kubernetes in the cloud as well as self-managing it on-premises.
The explosive growth of containers and Kubernetes gave rise to innovative solutions like Kubeless and Knative that married the container workflow, the portability of Kubernetes, and the benefits of serverless.
The 2018 launch of Knative paved the way for a new set of fully-managed serverless offers coming online now.
We identify three essential types of serverless vendors:
For our initial purposes, we are focusing on the first two types.
Table 1: Comparison of FaaS and Container-based Serverless
In our next and final blog in this series, we will take a detailed look at how several of the leading FaaS and container-based managed serverless options work.
TriggerMesh believes enterprise developers will increasingly build applications as a mesh of cloud native functions and services from multiple cloud providers. We believe this architecture is the best way for agile businesses to deliver the effortless digital experiences customers expect and at the same time minimize infrastructure complexity.
To bring today’s enterprise applications into this future, the TriggerMesh cloud native integration platform ties together cloud computing and on-premises applications. We do this through an event-driven cloud service bus that connects application workflows across varied infrastructures.