• Jan 22, 2020
Two years ago, I wrote predictions about Kubernetes and was dead on, which obviously means I was completely motivated to write another one, entitled “State of Kubernetes in 2019”. And so, I am now being nudged to write another one for 2020.
The first thing I have to realize is that we are no longer 20 people and everything is bigger and professionalizing. These changes are creeping in, and I do think that it’s a general sign of the industry that we have been a part of for the last five years. In essence, it’s no longer just a playground.
But first thing’s first. How did I fare last year?
I think we can say a resounding “Yes!”
It’s not done yet, but Suse stopped their Openstack Product, VMWare is rearchitecting its vSphere product to really be a beefed-up Kubernetes and cloud providers are stepping over each other to have their own Kubernetes things. I mean, you can now have Fargate be your interface to Kubernetes.
For this, I sadly do not have clear proof other than Mesosphere renaming to D2iQ to focus on Day 2 operations of Kubernetes.
OK, you have to admit, that is a big tell that Day 2 is important. I could also add that we’re seeing more (welcome) competition and Gartner is telling us that Day 2 is gaining importance. I think I rest my case when a company rebrands to Day 2iQ when in fact it originally didn’t do Kubernetes and was founded on a competing technology.
I would say that this has to wait for 2020, even though you could keep yourself busy with Big Data and Machine Learning talks at KubeCon 2019 in San Diego.
The move is starting, for sure, and we are having conversations with customers that have moved to the cloud with their big data stack and now want to move it into Kubernetes for the added flexibility. I can point to Google replacing YARN with Kubernetes for Spark Management or Tigera’s post on Big Data and Kubernetes or Microsoft SQL Server Big Data Clusters actually running in Kubernetes, but that is all the more circumstantial.
I think this is another clear win. Everyone will run multiple Kubernetes clusters, we have been saying so from the beginning.
There’s a lot of great work being done with cluster API and we actually have different (regular) meetings with different parties to collaborate on it. It’s not fully where we need it yet. However, it’s getting there and the future looks bright.
Other than that, you will have heard that there are now control planes or ‘multi-cluster capabilities’ - a way to easily start clusters around Openshift 4, vSphere Project Pacific and their Tanzu SaaS control plane for managing clusters and apps.
There are multiple parts to this question. First of all, it was about CRDs taking over, and yes, if you want Tim Hockin’s opinion, everything is becoming a CRD. So that’s solved.
“The rise of CRDs has been a topic that might already have been felt through the number of CRD and operator/controller related talks at the last KubeCons. More drastically, we have been seeing the upstream extensions like the Service Broker API moving from aggregated API to CRDs and similarly for the optional cloud provider service integrations (e.g. AWS Service Operator). Closer to main upstream, many of the current extensions are in their next versions, if possible, being built based on CRDs. Most prominently the Cluster API project, who are, like us, pioneering complex interconnected multi-CRD and multi-controller systems that work together to set up a complex structure such as in this case full Kubernetes clusters. Looking at the aforementioned multi-cluster control planes, both Openshift v4 and VMware Project Pacific rely heavily on CRDs and custom controllers. I don’t think we would be going out on a limb saying that almost all extensions of Kubernetes will be built with CRDs as their main API component, be that extensions to the core or finally actual use-case-oriented developer platforms on top of Kubernetes. Remember Joe Beda saying, ‘Kubernetes is a platform for building platforms?’”
In all honesty, I need to come full circle and say things are professionalizing, and with this, they are no longer developing at a breakneck startup pace.
Many of the things I said last year still hold. More CRDs, more ClusterAPI, more Big Data and more Day 2 operations. I could add that people will understand that managing Kubernetes isn’t for the faint-hearted, that service meshes and edge clusters will continue to be a thing that should be done and people will understand why we focus on security so much at Giant Swarm. But all of this is hardly a prediction or something outlandish where you would say; “Wow, haven’t thought of that.”
I will hence split this into two parts:
1. Pivotal Platform will die, and VMWare will focus on Native Kubernetes
Admittedly, 2020 might be too short-term here, but we all know that this is just a matter of time.
The entire acquisition of VMWare was just a control play that allows them to do a lot more with Pivotal the company and Pivotal Platform and make things look good while it slowly dies off. I am sure that we’ll see a huge revenue drop at least. If they even show us the numbers anymore.
I do hope at the same time that some of the things that might make good additions to Kubernetes make it into great open-source projects. What Pivotal Platform is really used for is a very rigid deployment system to manage large numbers of developers in a controlled manner. That is very likely still needed and we’ll see how OPA and other tools will work or be usable here in the long run.
2. There will be at least two major acquisitions
As the Kubernetes space is heating up, there will be a continuous consolidation and hence at least two major early players in the Kubernetes space will be acquired (1-2) or acquihired (2-3).
Many are still struggling to find their business model but are well VC-funded and with great talent. Let’s qualify that a bit. A major acquisition means north of 500 million USD and that the company has been present at KubeCons for a few years - at least attending, if not sponsoring the event. Acquihires might or might not be cheaper but will be obviously mostly for the team.
3. Redhat will announce a fully K8s compatible Openshift Version
While they have been more or less compatible, there are still differences to native Kubernetes, meaning standard Helm charts out there often don’t work.
There is a special istio version from Redhat that is very special…
Well, it does implement the changes to upstream that are required to make istio work in Openshift. Customers will start to complain, and Redhat will need to change. But previously OpenShift was OpenShift, now it’s to a large extent a packaged Kubernetes and becoming more so with the integration of Tectonic. Maybe the old one is already dead.
1. We will continue to be patient
I recently heard a great saying: “If you lack conviction, I have patience.”
That is exactly the thing I have been saying all along. We need to be the patient ones as we are currently geared towards the big companies that need compelling reasons to choose a fully managed solution like ours.
This might sound counterintuitive for a startup. However, we have tripled our staff, continue to be profitable, and are adding large customers that are all happy and do multi-year extensions of their first contracts.
Regardless of how many new customers we attract, we make sure that our current customers experience consistently excellent service. We express this commitment through our sustainable business model and unique approach to working relationships. This often takes months to establish, but it’s worth it in the end. In the meantime, some might decide to DIY or to choose some product. Honestly, we’re happy that they are taking that step, as it’s the next step on the learning curve that will eventually lead to us.
2. We will grow beyond Kubernetes
We have actually been talking about it for well over a year and have always said so internally.
We are here to make our customers successful in the cloud-native space, and Kubernetes is the first thing we did there, but more tools around Kubernetes will be coming and we will manage them too. Based on simple logic, we will be able to provide you with a more stable and reliable EFK stack than your multiple teams can handle themselves. And it will be worth it. We’re already managing EFK, Prometheus, Kong, Aqua, NGINX Ingress, and others for our customers.
Remember, we never wanted to provide Kubernetes to you. Our primary goal is to enable an agile work environment using microservices and containers to increase development speed and quality, especially in the midterm. As it stands, Kubernetes is just one component that makes that happen. Bottom line, we are here for our customers on their journey.
3. We will grow 50 to 100% on multiple fronts
While we have tripled our staff, doubled our revenue, got our first colleagues in Israel and the US, and added our first US-based customer - all while achieving a lot of other firsts…
2020 will be more of the same and I sure hope that we will maintain and continue with healthy growth. Some of our customers are growing a lot themselves too. We will grow by 70% to 100% in revenue and a large part (but not all of it) will come from new customers spread across Europe and at least one in the US. Having laid the groundwork to support a lot more than our projected growth, we will not jeopardize our quality for new customer growth.
We won’t triple our team size again although we will be further distributed geographically and more diverse. After 2019, doubling will be challenging enough as everyone needs to find their home now in this distributed system. I think there’s A LOT of growth in swiftly getting this team through the storming and norming to achieve a high performing team of triple the size from last year.
So there you go, these are my predictions for 2020. What are yours?
Giant Swarm’s managed microservices infrastructure enables enterprises to run agile, resilient, distributed systems at scale, while removing the tasks related to managing the complex underlying infrastructure.
GET IN TOUCH
CERTIFIED SERVICE PROVIDER