In the last two blogs on this subject we talked about Cloud Native computing and about strategy. In this blog, we'll put the two together and consider Cloud Native Strategy - what it means and how to do it.
In our first post we defined Cloud Native as a toolbox of approaches (IaaS or PaaS, microservices, containerisation and orchestration) for helping with three potential business objectives:
We also said that Cloud Native strategies tend to:
In our second post we looked at seven key elements of strategy, including goals and actions we take towards them.
Overall, we highlighted the changes that cloud has brought to IT strategy by de-risking infrastructure decisions. Basically, the cloud makes it possible, or even preferable, to be more experimental and decide less up-front.
In this post, we are going to talk about how even with the more experimental and lower-risk Cloud Native approach it still remains critical to consider Jamie’s seven elements of strategy:
The cloud is a highly uncertain environment subject to constant change. It happens that in the cloud some decisions are less irrevocable and thus less risky than in a privately-owned environment. That gives us interesting new opportunities - but also generates some new threats.
“Being Cloud Native” is not an end in itself, it’s merely the rocket by which you reach your ambitious destination of choice. A Cloud Native (CN) strategy allows you to achieve a defined business objective by exploiting cloud infrastructure and tools like containers and orchestrators.
We’ve talked about some common goals but every business must define its own objectives based on good situational awareness - understanding of both the opportunities and the issues the business faces. For example, right now is the most important goal faster delivery on new features for an established product? Or reducing operational costs? Or improving response times in new regions? You may have noticed that these are all business goals not technical ones. The value of a Cloud Native goal is generally to the whole company not just the IT team.
Some common Cloud Native objectives may seem contradictory. Don’t worry, that isn’t just you misunderstanding them - they genuinely can be. For example, Company A may need feature velocity and ease of development. They might choose a Cloud Native architecture that is slower to run and costlier to operate but is easy for a large team to develop on simultaneously and deploy to quickly. For them, that is success - their goals of quick and easy development are met.
Company B may prioritise site response times. They choose a Cloud Native architecture that gives them higher execution speed but makes development a bit slower and more difficult. For them, this is success - their response-time goal is met.
The lesson here is that choosing “Cloud Native” does not define your business priorities, you still have to do that through situational awareness. If a business has different priorities in different areas, which isn’t unusual, they may have more than one CN strategy and that is fine. One of the strengths of a CN approach is it can achieve more than one thing. However, that is also dangerous - if you’re not clear what goal you’re trying to achieve it isn’t obvious what you’ll get.
So the first step in a Cloud Native Strategy is review your situation and define your goal.
A CN strategy often aims to be cloud agnostic - it doesn’t depend on any one unique cloud service or vendor. However, vendor lock-in is just another risk to be weighed up against potential advantages. A Cloud Native approach de-risks many infrastructure decisions by making them reversible but it does introduce new supply chain dependency risks.
The next step in your strategy is understanding what risks you are willing to take.
Every Cloud Native goal, such as a scale target, has many sub-goals and each may require its own strategy. Once you’ve decided on your overall objective, the first step is usually to identify a well-defined sub-goal and start tackling it with self-supporting actions. A simple strategy for a limited, clearly-defined Cloud Native goal within a single team or group might be to take very small, low risk, exploratory steps without a detailed plan and with frequent review of the results. Sometimes though, a simple iterative process is not enough. It is important to step back once more and gauge the difficulty of what you are trying to achieve. A lot of that difficulty will arise from the complexity of your working coalition.
Some changes are easy to achieve - maybe a repetition of something we’ve done successfully in the past. Some are purely technical and low-risk, so a suck-it-and-see experimental approach can work without hard up-front thinking. But consider these questions for a moment:
If the answer to all of these questions is ‘no’, then a simple spreadsheet, a bit of common sense, a small team, and an experimental approach is very likely to be enough. If, however, the answer to any of these questions is ‘yes’, then this is a more difficult objective and you will have to form a cross-business working coalition.
Many companies don't realise this. They think of all Cloud Native change as purely technical change. They thus rely on existing management practices - read common sense and a list of straightforward activities - when what they need is something more powerful: a strategy.
When we realise our objectives are going to be tough to achieve, we need to step back and reconsider the classic components of strategy: our goal, vision and willpower, our current situation, the risks, our self-supporting actions and our working coalition. We also need to be aware that whatever we do there will be no glamorous big bang finale - this is a continuous process.
Whilst building this consensus we probably want to get agreement on some concrete foundational stones of the project (self-supporting actions) that might be controversial and more costly to change later. For example, choosing a single cloud vendor or a multi-cloud approach.
Making any complex coalition deliver relies on having a compelling vision and considerable willpower. Cloud Native is a continual process - there is no “big bang” to aim for. There will be lots of small wins to celebrate but missteps too (this is all very new) and everyone has to remain motivated to keep going. For every company we have spoken to, Cloud Native has been a gradual process of years, there are no magic final release dates.
In our next post we’ll talk more about the three most common business goals of Cloud Native: speed, scale and margin.
Read more about our work in The Cloud Native Attitude.