Enterprise infrastructure modernization does not necessarily require organizations to choose between Windows and Kubernetes. Increasingly, enterprises are running Microsoft SQL Server on Windows while introducing Linux, Kubernetes, and cloud infrastructure elsewhere in the same environment.
That mixed infrastructure creates an opportunity for channel partners to help customers modernize SQL Server environments incrementally rather than forcing large-scale platform migrations. Partners can help customers address availability, resilience, hybrid cloud architecture and workload portability while preserving infrastructure that still works.
Channel Insider spoke with Don Boxley, CEO and co-founder of DH2i, about why Windows remains deeply embedded in enterprise SQL Server environments, where Kubernetes fits into the modernization roadmap, and how partners can help customers bridge Windows, Linux and cloud infrastructure.
Why Windows and Kubernetes are becoming complementary
Don, everybody talks about Kubernetes, but Windows is obviously still a huge part of enterprise IT. What are you actually seeing from customers?
That’s exactly it. Windows is still incredibly important. A lot of SQL Server environments have been running on Windows for years; they work, and they’re running critical parts of the business.
But at the same time, you’ve got other parts of the organization moving toward Linux and Kubernetes. Applications are being modernized. Development teams are using containers. So now you’ve got Windows over here running the database and maybe Kubernetes over there running applications.
That’s the problem customers are asking us to help solve: How do I bring those worlds together? And our answer is: you don’t have to do it all in one bite.
So this isn’t really a “Windows versus Kubernetes” story?
No. I think that’s where people can get this wrong. It’s going to be Windows, Linux, and Kubernetes for quite a while for most companies. And that’s okay.
What we want to do is give customers a way to run those environments together. You can have SQL Server running on Windows today. Add a Linux node tomorrow. Add Kubernetes when you’re ready. And manage that as one availability environment.
For modernizing, that is much more realistic.
Why has that transition taken longer than people expected?
Because enterprise infrastructure has gravity. If for 10 or 15 years you’ve got a SQL Server environment that’s been running successfully, you’re not going to change it because somebody walked into a meeting and said, “Kubernetes is the future.”
Why? That’s the first question you’re going to get.
What’s the business reason? What’s it going to cost? What’s the risk? What happens to availability? What happens to the applications that depend on that database?
Those are legitimate questions.
And there’s another piece of this. Some customers aren’t running the latest SQL Server releases yet. Our telemetry is showing us that there’s still a lot of older SQL Server infrastructure out there. So before some companies even think seriously about Kubernetes, they’ve got some modernization work to do on SQL Server itself.
Your telemetry is also giving you a better picture of the Windows/Linux mix, right?
Yeah, and that was actually pretty interesting. Among the customers where we’re currently collecting that telemetry, we’re seeing roughly a 60/40 Windows-to-Linux split. I thought that was pretty telling.
Windows is still the majority, but Linux has clearly become a significant part of the SQL Server world. And Red Hat is the number-one Linux distribution we’re seeing, with Ubuntu close behind.
So again, this isn’t one platform disappearing and another one suddenly taking over. It’s becoming a much more mixed environment.
Hybrid and multicloud make platform flexibility more important
How does cloud adoption complicate that mix?
Absolutely. We’ve got a lot of customers with Azure, which makes perfect sense given their Microsoft environments. But we’ve also got customers using AWS, Google Cloud, or combinations of them. That’s where being platform-agnostic becomes really valuable.
You could have Windows running on-premises and Kubernetes running in Azure. Or AWS. Or Google Cloud. From our standpoint, those are nodes in the cluster.
For the DBA, I’ve got SQL Server here, I’ve got a primary, I’ve got secondaries, and I need to keep the database available. That’s what they should have to worry about, not stitching together a bunch of different HA technologies because the infrastructure underneath each replica happens to be different.
Is AI accelerating any of this?
In an interesting way, yes. What we’ve seen with some customers is that AI is creating an opportunity to look at infrastructure that they probably needed to modernize anyway.
Significant money is being spent by companies on AI. Once you’re having those bigger infrastructure conversations, suddenly somebody can say, “Okay. While we’re doing this, we also have this SQL Server environment that we’ve needed to address for the last five years.”
So AI isn’t necessarily the technical reason they’re moving SQL Server from one platform to another. I don’t think we have enough visibility to say that. But it can be the catalyst that gets the broader infrastructure conversation going.
Why incremental Kubernetes adoption lowers migration risk
What about the IT leader who says, “Everything works. Why should I touch it?”
That’s the right question! If everything works, you better have a good answer for why you’re asking somebody to spend money changing it.
At the end of the day, there has to be a business case. Maybe it’s cost. Maybe it’s resilience. Maybe it’s operational simplicity. Maybe the organization wants more flexibility for where workloads run. But “we want to modernize” by itself isn’t enough.
That’s why the incremental approach is the one I like best. “We’re moving everything to Kubernetes next month…” is not something you have to say. “Let’s put an architecture underneath SQL Server that gives us that option. Then when the business is ready, we can move granularly…” is what you can say.
Q: Does that also lower the risk?
Tremendously. Let’s say you’re running SQL Server Availability Groups on Windows today. We can get you onto DxEnterprise, and now you’ve created that foundation. You’re still running Windows. Nothing says you have to change that. Then maybe you add Linux. Maybe later you add Kubernetes. They can be run side by side. You decide where you want the primary workload to run once you’re comfortable and you’ve tested everything.
That’s very different from saying, “Friday night we’re ripping this whole thing apart and Monday morning we’re Kubernetes.” That is not something anyone ever wants.
What’s the one thing you want an infrastructure engineer or DBA to take away from this?
That this is a lot more manageable than you probably think it is. A choice between Windows and Kubernetes does not need to be made. The environment that is working doesn’t need to be thrown away. And, everything doesn’t need to be modernized at once.
You can start with the Windows SQL Server infrastructure you have today. Bring Linux or Kubernetes into the picture when it makes sense. And move at whatever speed is right for your organization.
That’s really what we’ve been trying to solve: give customers a practical way to get from where they are to where they want to go – without making the journey harder than it needs to be.