Ordered list of blogs will go here with a widget
I stumbled upon an article over the weekend on Mitigating Serverless Challenges. The article raised some misnomers ranging from vendor lock-in to security and observability. Granted the article was sponsored by Zoho Catalyst advertising their own platform, but it does raise a few points. Primarily with respect to vendor lock-in.
In some respects, the vendor lock-in is okay. Each vendor has their own approach to enabling serverless function securely with how they handle routing traffic to the serverless functions and with the appropriate observability baked in. Where things get interesting on the serverless side with the vendor lock-in is how they are invoked, and how the functions are published.
At its core, the concept of serverless is itself an abstraction of turning a software function wrapped into a container with a runtime engine which exposes a service. For some platforms, this container maybe a webserver where the function takes the payload verbatim to perform it's action, and it will return a result that is treated just like any other web server response. Knative and fn project are some example services that do just this. In other cases, the underlying runtime may integrate the service with the vendor's offerings allowing for flexibility in integrating your function with their various offerings. AWS provides the best example of this with their Lambdas. You can use define multiple "triggers" that will invoke your lambda function in any way that makes the most sense including their third-party providers.
The most important for companies and organizations is how the functions are built and published. For example, AWS and GCP allow for creating and editing functions on the web console. Otherwise, the expectation is a function would be stored with a manifest in a zip file. This zip file is uploaded and the function built and configured to run when ready. For other providers such as Knative, Kubeless, and even fn, they provide a framework where the source is built with a runtime engine producing a docker image that is then used by the underlying framework. One thing to keep in mind is, just like Java Enterprise Edition servlet containers, some vendors such as AWS and fn, will require their custom libraries and interfaces to interface with the underlying services. If the service ever needs to be ported, then the function must be modified.
To help with the building/deploying aspect is the Serverless Framework. Key to their offering is the serverless.yml
configuration file which defines which cloud provider to target, the runtime
engine for building the serverless function, and how to deploy it reducing
the complexity while allowing for an agnostic approach to build and deploy
functions. In addition, TriggerMesh provides their
own CLI that understands the serverless.yml
syntax, and can be used to build the serverless function within your own cluster
provided Tekton is available.
In conclusion, there are quite a few vendors and the space is growing in popularity. While there are differences with their offerings, the underlying technology and abstraction is mostly the same. The one area that will be of some concern for the implementer is how to manage the code and deploy to the preferred vendor. In addition, for the serverless functions that require using the cloud provider's library, there will be a maintenance cost to ensure that it is kept up to date, or the underlying function ported when a new provider is chosen.