How do I get there from here? Two first rungs on the ladder to cloud?
If only we hadn’t called it ‘cloud’. I sometimes wish that the technology industry had come up with a better term for the global, hyperscale, software defined platforms that I believe will form the dominant computing infrastructure of tomorrow. ‘Cloud’ implies something nebulous, light and airy, something that is impossible to touch or pin down. In real life, the physical implementation of cloud is a long way from this image: it is made of servers, storage arrays, network equipment, cables and physical facilities. The cloud is something you can weigh.
However, there is one way in which the term ‘cloud’ is useful. When we think of a cloud we think of something which is way up in the sky, something that is difficult to reach for mere earthbound mortals. The reason that I think that this image is useful is that it represents something true about cloud: that answering the question, ‘how do I get there from here?’ is difficult. To reach a real cloud, you would need a very long ladder and you would have nothing to lean it against. Getting to the computing cloud from your on premise starting point can seem like just as much of an acrobatic balancing act.
A lot has been written about the technical aspects of cloud migration, and I do not intend to replicate that here. I don’t have much to add to the language of R-types (re-host, re-platform, re-factor, re-architect and so on), or to VM or container migration techniques. Similarly, in this article, I don’t intend to get into debates about migration tools, portability standards or security patterns, What I hope may be useful are some ideas about how to think about and organise the less technical aspects of your journey to cloud. There are seven ideas I’d like to explore: that’s a few too many for a single article, so I’ll attempt to tackle two here, and continue next week. This may take two weeks; it may take three. Let’s find out.
Motivation
Like many things worth doing, moving to cloud from an established on-premise architecture is hard. Like all hard things that you choose to do, it’s a good idea to know exactly why you’re doing it.
There are many reasons to move to cloud: agility, resilience, security and (if you do things right) cost. But it is rare for all of these things to matter equally to any particular enterprise at any point in time. If your cloud migration is to go well, it’s important to know what matters to you most, and even more important to ensure that this clarity is shared across your organisation.
Without this clarity things can easily go wrong. For example, imagine an infrastructure team driven by short-term, tactical challenges: data centre leases are about to expire, and core infrastructure components such as OS images are out of date. A move to cloud represents an opportunity to fix risks: speed matters. Yet the architecture team believes that the move to cloud should be driven by the agility arising from cloud native applications. They refuse to sign off ‘lift and shift’ migration patterns in favour of more profound refactoring. Which is right? Unless your motivations are clear, you may be stuck in stasis as internal teams argue with each other, and precious time ticks away.
Ambition
Cloud platforms hold out the promise of providing a new home for enterprises. There is very little that cannot be done at least as well on cloud as on premise: and the residual set of things which are hard to do on cloud is shrinking.
And yet many enterprises still seem reluctant to move into their new home. They are reticent about saying that everything will move to cloud, even if the day of completing that move is a long way off. They hedge their bets with private cloud investments whose value is often questionable (the subject of a future article). Project managers and development teams who have been agitating for access to cloud suddenly get cold feet when they realise that they will be one of the first tenants.
I believe that to get most value out of cloud, enterprises should be ambitious, and should be explicit about that ambition. The day will come when any retained traditional infrastructure becomes a drag on innovation, reliability and resilience - and the companies that have been the most successful in reducing this drag will do better than those that have not. This does not mean a reckless or foolhardy charge to the cloud faster than organisations can manage. But it does mean being wholehearted and ambitious about the destination. I would go so far as to say that, if you expect your cloud platforms to become just another set of environments that add to the many different types of environments that you already run, just one more layer of complexity in your architecture, it might be better to spend your attention elsewhere.
To make these thoughts about motivation and ambition real, to make them more than just exhortations to clarity and boldness, let’s consider what practical action they imply. I believe in the power of writing down strategy, and I particularly believe in the importance of defining strategy for difficult, complex initiatives. Anyone embarking on a cloud journey should define an explicit cloud strategy understood, endorsed and sponsored by the leadership of the company. The first sections of this strategy should address the two topics outlined in this article: motivation (why are we moving to the cloud?) and ambition (how far and how fast are we going to go?). If you don’t have a cloud strategy, or your cloud strategy does not define your motivations and your ambition, perhaps it’s time to get the pen out again.
If you know the reason for your journey (motivation), how far you are prepared to go (ambition), then you have some good starting points. But that’s not enough: in my next article, I will explore the importance of leadership, thought, empowerment, balance and persistence.
