Kubernetes is not an orchestrator — it’s a game changer in the Cloud

If you happen to read my ramblings or interact with me, it’s not a big secret how big of a Kubernetes fan I am. I got interested in the technology some time between two and three years ago, while I was looking for something which would heal my delusion in trying to run containers in production.

Since then, the landscape has changed quite a lot. Nowadays, Kubernetes is pretty much the go-to solution if you want to use containers, it extended way beyond its reach, and started to become something different than just an orchestrator: an application platform.

What got me really excited, though, was this blog post roughly a year and a half ago. When I read about it I literally jumped from my chair and thought “This is huge”. Well, as a matter of fact, it was.

But is it all just technical discussions and ramblings? I don’t think so. I believe we’re in the middle of a huge paradigm shift, in which Kubernetes and Operators will play a fundamental, new role.

It all starts with a very simple question:

What is “The Cloud”?

I guess nobody really has an answer, especially if we assume “The Cloud” is mostly companies providing SaaS services on top of a Cloud infrastructure. To me, “The Cloud” is commonly mistaken as a buzzword for “SaaS”, which in turn is a combination of three main elements:

• Infrastructure
• Services
• Operational Intelligence

Kind of works, right? After all, this is all you expect from SaaS: you don’t care about infrastructure, you want your service to self-heal (arguably, you don’t even want to know it breaks), you don’t care how it’s provisioned, you expect it to (down)scale: in short, you just care about the service itself and not how it works internally. How you pay for it isn’t really relevant in this discussion.

Let’s assume what I said it’s true, what does it mean for SaaS providers? That you can be competitive in the market only if you master all three areas: having just a great product or a great infrastructure isn’t really enough, as you will be crushed by those companies which master every part of the stack.

This isn’t that far from reality. Leading SaaS providers are, incidentally, leading cloud infrastructure providers which invested a lot in automation and have great software development teams. Especially if you consider developer-oriented services, or PaaS in general, where hybrid/private instances and replicated deployments matter — a lot. And if keeping up a huge, multi-tenant instance is something you might be able to deal with even if you don’t dominate every part of the stack, how would you keep up with thousand of deployments with the same requirement in terms of scalability and reliability?

As it stands, you simply can’t. In fact, in the PaaS world we’re mostly stranded with a lot of proprietary and vendor-specific services provided by the few who are capable of doing it: not exactly developer heaven.

Kubernetes in the bigger picture

Infrastructure virtualisation is a hot topic since as long as I can remember, but it didn’t really affect developers until recently. In fact, why would I care about infrastructure if all that bothers me is running a service and I’m bound in a Virtual Machine, or a Container? (spoiler: for the reasons outlined above)

Kubernetes twists the plot entirely, by giving Developers access to Infrastructure Virtualisation/Automation from within the infrastructure itself. Don’t get me wrong: it’s not like infrastructure automation, service orchestration and automated recovery are anything new. The main point, though, is they were in different domains. This is exactly the reason why Operators matter: in Kubernetes world, everything belongs together.

So, what happens?

• Infrastructure == Kubernetes
• Service == Your Service
• Operational Intelligence == Operator

Did we just get the keys to the Lamborghini? Not quite — there’s still a missing bit: Kubernetes itself. And that’s where things get really interesting.

Over the last months, every major cloud provider (sorry for those I forgot, mostly laziness) started ditching their own Container Service solution in favour of a managed Kubernetes service. How big the implications of such a thing are is left as an exercise to the reader.

What really matters, though, is that as long as our infrastructure is provided with the needed warranties, we can start building on top of it.

Power to Developers(?)

Everybody loves developers — they’re amongst the most reliable sources in the world nowadays for making money, but all of this might just change the way money is made. Operators are literally allowing software developers and companies, who had previously no business in/with infrastructure, to do business on top of it with a fraction of the overhead.

But that’s not just about all. In a world where Open Source/independent projects can be deployed in a Hybrid Cloud scenario, who needs vendor-specific services? I initially thought I was crazy, but it looks like I’m not the only one. Smart developers and ISVs are, in my opinion, facing the biggest opportunity in years: Infrastructure Providers and Cloud Vendors are no longer competitors: they’re becoming customers/distributors.

Personally, I think there’s a further evolution step, and that’s what we’re trying to do at Ispirata. In less than two months Astarte, our main product, will be distributed as a PaaS solution by an Infrastructure/Cloud Vendor. On top of their own Kubernetes implementation, hidden from the final user/developer.

This is stuff for a different post, but it highlights an important scenario: competition in the Infrastructure space might just get back to Infrastructure itself rather than services, if such a scenario will prove to be successful. In a world where everybody is enabled to distribute the same piece of software, the difference stands in how you do it.

A controversial vision for the future of PaaS

Predicting things in such an industry is difficult and dangerous, and the obvious disclaimer is that my vision is biased and it’s just one of the possibilities. But, if you were to ask me where this whole thing is heading towards, I’d go for “Open Source Platforms as a Service”. And I’m not talking about compatibility layers — I mean the actual Open Source product. To be as explicit as possible, stuff like “actual MongoDB as a service” rather than “DBaaS which is incidentally compatible with Mongo but not quite”.

Emerging models are putting keys to the infrastructure in the hands of developers, and this can be a good thing for everyone. For “edge” developers, this means more standardisation regardless of the chosen Cloud Provider, for “plumber” developers it means opportunity, for Cloud/Infrastructure Providers it means stepping up their services game.

Relatable? Crap? Time will tell, but there’s one thing I’m pretty sure about: things are moving real fast, and new opportunities are popping up on a daily basis. Exciting times lie ahead, and we’re in for quite a ride.