The serverless-Kubernetes hybrid is becoming an increasingly popular choice for cloud-native applications and was the subject of several sessions at the conference, but it continues to divide opinion.
For me, the question remains whether there is a real need for this type of hybrid approach. Is it a stepping stone on the way to full serverless or a blind alley?
I had an interesting discussion with Nikhil Barthwal from Google and William Chia from GitLab. Both companies are driving forces behind the Knative push. I must disclose that I belong to the other side – the serverless side – and yes, my company is a pure serverless company.
Google tells developers that Knative allows them “to focus on writing code without the need to worry about the “boring but difficult” parts of building, deploying, and managing their application.”
There is no doubt that teams heavily relying on Kubernetes will find Knative extremely valuable as it saves a lot of time for everyday tasks. Furthermore, as we know, developers like to use the latest exciting technology, and providing them the environment to practice serverless in their current deployment environment will make them happier for sure. It creates a bridge between Kubernetes-based teams and serverless teams.
The main drawback, in my eyes, is that this approach is not really scalable in the way promised by the “serverless” concept. True, you have elasticity in that environment, but if you suddenly have a spike that requires 50 times the compute power allocated in advance, it will not be available in Knative, while it will in a serverless environment like AWS.
Another point is maturity. Knative is growing, but still, there are many features that are not there. The common answer you will get is that the underlying technology is Kubernetes, so you can write whatever you need and deploy directly on Kubernetes without using the Knative mechanism.
That is true, there is no lockdown and you can build whatever you need, but this takes us back to one of the fundamental discussions in serverless. In a serverless world, I’m willing to give up some freedom in order to move faster, and as development velocity is the main goal of software engineering teams, I prefer to get pre-built functionality and be locked in than develop everything I need myself.
So, the discussions during the sessions and the breaks were deep, interesting and sometimes emotional. I believe that in the coming years the stack will be a combination of Kubernetes and serverless, based on use cases.
There were other general sessions like testing (my session), distributed tracing, cost analysis, and cultural aspects, such as how to move your team to adopt new methodologies. Some topics were covered through a panel with the different presenters and I think it was extremely valuable to hear different opinions from people with experience.
I think it was a great conference. I learned a lot on many topics, and I’m looking forward to the next one (Berlin in October, I’ll do my best to be there). I’ll be happy to continue the discussion on serverless topics and ideas, so ping me on twitter @avshafir or email me at firstname.lastname@example.org. More knowledge on serverless can be found on our website.