Cloud native architecture can practically endow software developers with superpowers by granting project velocity, scalability, increased security and reliability, even cost savings. An undeniably potent combination of capabilites -- but only if we use them correctly.
As we explored previously in When is the Wrong Time to Use Kubernetes?, the desire to modernise infrastructure and go Cloud Native is a good thing. But the component technologies are complex and not yet widely understood, which too often leads to enterprises thinking they can make a quick jump to the cloud (and, often, by “cloud” they actually mean Kubernetes) to solve all their problems...Without any understanding of the crucial steps that must happen first.
Very recently we had a potential client approach Container Solutions for a proposal to deploy Kubernetes for their enterprise. We did a thorough and detailed discovery and analysis of their current system and provided a lengthy report.
The client had asked specifically for Kubernetes, and our proposal included it -- along with CI/CD, automation, security, and processes. Everything necessary for achieving the full potential of the platform and tools, done in the correct order.
The client was not happy.
We heard back very quickly that our proposal was going to take too long and included too many things to be done. The client insisted, quite clearly, “All we really want is the Kubernetes.”
This response told us what we already had sensed: this company is after a unicorn solution. A quick, single means of magically solving all their problems. And they had decided their unicorn would be Kubernetes.
This is similar to going to a doctor when you are sick and then telling them what your own illness happens to be before asking for a specific medicine. Every professional, no matter what their field, will first diagnose the situation and offer one or more appropriate solutions. It sounds quite absurd to invite a professional in, and then tell him what to do and how to do it...and refuse to consider any other option.
However, knowing that cloud native can be mysterious to those new to the architecture, we explained - again - the choices our proposal suggested, and why. And that, furthermore, installing only K8s would create many more problems than it solved. That it would in fact work against the company’s own desire to become more agile, secure and just better in general.
Again, we heard back very quickly. The client was clearly perplexed at our refusal to simply do the thing they wanted done. They pointed out that other cloud native consultancies were perfectly happy to provide them with Kubernetes, in much less time and without all those “unnecessary extras” like CI/CD and security.
Clearly our attempts to explain had failed. The only thing left for us to do was to gracefully exit the discussion.
Container Solutions only takes on cloud migration projects when we know we can stand behind the solution. We responded that, given the results of our assessment, we knew that a lot of things needed to happen in order to for them to benefit from moving to such an infrastructure. That giving them the solution they were asking for, installing only Kubernetes, would not help them in any regard. That we were sure they would find other companies willing to do it, and for less than our price. We even offered to provide some contacts.
And that was that.
When implemented properly, microservices, containerization, and orchestration can revolutionize how development gets done. But this needs to happen in iterative steps, each one building on the one before.
Jumping ahead to any single one of these “magical” solutions can easily result in improper, or even disastrous, implementation.
We regret that we weren't able to work with this client. But we do wish them best of luck with their unicorn hunt.
Want to learn more about Cloud Native? Download our free eBook below.
Previous article
