If you’ve been in IT for any length of time, you know that once upon a time, basically all servers ran on Windows. That’s just how it was: Microsoft’s Windows NT operating system dominated the market, and the company charged plenty for the privilege of licensing their product so you could conduct business.
Eventually, though, Linux came along. As the open-source OS became more and more popular, it also began eating into Microsoft’s domination of the Windows server market. Users had multiple reasons for moving to Linux, but the biggest one was that Windows was very expensive on the server, and Linux was free. Alarmed by its shrinking market share, Microsoft countered with an advertising campaign based on Total Cost of Ownership (TCO).
Assessing a large initiative or purchase from a broader perspective than simple cost of entry, TCO includes the initial purchase price as well as all direct and indirect expenses over time. It includes expenses such as paying your engineers and sysadmins overtime to learn, implement, and maintain a less-mature operating system.
And such was Microsoft’s message to the IT world: Yes, Linux is free, but it’s difficult to maintain, and there are all these other hidden costs to using it. Microsoft even found a way to put numbers around all this. Based on research (and some Microsoft-sponsored case studies), the company claimed, it was 10 percent cheaper to run enterprise servers on Windows than it was to use Linux—even with Microsoft’s pricey licensing fees.
Whether or not that number was accurate, one thing was recognizably true: In those days, enterprises did have to invest more sweat equity in order to use Linux. And it was difficult to quantify what exactly those costs were.
Why are we even talking about on-prem servers now, when everything is moving to the cloud (and even Microsoft is running its own Azure Cloud Services on a Linux-based kernel)? This throwback glimpse into the IT of old is actually very relevant to Cloud Native transformation, though—at least the holistic way we approach it at Container Solutions.
We commonly have potential clients say to us, ‘Vendor X and Consultancy Y quoted us much cheaper rates, why are you so expensive’? Our answer is simple: Because we are offering transparency. When we give you a proposal to help you take on your Cloud Native initiative, we aren’t talking about simply coming in to install Kubernetes and then leaving. We are also talking about helping your entire organisation evolve how it delivers using your brand new tech. This human-centered transformation is so essential for ultimately succeeding with Cloud Native that we built a tool—the Cloud Native Maturity Matrix— to expose and assess it.
However, proposals from other tech consultancies never even mention the critical need for evolving your culture or delivery process, much less build in the steps for making it happen.
When we talk to clients about a Cloud Native initiative, we don’t just mean the cost of installing a cloud platform. We are talking about the Total Cost of Transformation (TCT).
Like the early days of Linux, Cloud Native tools and technologies are not yet fully mature. There is no full-service solution, no well-defined path to a guaranteed happily-ever-after, because we are still in the process of evolving enterprise-grade solutions. We would love to have an initial consultation and tell you exactly what we will do for your transformation, how long it will take, and how much it will cost. But we can’t, in good conscience, do this. Nobody can, really, despite promises to the contrary.
Everyone thinks that Container Solutions is in the business of selling technical solutions like Kubernetes. What we really, sell, though, is the next step. (K8s is sometimes that next step—but not always). The way we uncover that next step is by working directly with your teams to experiment and iterate, with hands-on learning as we move forward by eliminating options until the final best path is revealed. It’s not a linear process, but we have been doing this since before Cloud Native had a name. We won’t give you a low estimate and then come back to you asking for extensions or extra contracts because things haven’t gone as planned.
Because when we tell you what our services are going to cost, we are talking about true Total Cost of Transformation. All in, no surprises.
There are three elements that factor into an accurate and transparent calculation for the true cost of any given Cloud Native transformation initiative:
How quickly can you get there? We can help you build out a functional prototype in four to six months. If you try to do this on your own, the typical timeframe is more like two years. That is one and a half years of opportunity cost sunk into your best engineers struggling to build a Cloud Native platform and refactor your codebase—complete with dead ends, false starts, and a lot of wasted time.
Lower-cost offers typically go like this: A consultancy comes in and builds a platform for you. They may do a good job, but you don’t learn how to do it yourself. You’re stuck with them forever after, because if you want to improve or update, you need to bring them back. Or maybe just keep them around forever to run it for you.
The important question to answer here is, Is your Cloud Native transformation a temporary project, or permanent? A ‘temporary’ mindset means constantly paying someone else to handle things. A ‘permanent’ mindset means learning how to evolve and iterate your own platform and applications.
We can bring a company to self sufficiency in 6 to 12 months, because everything we do, we do together. Education from the start, training as you go, building together so you know how everything works. (Though if you want us to stay longer, we now offer Cloud Reliability Engineering services for long-term innovation and maintenance.)
By focusing on small experiments to identify good starting points and then more detailed Proof of Concept explorations to further refine the path, we only move in the direction that proves itself. Hearing about this process scares a lot of boards of directors, because they are used to being given a detailed plan. This exploration stage is crucial, however. By quickly reducing the cone of uncertainty, it eliminates options that are likely to fail—and thus reduces risk and the TCT.
So, yes, our proposal numbers might be higher than others. But we are working with your engineers, teaching them as we go. This is how a five-person team (two of our experienced experts, and three of your own most eager engineers) can have the impact of a 20-person team from a regular consultancy.
Ultimately, it doesn’t matter what the daily rate is. What matters is we can deliver an effective transformation in a shorter time, and with fewer people.
Photo by Jonathan Brinkhorst on Unsplash