• Jan 5, 2022
I made predictions for 2019 and 2020 and then we had this whole pandemic thing and it seems like I didn’t feel like predicting much for 2021, hence there’s no article. It’s about time I do it again since so much has happened in the last two years.
To share just some highlights from the past year…
We launched our Giant Swarm & Friends evenings, and who would have thought we would spend time with our customers, remotely, over a few beers, once a month, for hours, sometimes going until 2am.
We won a Deloitte Technology Fast 50 Award in Berlin. While we have often followed our own path, or as we like to say, “created our own destiny”, being recognized amongst such amazing market-leading companies as our fellow winners is an award in and of itself.
Winning an award was great but winning some time together in the sun at our Onsite in Croatia was just as rewarding. After 2020 and some false starts in 2021, finally gathering IRL felt like a victory and provided the fuel needed to finish this past year strong.
We welcomed many new members to the Swarm and some of our Swarmers welcomed new members to their families. To both Swarmers big and small we say: it’s so nice to meet you! We’re currently recruiting many new roles, check them out and join us.
Now that we’ve looked back on some of the highlights from 2021, let’s revisit some of my previous predictions and see how I fared.
I think this is a win, but it feels like a cheat. Of course, VMWare has not delisted Pivotal but we have more talks about replacing old installations by Pivotal, and VMWare itself has folded Pivotal into Tanzu, which is clearly focussing on native Kubernetes.
I have the added benefit of having two years to look at, but let's look at who has been acquired. If we just look at 2020, Pure Storage bought Portworx for $370 million, Cisco bought Portshift for $100 million, Suse bought Rancher, VMWare bought Octarine, Mirantis bought Kontena and Venafi bought Jetstack. In 2021, Microsoft bought Kinvolk, Suse bought Neuvector, Rapid7 acquired Alcide. I think this one is another clear win.
This is a harder one. The newest OpenShift has taken over a lot of features and parts of Lokomotive, the Kubernetes variant from Kinvolk that they bought some time back. Additionally, we know they are working on CAPI topics, even though it is mostly infra-related and not for Kubernetes on top but let’s see where this goes.
Yes, we were patient and we kept our service idea up and even improved it. It has become clearer that we help you in your path. We don’t jump on every hype train and we stay consistent.
Of course, this happened. This was easy. I knew this would be implemented, and boy how we've done it. By now, we have built teams around capabilities. Having moved to CAPI and become one of the major contributors upstream, we have built a team focused on the cloud building CAPA, CAPZ, and CAPG implementations, as well as an on-prem team working on CAPO (with the wonderful THG) and CAPV (with DTAG).
But what does the rest of the team do? This is where it gets interesting. We have Zachurity, built around our Zach for security (and yes, we are looking for only Zachs as additional team members for the fun of it), where we're building a full stack for securing your clusters. Then we have connectivity, which is working on everything that is getting traffic in and through the clusters, be it via Nginx, Linkerd, or Kong as an API gateway. Of course, we have our observability team with diverse monitoring and logging as well as a team around developer experience — think developer tooling, GitOps, and pipelines. I'd call it a 100% success.
Well, we had COVID-19 and we didn’t. The thing is that we did grow, immensely in maturity, a little bit with regards to employees, and more so in terms of revenue, but not quite 100% on multiple fronts. In this regard, COVID-19 was too much of a downer. However, I do think we are set for some great growth in 2022 but that comes next...
Well, now I need to make some new predictions and it remains that I should not be light-hearted. These need to be controversial at best and not brain-dead simple.
Now that many of us have managed to understand that this cloud-native thing is important and Kubernetes is here to stay, we need to get our shit together and figure this security thing out.
We have just announced our own managed security solution, and as always we're taking the iterative approach. However, there is stuff like Chainguard and probably a slew of others out there that are trying to look at securing the supply chain. For the not-so-tech-inclined people, I'm not talking about the supply chain as in shoes, but the supply chain as in software pieces. We have learned that DevOps is key, and teams are independent, but we also know everyone uses libraries, or base images, and whatnot, and they are all integrated from different sources. How do we make sure our push from today only adds our small fix and not a huge CVE though a dependency right with it?
There will be more towards the end of the year on how we make builds reproducible, how we make the entire chain secure, and especially what some best practices are, and in which circumstances. Some vendors announced that they have a way to deal with log4j instances that aren't patched to make them secure, only later admitting that they pretty much just turn them off. That's not how it's supposed to work most of the time. Neither is it about just leaving them running. I'm looking forward to a lot of different innovations, best practices, and open-source projects down this path.
It has been a thing for a long time but it's only slowly starting to be really visible now: Kubernetes at the edge. In 2021, we talked to a lot of people around factories, trains, shops, warehouses, and other use cases, some I might not even consider edge. However, one thing that's for sure: it's non-cloud and that means standardization and at best CAPI is key. This will only work if we make it very easy to manage remotely, easy to upgrade in place on certain schedules, easy to rope in security into a tight network, and also run enough servers to make it a cluster, etc. Kubernetes is great, and especially real cloud-native is wonderful, but it does come with its own challenges. A one-node Kubernetes cluster just makes very little sense no matter how you slice it. But a big ol' Java or C# app might need a lot of space, with clusters offering such space, meaning servers, and that escalates very quickly. I can seriously see it happening, but it will be interesting to see how, and important to look at individual use cases.
With lots of companies moving or still having to move to the cloud, and many not having radically unique business models, the focus especially from the cloud providers, but also anyone else, will be on value-added services. What I mean is that the big cloud providers will move from servers to databases to special purpose databases to services for a niche that needs a database. Why not provide the capability to launch and just have your entire product catalog handled by the cloud provider? Sure, there's a lock-in, but companies probably would have overcome that fear already. However, they will later figure out that there's deep lock-in and will have a hard time moving out of such systems. This will lead us towards the end of the year and to...
Companies will learn that they can't just follow buzzwords but that they need to understand open-source adoption and embrace the bazaar instead of the cathedral. They'll figure out that moving around is a lot easier if you use standards for real, and that this has value in negotiations but also in terms of choosing the best tool for the job. For UX, this might mean traction for things like ClusterClass, allowing for things to be built on top of CAPI that make it easier to use but that are still fully CAPI compliant, making different layers exchangeable at all times. This will only start towards the end of the year though when people start thinking about the next cycle. This will also mean that we will start seeing a trend back towards real data centers.
This one is easy. I just see it left and right. GitOps still needs us all to learn a lot of things, both for things we do with it now and for things that will be possible in the near future. But in general, the idea is very powerful and we have capabilities integrated into different parts of our stack allowing people to bootstrap from 0 until everything running in the clusters as well as the clusters themselves are managed through GitOps automation.
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