At Container Solutions, when we say we help companies transform themselves into Cloud Native entities, we use that term for a very specific reason. Cloud Native is a major paradigm shift, not just the latest new tech to be bolted on top of whatever else a company has been doing for years.
The last true paradigm shift was Agile, which arose 20 years ago and is still not finished. Few people are actually doing pure Agile, though many organisations identify as such. Most don’t really understand Agile—and definitely don’t practice it. Nevertheless, many people have adapted at least a few Agile tools, and thus think of themselves as Agile.
A bigger concern is the common notion that Cloud Native is merely an incremental stage of Agile—the next step, as it were. But this is both untrue and potentially dangerous. CN is not some forward iteration of Agile. It’s a true paradigm shift. It’s Agile’s replacement.
Why does this matter? For us, this is something we figured out while conducting Cloud Native readiness assessments. This means that, practically, it is something we need to be aware of when conducting maturity assessments in such organisations.
Real world example: One client, Waterfall with Agile tendencies (sprints and Scrum masters) called us in to consult for their cloud migration. They took our analysis and feedback and compiled an 80-page report, taking four months to put it together. If you have 80 pages of diagrams and documentation, you’re not Agile. And in CN, if you give us four months, we could deliver an entire system.
When the decision is made to move to CN, everything you do should be reconsidered, and on all axes. From culture to technology. Assume everything you do is wrong, and ask yourself how you can improve. As you can imagine, this 'you need to change everything' message, is quite alarming for customers. But it’s the right path.
The core problem for any company looking to do a Cloud Native transformation is that they simply don’t know what they don’t know.
The Scary But Necessary Path
This is particularly challenging for traditional Waterfall companies. In their 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 their product. The engineer says three months, which their manager doubles or triples to factor in other considerations and produce a realistic timeframe. But this is a linear extrapolation, and everyone understands the steps involved.
In the case of a Cloud Native transformation, though, the engineer has no basis for estimation. They have no experience with the technology and techniques, so they make their best guess—which, due to the exponential difficulties and complexities inherent in distributed systems will be wildly wrong. They say one week and it turns out to be one year.
In the same vein, their manager hears an estimate of three weeks, 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 understand why it is this way. They don’t know what they don’t know.
What happens next is, the manager quickly runs out of budget and patience. The typical enterprise has patience for one to two years; our very best, most cloud-ready customers take a year to do their migrations. Most companies take much longer.
Real world example: We once had a client with OpenShift (the container application platform) installed and one app running in testing. Based on this perceived success, they decided 'OK, now we will onboard 10 teams in the next three weeks. We are ready to go completely Cloud Native!'
This was based on how they had always done things previously, and in that context, it was an understandable decision. However, what they did was install a bunch of expensive, complex tools on top of the same system they had always used. Yes, they would have Kubernetes—but they would still deploy every six months.
It takes a deeper understanding to see that, while this was undertaken as a step forward, it is actually the opposite. When we look at the value the change ultimately brought to the company, it is in fact negative.
True, you can point to having containerised microservices and believe that makes you a Cloud Native company. In reality, though, you have just spent a lot of money and invested a lot of work—but you are not faster or cheaper.
Typical Cloud Native Transformation Scenarios
We at Container Solutions have been doing Cloud Native long enough now that we have been able to identify some commonly occurring CN transformation situations. These are scenarios—perhaps different in detail, but extremely similar in structure and origin—that we often find when coming in to assess an enterprise. Either for a brand new migration initiative or, more often, when called in to figure out why such an initiative has gone wrong.
This post is one of several where we examine various frequently occurring transformation scenarios, what they look like, why they happen—and what to do to solve them. These scenarios and solutions can also be found in our forthcoming O’Reilly book, ‘Cloud Native Transformation: Practical Patterns for Innovation.’
Previous article
