Kubecon EU in Valencia, Spain was a welcome breath of fresh air for the Kubernetes community. While the Linux Foundation and the CNCF did great work in the pandemic, nothing is quite like seeing your “people” in person. That what Valencia delivered. I don’t know the attendance figures off the top of my head, but having been in Los Angeles, I can tell you it felt like many multiples.
We were cleaned out of tshirts by 3pm on Day One, despite bringing 25% more than LA. We think that’s a pretty good indicator.
We had four big takeaways from the event which I will detail here. As always, we welcome your thoughts, objections, arguments, etc.
The Kubernetes Wave is Just Getting Started
The first takeaway is that Kubernetes has come a long way since San Diego in 2019 where we last gathered in numbers. It has less of the “gold rush” feeling and more of a mature technology. Still, we are very early in the overall technology cycle. I say that based on conversations with enterprise deployers and smaller organizations. More and more workloads and infrastructure are powered by Kubernetes, but not everything. For others, the intent is there, but the realities of migrating workloads to a Kubernetes-native footing presents challenges. These challenges will be overcome because the Kubernetes model is simply a better mouse-trap and organizations continue to seek efficiency, even in the face of friction. I think we will start to see ubiquity in twelve to eighteen months. That doesn’t mean we won’t continue to see real innovation, it just feels like this is a “done deal" (Kubernetes as the operating system of the cloud operating model) and it will just take some time to get full penetration.
Kubernetes = Kryptonite for Legacy Storage Vendors
The second point has to do with those companies that are not that keen on the rise of Kubernetes - specifically the traditional storage appliance vendors. Indeed, they were not at the show. NetApp’s only presence was Spot. Cloudian didn’t show. Dell wasn’t there. Pure Storage was there with Portworx (who was demoing MinIO in their workshop :)).
We get it, SAN/NAS is legacy technology in the cloud operating model and these are not their “people.” The cloud operating model doesn’t tolerate HW appliances. They will need to change their businesses pretty dramatically. AWS, GCP, Azure, IBM Cloud were all there, talking storage as were Hertzner and others. We may see some of the legacy players in Detroit but it is a bit of a futile effort.
The third point is the prevalence of the operator. Operators are everywhere and everyone has an operator.
Kubernetes implemented the operator model to let vendors extend the Kubernetes's orchestration capabilities with their own custom operators. The operator model is how applications manage the lifecycle of their applications, upgrades, installation, and configuration.
For example, MinIO's operator has the specific knowledge to deal with MinIO's orchestration, but not Cassandra. Because MinIO uses ErasureCode and Cassandra uses Replication. MinIO's operator knows how to provision, scale, upgrade etc., because it is aware of erasure-code parity settings, the concept of pools and how to upgrade MinIO non-disruptively. With the help of MinIO's operator, MinIO appears to the DevOp just like any other application container. This way, the DevOp can deal with all the containers alike (declaratively).
More generally, the proliferation of operators follows the growth of stateful services in the cloud operating model.
Kubernetes knows how to orchestrate stateless services really well, however, when it comes to stateful services like object stores and databases it doesn't have the right knowledge to orchestrate these services.
There is not a universal operator for stateful services and it may not be feasible (the talented Kubernetes community would have done so if it were). The reason this is hard is that each of the stateful services require specific knowledge to implement a custom orchestrator.
This is true for all data stores, databases, message queues - pretty much anything that has to persist state locally. The value of the operator is clear, without it, developers have to write the logic for upgrade/delete/scale tenant as part of their devops automation tooling. It is possible because of Kubernetes’ elegant declarative architecture.
Still one has to wonder if the explosion of operators will create complexity at a level where it becomes a problem to solve for. How many operators are too many to manage? Ten, Twenty, Forty?
It may not end up being a problem. In the words of a very smart engineer here, “...no one complains there is too much software. Right?”
The last takeaway was the most obvious. The cloud is now plural. Multi-cloud is not a feature, it is a requirement. Almost every conversation we had ended up at active-active, strictly consistent multi-site replication. The more important the workload, the greater the concern around continuity.
Enterprises are not just moving into the public cloud, in fact, most who will, have a cloud presence at this point. They are still building out private clouds. They are still building out datacenters. They are still adding more public clouds.
Furthermore, there was some very interesting discussion around a pendulum swing regarding the cloud. In the past, there was the construct that in order to do the cloud correctly, you had to move your data to that cloud. Sales data followed by HR data, followed by operational data. There is now a recognition that you don’t have to move your data to the cloud to use the cloud operating model and that it may be in your best interest to not move that data. It causes lockin, reduces operational flexibility and introduces security risks that are beyond the control of the enterprise. There is also the regulatory/data sovereignty angle.
The net impact is that the cloud operating model doesn’t just mean the public cloud. It can, and in many case does mean the public cloud, but there is a shift and it just means more clouds. The evidence here can be found in vendor messaging. Everyone but AWS was talking multi-cloud. That tells you everyone but AWS has a vested interest in its success or listen closely to their customers.
Kubernetes, and the aforementioned operators, are the facilitators of the multi-cloud explosion, which is only showing signs of acceleration. To learn more about our approach to multi-cloud check out the products section above or our other blog posts on the subject.
We are really looking forward to Detroit and have already begun to formulate some ideas. Object storage isn’t the best demo, but there are some things we can do that will give you a sense of the power of MinIO in the multi-cloud, cloud-native world in which we live.
We promise to bring a lot of tshirts…