The core problem for managers at any company contemplating a Cloud Native transformation is that they don’t know what they don’t know. They don’t even know how long it will take, so they come up with estimates based on the way they’ve previously worked. These estimates are always wildly wrong, for a number of reasons.
Coming from a traditional Waterfall predictive approach, it’s understood how things work. For example, an engineer is summoned for an estimate of how long it would take to make an iPhone app for a company’s product. The engineer thinks this over and says it will take three months. Their manager then doubles or triples that to factor in other considerations and produce a realistic timeframe to report upward to the next level. This is a linear extrapolation, and it works with reasonable accuracy because everyone involved understands how the system works.
If you ask the same engineer to estimate how long a Cloud Native transformation project, or even part of one, will take, they will do their best to give you an answer that they believe is realistic. Unfortunately, though, the engineer has no basis for estimation. They have no experience with the technology and techniques, much less the architecture, so the best they can do is make a guess.
And that guess, due to the exponential difficulties and complexities inherent in distributed systems, will be wildly wrong. They say one month, and it turns out to be one year.
In the same vein, their manager hears an estimate of one month, does the usual extrapolation and comes up with three months … but really, it’s three years. Only they have no way to know this, or to understand why it is this way.
What happens next is fairly predictable. The migration initiative launches, and everyone expects it to be done pretty quickly. Unfortunately, this does not happen, even with considerable resources allotted to the project. Everything is a great deal more complicated than the tech team’s optimistic early experiments on Google Cloud or Azure led them to believe. Management is understanding, gives them first one extension and then another, but eventually the project runs out of budget and the company’s leaders run out of patience.
At this point, their thinking goes, they have poured a year or two into a cloud transformation that has led nowhere. Is it time to simply pull the plug?
This entire frustrating process is due to poor expectations management. If executives had known up front that the project could take up to two years to complete, they would have proper context for the rate progress should proceed. Knowing this, they could make appropriate deductions, allocate budgets and manage their own stakeholders. But instead it starts as a three months project, fails to progress at anywhere near that rate, and so requires endless extensions until everyone runs out of patience.
A Reality-Based Time Frame
The key to solving this frustrating deadlock, or preventing it from happening in the first place, is starting out with reasonable expectations.
First and foremost is the need for reasonable expectations regarding time frame. When it comes to a large technology shift, the typical enterprise has patience for one to two years. However, our very best, most cloud-ready customers take at least a year to do their migrations. Most companies are nowhere near this knowledgeable or prepared, and so the process takes them much longer.
The second is the need for reasonable expectations regarding how a Cloud Native system grows and extends as you build it. It’s not linear!
For example, we had one client who had OpenShift installed and one app running in testing. The client then decided they would go to production based on this setup: “OK, now we will onboard 10 teams in the next three weeks.”
They assumed this would work, based on how they had always done things before. And this assumption—trying to do Cloud Native using Waterfall methods—is the root cause of why many transformations fail.
Cloud Native Isn’t Turn-Key
Cloud Native is not simply new tech, but a genuine paradigm shift. Most well-established companies now considering Cloud Native think they can simply buy their way into a new operating system, the way they have always been able to do it before. Buy the new big thing, move everything over to it, then you’re done for the next 10 years.
Unfortunately, Cloud Native is not a turn-key proposition. Understanding Kubernetes or installing Istio does not begin to solve things.
The last major paradigm shift was Agile, 20 years ago—and really, that is still not finished. Even by now, few people are actually following purely Agile practices. But there is this persistent and pervasive belief that Cloud Native is just the next incremental stage of Agile.
Many companies call themselves agile, and many have indeed adopted a few of the outward trappings, like sprints and daily standup meetings. Most of them don’t really understand Agile, though, and definitely don’t practice it.
We worked with a very large company recently that considers themselves Agile, but still they move very very slowly. They needed four months to compile an 80-page report on installing Kubernetes, complete with diagrams and documentation. Installing Kubernetes as an experiment is not a bad idea. Treating it as a Waterfall project—spending months and months creating diagrams and trying to foresee all problems, all contingencies, before even trying it—that is a bad idea.
If you need four months to do a report, you’re not Agile. In Cloud Native, we could deliver a whole system in four months!
Throw Away the Old Maps
In Cloud Native, everything you do should be reconsidered, from culture to technology. Assume everything you do is wrong and ask yourself how you can improve.
This message—you need to change everything!—can cause customers to panic. But we can show them that it’s not impossible; that other companies have done it, and so can they. They just need to accept that they don’t know what they don’t know, and to stop trying to control everything.
The old ways are about identifying all the risks up front and planning for them. Cloud Native is about not knowing everything, and being comfortable with that.
Think about Cloud Native in this way: imagine you are in a new place, a new city, with no maps. You are told to go from point A to point B, but you don’t know the layout of the city. You can try using a map from your hometown to figure out this route. It will take you somewhere, absolutely—just not to your intended destination.
So instead, you explore. You walk around a little bit, in circles, getting the lay of the land nearby, then in widening circles. Eventually, through experimentation and gradual learning, you will find your way.
This is how it works with Cloud Native. There is no map. The path to a successful transformation is made by walking.
Want to find out more about Cloud Native? Download our free eBook below:
Previous article
