An abstraction over basic Kubernetes primitives is sorely needed.
A concept of an application with versioned releases can be hacked together with a lot of effort and a multitude of tooling, but it's an awkward experience.
An standard abstraction over event driven systems is also very beneficial.
To me Knative had somewhat bad positioning, relatively subpar documentation and bad marketing. It seemed like a half-hearted effort without a coherent vision or strong drive.
It also came very late. Something like it should have been officially included in Kuberentes much earlier.
Dapr [1] is a very similar effort, driven by Microsoft. It does much better on the above points, in my opinion.
One complication here is that the cloud vendors might be ambiguous or even adverse towards a standardized application definition and deployment system. It has the potential to (maybe significantly) reduce the lock-in AWS/Azure/GC currently cause for most customers.
Problem with knative and serverless in general, if you objectively look at it is that the market is quite small. Serverless is a nice way to create and deploy apps in startups. Startups in general have their own existential issues, now if I have to setup a managed kubernetes cluster and then then deploy, I am adding more unnecessary layers to already burning pile of fire.
For others they already have apps running, they want to port the platform as is on kubernetes. That itself is generally a struggle.
I think knative is really cool to play around with, it quite fun but I would think twice using it in real world because there are lot of moving operational pieces, learning curves and abstractions. It is much more comfortable to just write simple services with confidence.
I classify serverless, one push deployments, app runners in Heroku bucket. Heroku more less had 50mil ARR in 2020 [1], market is quite smaller actually.
I do custom enterprise software and there the story is somewhat different. In that landscape many existing workloads are either being migrated to VMs or containers in the cloud or replaced with new cloud native applications. Companies are eager to have as minimal on-prem setup as possible (mostly for legacy software too difficult or risky to migrate).
For entirely new applications serverless solutions are usually the first option to be considered since they are very easy to operate. Many clients also don't have much expertise in-house for operating k8s so new workloads would be operated by outsourced ops teams or development teams themselves which is very expensive. Large enterprises also have formed some sort of "strategic partnership" or alliance with either Amazon or Microsoft so cloud agnosticism rarely enters the picture. In addition to being easier to operate, skilled development teams are also very fast to deliver on serverless since there's very little infrastructure-level things to worry about. The team can focus on business logic and delivering value from day 1. If you only look at Heroku I can assure you the market for serverless is much bigger and constantly growing.
Thanks for your insight. What happens to their existing applications, do they move them to serverless too? I am working on an enterprise software in the space. Would love you be in touch with you and get some insights.
The most common approach I've seen is lift & shift to a VM and possibly some devops pixie dust on top to adopt golden image deployments.
My perspective is limited and evidence anecdotal but I've seen only one on-prem to serverless "migration" project so far and that was a complete rewrite. The original codebase was ~20 years old, had a tight dependency on an expensive proprietary database and a variety of scalability issues so it would have needed thorough rearchitecting anyway. A more common pattern is to do the lift & shift and incrementally either create new services or migrate existing ones to serverless where it makes sense (the strangler pattern).
Most of our Kubernetes-based services communicate with Kafka.
Istio adds basically no value into Kafka-based clusters as it doesn't offer a full abstraction over Kafka (and basically can't as clients as broker-aware etc.).
KNative was basically DOA for us because it required Istio.
It's not so much that KNative was marketed wrong so much as being too opinionated about the "cluster-admin"-level components. If they were part of your stack already, cool, it was easy to get going. If they weren't, then trying to adopt KNative was like trying to force a square peg into a round hole.
> I think Knative should have been just the serving component.
There are so many different ingresses (& now gateway) providers in Kubernetes. Serving continues to strike me as fairly unremarkable, and something already hotly fought for. Knative builds upon & extends a handful of the existing options, but it feels like Kubernetes Gateway API[1] will probably take over a large part of the special sauce type behavior that Knative used to be useful for abstracting over, & go a long way towards unifying serverless serving.
Eventing, on the other hand, is a hugely absent & missing abstraction in Kubernetes. There's lots of function as a service systems, plenty of fancy ingress/gateway options for routing traffic, but in terms of connecting up a panoply of services together, having a system to transport events around, there are very few Kubernetes-related offerings.
Knative Eventing is an unmatched offering. This article suggests the serving component should have been emphasized, and indeed, I think it's more core to the servlerless idea than eventing. But it's also far far better served, far more competitive a realm, to the degree that now there is participation & cooperation going on across the many providers to create a Kubernetes Gateway specification as a high-powered replacement for Ingress. What we need, what has unique value, is Knative Eventing.
My experience with Knative was that it was an abstraction too far for the market. Even when I started to understand it, explaining to other engineers was really difficult.
As a colleague once said, 'The first rule of Knative club is that you can't explain what it is'
I couldnt ge knative to work nicely with gitops tools, and found some of the abstractions confusing and didn't really simplify anything, won't be using it again probably
A concept of an application with versioned releases can be hacked together with a lot of effort and a multitude of tooling, but it's an awkward experience.
An standard abstraction over event driven systems is also very beneficial.
To me Knative had somewhat bad positioning, relatively subpar documentation and bad marketing. It seemed like a half-hearted effort without a coherent vision or strong drive.
It also came very late. Something like it should have been officially included in Kuberentes much earlier.
Dapr [1] is a very similar effort, driven by Microsoft. It does much better on the above points, in my opinion.
One complication here is that the cloud vendors might be ambiguous or even adverse towards a standardized application definition and deployment system. It has the potential to (maybe significantly) reduce the lock-in AWS/Azure/GC currently cause for most customers.
[1] https://dapr.io/