Not just someone else’s computer: to understand cloud, go back to the start

Do you believe that the cloud is just somebody else’s computer? If so, then I have to disagree with you.

I could say that this is because a computer is just a machine, whereas a cloud is a fully architected, software defined, API managed platform, that is at least as much software as it is hardware. However, I think that we can find a more interesting answer by going back to the origins of cloud.

Most on-premise computing architectures have grown organically over decades, and include principles, patterns, components and capabilities from other eras. The code running on that mainframe at the heart of your estate may have been written before it was normal for systems to run across large numbers of machines in parallel. The processes to procure, configure and manage servers may have been created before we realized that dev and ops belong together as a shared set of accountabilities. The security measures that protect your assets may have been implemented before it was the standard to connect most of your systems to a global public network.

The systems underlying cloud platforms grew organically too. Despite the reputation of companies such as Google, Amazon and Microsoft for innovation, they cannot predict the future perfectly, and have had to adapt to changing circumstances as they have grown. The difference is that, at least for the cloud platforms created by digital native businesses, they did not start in the same place as most enterprises, and the nature of their growth has determined the nature of their platforms.

Another way of describing cloud (other than as somebody else’s computer) is as technology platforms which have been built to support the needs of fast growing, global scale, digital businesses, and which have now been made available for other paying customers.

Let’s consider some key characteristics of such businesses and what they mean for cloud.

Centrality of the Internet

Although the Internet has existed for decades, and has been a mass phenomenon throughout the entire 21st century, it still feels like exotic territory to many on-premise architectures. There is the internal network (safe, familiar, controlled) and the Internet (wild, chaotic, uncontrolled). Letting customers access services over the Internet has often been a slow and cautious process, involving high friction checks and barriers.

By contrast, the digital native businesses that have built cloud platforms have treated the Internet as a de facto part of their architecture from the outset: that’s where their customers are. Indeed, as these companies have grown, created their own networks and laid their own cables, they have become essential parts of the Internet in their own right. It’s no wonder that concepts such as Zero-Trust Networks arose from digital natives and the companies that have created cloud platforms: they’re a natural result of treating the Internet as part of your architecture.

For cloud customers, this creates opportunities (it’s easier to reach your customers on the Internet from your cloud hosted services) and challenges (migrated services born in the dark, protected environment of the corporate data centre are now, if you are not careful, exposed to the Internet by default).

Innovation with the Prospect of Scale

Google was not the first search engine. Amazon was not the first e-commerce platform. In order to compete in the early days of their growth, they had to be capable of launching new features quickly and testing them with customers. They also had to be ready for those features to flop - or for them to scale rapidly to the point where they were used globally by hundreds of millions or even billions of users.

This meant two things. First, they had to optimize for developers: to make it safe and easy to get code into production (in contrast to many on-premise architectures, which seem to be optimized to deter developers, and to make it as hard as possible to get code into production). Second, they had to build architectures that were inherently easy to scale up and down - to provide just enough capacity to prove a new feature, and to scale up to global proportions if successful (in contrast to many on-premise architectures, where capacity needs to be predicted far in advance, and errors are expensive).

For cloud customers, this creates the opportunity to give your developers a better experience, to amplify the impact of successful innovation and to minimise the cost of failed experiments. Now you just need the ideas and the engineers who can make them real.

Need for Reliability

For years, many traditional corporate technology teams dismissed cloud platforms as being run by ‘dot com’ companies (the term denotes the freshness of the opinion) who didn’t understand the stringent requirements of running services at scale, particularly in regulated environments such as financial services. What did it matter if people couldn’t buy books or search the Internet for a few minutes?

The answer of course, is that it matters a lot. Today, a disruption within Amazon or Google’s core business makes headlines fast: many people rely on these services. But, even from the beginning, the cost of disruption to these services was immediately apparent: these companies are businesses just like other companies, and impact on revenue from outages was immediately apparent. The longer term effect of any outage was apparent too: people don’t go back to Internet services that they can’t rely on.

This means that cloud platforms have been engineered to be reliable at Internet scale, sometimes as a result of new technology invented for this purpose. For cloud customers, this means that they can enjoy the benefits of this reliability - if they architect and engineer their applications to take advantage of it.

I believe that understanding the origins of cloud platforms helps us to understand the value they can offer, and the changes that are needed to realise this value. Cloud platforms came into existence because the companies that created them had to use technology to solve new and interesting problems. They are not unique: all companies have had to solve interesting problems particular to their context. The next challenge, of course, is getting your interesting busines solutions to these interesting cloud platforms. I’ll share some thoughts on cloud migration in my next article.

(Views in this article are my own.)