More companies like Ticketmaster, Huawei Technologies and IBM are using cloud native architectures - defined as container packaged, dynamically managed and micro-services oriented - to modernise their infrastructure. But what’s really involved in implementing a cloud native strategy?
Cloud native strategy
The author, Richard Rummelt, says that a ‘strategy is a way through a difficulty, an approach to overcoming an obstacle, a response to a challenge’. Cloud native computing is a valid way through difficult challenges, such as increasing business agility, reducing hardware costs or freeing people up to do more valuable work.
Going ‘cloud native’ is nearly always strategic. Think about these questions:
- Does the change cut across organisational boundaries?
- Does the change require skills we don’t currently have?
- Does the change require skills we don’t currently have?
If the answer to all of these questions is ‘no’, then a plan and a bit of common sense is very likely to be enough. If, however, the answer to one or all of these questions is ‘yes’, then a strategy is needed. Many companies don't realise this. They think of cloud native as a technical change. They thus rely on existing management practices - read common sense and planning - when actually what they need is something more powerful, namely a strategy.
Cloud native computing is a multi-faceted problem
For most companies, cloud native computing is a three-sided problem. On one side, you have application development. On another, you have infrastructure. Finally, on the third side, you have organisational issues.
To understand why the problem is three sided, we have to dig a little deeper into what a cloud native system is. A cloud native system is ‘dynamically managed’, ‘container packaged’, and ‘microservice oriented’. These three characteristics allow cloud native systems to be ‘optimized for modern distributed systems environments capable of scaling to tens of thousands of self-healing multi-tenant nodes’. It is the self-healing nature of cloud native systems that make it easier for businesses to recover from disaster, test new features and, of course, do so with much smaller teams and much less hardware.
Cloud native computing, then, is both three sided and strategic because:
- Dynamically managed systems are made possible by programmable infrastructure. It is programmable infrastructure that allows machine efficiency to be improved while reducing the costs associated with operations. Currently, for most organisations, this is not how applications are managed. In other words, in the cloud native world, we run applications differently.
- Microservice oriented and container packaged applications contribute to agility and dynamic management. For example, Kubernetes dynamically manages containerised applications, thus freeing up operations teams to do more value adding work. In other words, because we run applications differently, we build them differently, too.
- Finally, the ‘shape’ of a computer system nearly always reflects the ‘shape’ of an organisation. In other words, most companies cannot move towards microservices (thus cannot change the shape of their systems) without first changing their organisational structures. In other words, in the cloud native world, because applications are built differently, companies must organise themselves differently, too.
Because every company has different problems, every company needs a different strategy. Both ING in the Netherlands and Holiday Check in Germany have gone (or are on their way to becoming) cloud native. However, their approaches, tool choices and the order in which they did things were different. The difference in their strategies was affected by their location, the industry they work in and their business goals.
Companies who have created decent cloud native strategies did so by first having a rough idea what they wanted to do. However, to account for the multi-faceted, and complex nature of both cloud native computing and everyday, organisational life, they built into their strategy space to learn. It is through this space that new ideas emerge. As time moves on, strategies of the past become plans for the future. In other words, those who succeed with cloud native computing have done so by using an emergent strategy.
One way to take lessons from the past and apply them to the future is to get one thing (or team) working. Think of this as ‘nailing’ cloud native in one part of the organisation. After nailing a number of difficult problems, organisations can then think about scaling what they have learnt. It is through this process of nailing small things that strategies start to emerge, as in ‘image 2’. Only after doing this for a while, will our strategy start to become clear.
Another way of thinking about this is by looking at the J-Curve. Many companies get bogged down in (often pointless) discussions about what to do next. They argue about choice of orchestrator before they’ve learnt about containers. They wonder how 100 people can begin to continually integrate their code when they haven’t even managed to get one team to do it. One way to break this sort of deadlock is to think about changes as small investments.
Once a team understands the emergent strategy model and therefore that they need to experiment in order to generate knowledge, they can then use the J-Curve as a way to reason about their next steps. The J-Curve is a simple enough idea. On the vertical axis, we have cost. Once started, an experiment starts to burn money. Because organisations don’t want to burn too much money, a maximum amount is decided in advance. For example, one team may spend one week containerising their application. If this experiment turns into an adaptive change, i.e. if the experiment leads to a better way of working, then the organisation will start to recoup its investment. Once the J-curve hits the horizontal line, the experiment starts to break even. After that, the investment will start to make a return.
A ‘failed’ experiment is the cost of knowledge - we now know what doesn’t work. It is these failures that push us towards our next actions. Few organisations get their cloud native strategy right without some failures. Navigating these failures is an essential part of getting strategy right, and each one must be looked upon as an opportunity to learn. Thus, emergent strategy relies on many, small, experiments, each of which, one way or the other, points towards our next step.
For many organisations, cloud native computing is a multi-faceted problem. Those who succeed with cloud native computing do so because they treat it as a strategic change. This means they see the big picture whilst also seeing the details. They can also see what they just did and apply what they learnt to what they see in front of them. They welcome success and failure, knowing that actions and the passing of time are what leads to new, ‘emergent’ strategies. And finally, exactly because strategy is rooted in actions, they see it through. With an implicit or explicit understanding of the J-Curve, they work to finish what they started, learn along the way, and by doing so they inch ever closer to their own cloud native strategy.
Image Credit: Everything Possible / Shutterstock