Kube-Native or Kube-Lite?
Kube’s been around for a while now and the eco-system continues to evolve at an accelerating rate. I’m increasingly seeing the term kube-native but what does this really mean? This is my take on it:
Kube-lite: I’m starting to think that what we’ve been doing to date is really “kube-lite”. I see this as being taking an traditional infrastrucutre and deploying it on top of kubernetes to take advantage of it’s scaling and scheduling benefits. This is akin to the mass migration to virtualisation (primarily VMWare) that many of us saw ~10 years ago. Infact, I really see the current trend of large institutions adopting kube as being the logical next-step of that virtualisation migration we saw.
To date, we’ve taken our PHP monolith and deployed it inside a container and built-out a number of microservices around this, decomposing the functionality one opportunity at a time. Now we have 50–60 microservices that actually make-up the majority of our stack. However what makes it kube-lite is the fact that we’re still treating kube as just being a smart virtualisation layer. We’re very loosely coupled to kube and we could quite easily (I mean a few weeks platform engineering, at most) to move the whole stack to any other means of running code, e.g. even as bare metal.
So if kube-lite is just running apps in containers on kube, what’s kube-native?
The rapidly maturing kube eco-system has led to some significant frameworks arriving. I think the most important I’ve seen so far is Istio (though of course there are other ways of implementing what it does — a service mesh, such as linkerd). Istio has taken existing tools e.g. as envoy and wrapped them in a way that integrates very neatly with kube. Kube, in combination with tools like Istio allow you to go full kube-native.
What I mean by this is taking lots of common elements from your microservices and pushing them down into the platform. With kube-native, your applications no longer need to deal with this like trust, routing (in the form of the embedded express, for example) encryption, etc. Instead all these functions are pushed down into the platform, allowing developers to concentrate on writing the functions they need to deliver products instead of having to deal with lots of boiler-plate functionality. If this sounds like serverless to you, then we’re in agreement.
We’ve not really been using serverless, e.g. AWS Lambda, here at Wealth Wizards yet. It’s something developers are increasingly asking for and so we’ve started to look at and in so doing we’re increasing seeing the overlap between Serverless and what we understand to be kube-native.
The question is now: what’s the best option for us to implement the delivery of functions? Go “serverless” and make use of a vendor solution like AWS Lambda or Google Functions and commit to a vendor or remain ‘vendor-neutral’ and implement functions as kube-native using a second framework such as knative (pronounced “k-native”, rather than the far more satisfying “native”) or fission.io?
