.avif)
Everyone’s looking for the right moment
One of my favorite parts of being a pre-sales Solutions Architect is talking to customers across various industries, who are all at different stages of their Kubernetes journeys.
Some are startups, building everything fresh on managed Kubernetes from day one, taking advantage of the ‘easy button’ with services like EKS Auto.
Others are proud DIY and open source shops, rolling their own tooling to be the next Netflix or Google.
Others are decades-old enterprises still keeping mainframes alive and paying Microsoft or Broadcom hefty fees for enterprise agreements, while trying to figure out how containers fit into their world.
No matter where you are right now or where you want to be, if you’re on a Kubernetes adoption journey, at some point you’ll start to wonder whether you should invest in more serious tooling — an enterprise Kubernetes management platform — to help you solve the complexity of operating your clusters at scale.
You probably don’t want to waste budget building or buying a beefy solution too early: one small cluster doesn’t need a lot of management.
But equally you don’t want to wait until the accumulated tech debt and issues are affecting your business, or face migrations from point solutions that you’ve outgrown.
The right time will be unique to your business, its budget cycles and growth ambitions, and the skills and resources in your team. But there are a few common trends, shared truths, and useful items to ponder when it comes to tools that can help you get to your destination. In this blog we’ll help you identify a few clear inflection points that we see in the field.
When you’re starting “greenfield” rollouts
It’s rare that you’ll ever have the opportunity to work in a truly clear greenfield situation. Even startups building their first production environment will likely have to work with the custom scripts and fragile environments spun up to bootstrap the first demo.
A more likely scenario is the launch of a new product application or building infrastructure to support a new business unit.
While a centralized Kubernetes management platform that can handle large scale may not be essential for initial rollouts, there is a ton of value in defining your stack centrally and using automation to stamp out consistent clusters as your environment grows.
Sorting out roles and responsibilities early helps ensure new hires are not only given the right tools to do their job but also ensures that they only have access and capabilities applicable to their role.
This is where platforms like Palette tend to shine: You can start small, stay flexible, and scale without rebuilding everything later.
When your current vendor makes your life difficult
We hear (sadly) many stories from customers who are unhappy with their current Kubernetes management platform.
Many of my colleagues here at Spectro (from pre-sales to support engineers) have worked either in the channel, or for other K8s companies like Rancher, Red Hat or D2IQ, and we’ve seen it first hand.
To be clear, these stories are very rarely about companies outgrowing their toolset (which would be a kind of tech debt, and a natural part of evolution).
Instead, some users find they just don’t get the responsive support they need for production clusters. More painfully, sometimes the product completely fails to do what it claimed during the initial evaluation, particularly when tested at scale.
Another ugly pattern we hear about all too frequently is customers getting hit with massive price hikes. Vendors with multi-year contracts and licensing agreements will often use renewal periods as an opportunity to leverage lock-in to increase pricing to a point where it makes financial sense to make a change.
This unpleasant pressure can be turned into a business advantage. It is a moment when you can step back and evaluate how much value you are receiving from the vendor’s solution. If the hassles outweigh the benefits, it makes for a great opportunity to consider alternate solutions.
The right Kubernetes management platform can resolve this dilemma by eliminating vendor lock-in and giving you control. Some even give you the ability to bring your existing clusters with you.
When you expand to the edge
Running at the edge is where Kubernetes complexity really shows up.
We are seeing more and more customers deploying production Kubernetes workloads to remote edge locations particularly in the retail, healthcare, manufacturing, and oil & gas industries.
Edge environments introduce a host of new problems, including:
- Hardware and networking constraints
- Physical security risks
- Limited troubleshooting options
- High cost of truck rolls
- The need for autonomous operation
Scale magnifies all these issues, and it exposes the gaps in process and tooling that teams often cover through sheer herculean effort.
You can't be doing one-by-one cluster management when you have thousands of edge locations. And you can't rely on a cloud-managed K8s service to stand up the cluster for you. You need to find a way to manage provisioning. That’s a great opportunity to look for a full lifecycle management tool.
(At this point I can’t resist mentioning our work at the edge).
When you become “multi-anything”
As our research proves, many enterprises are already multi-cloud for their Kubernetes clusters. This can happen by choice: many enterprises like to play vendors against each other to ensure price competitiveness, to spread risk, as an added layer of redundancy and reliability to protect against outages, or to benefit from unique services. Others end up multi-cloud by default after organizational changes such as M&A.
But multi-cloud isn’t the only ‘multi’. There are multiple environments (bare metal, virtualized data center, etc). There are multiple K8s distributions and stacks. Multiple development teams to work with, each with their own preferences and pipelines.
The unfortunate reality is that every “multi” step increases complexity. It means additional work to verify your application and business processes, including ensuring that disaster recovery and continuity are acceptable in each scenario. The added failure points of integrations combined with the vast scope of disparate environments quickly becomes nearly impossible to manage.
Unifying and standardizing on a management platform that gracefully supports the diversity of modern infrastructure can take the pain away.
The “boomerang” customer
Some of my favorite conversations are with companies filled with very smart and capable engineers who have a long history with open-source tools.
They are often ones utilizing methodologies like GitOps, automation tools like Terraform or Ansible, infrastructure management standards such as CAPI, and they are very familiar with their provider’s cloud console and handy with direct kubectl access for troubleshooting and operation. It is extremely impressive what a small team of talented engineers can build.
It’s no wonder then that these guys tend to be extremely resistant to buying a commercial management platform, particularly one that has some closed source components.
We get it! Cost factors aside, there is an argument to be made for tools that are open and flexible and that allow a competent operator to do things exactly as they want. Lock-in is a bad thing, we all agree.
As you might expect, these conversations usually don’t end in a sale for us. But the funny thing is, the same folks often come back to talk to us again about a year later. It happens so often that we have a name for it: we call them boomerang customers.
So what’s the story?
For a while, these DIY projects appear to be working beautifully. But soon the platform teams find they’ve become a prisoner of their own creations. Every time there’s a change in part of the tech stack, their fragile custom scripts and tooling needs to be updated and tested. There’s no vendor to turn to for support. When engineers leave or get reassigned, important knowledge about the codebase is lost.
Sure, when you DIY you are master of your own destiny — but it’s a lot of work, particularly for a small team. And when new requirements hit (whether it’s a major increase in infrastructure scale, or a whole new initiative like edge computing), the home-rolled platform may not be ready.
We love talking to these customers, not because it’s a “told you so” situation, but because by the time we have that second conversation, they deeply understand the importance of a well-engineered platform, and the value it delivers to their business. They also deeply appreciate both sides of the build vs buy equation.
So…when is the right time?
If you haven’t encountered any of these difficulties, you might not be ready for a product like Palette yet. Conversely, if you’re finding yourself suffering from Kubernetes infrastructure management troubles like more manual work than you can handle, team burnout, growing backlogs, unpatched security vulnerabilities, outages, inconsistent clusters, overwhelming upgrades, cost overruns, and more, you might have been ready to make the change some time ago. In that case, there’s no better time than now.
If you’d like to learn more about how Palette can help simplify Kubernetes management for you, book a demo here, or learn more about Palette’s cluster lifecycle management features here.