How to sell your cloud journey (and get it right once you’ve sold it)

Public cloud services have been around for just over a decade now, and many organizations are well into their own cloud journeys. Some industries, like Financial Services, are slightly slower to adopt public cloud, whereas for media, retail, startups and others, there is no “on-premises infrastructure”, and cloud is all there is.

In some industries, there are regulations and other external factors that act as barriers to cloud, but often, most of the barriers and resistance to change is caused by internal factors. A good way to overcome this internal resistance is to be clear about why you are embarking on your cloud journey. Knowing the “why” of your cloud journey will also make sure you get some of the core decisions in “how” you execute your cloud journey right.

In this article, I’ll touch upon the three main objectives I used in evangelizing for my organization’s cloud journey, their implications and some advice on how to achieve them.

1. Achieving faster development cycles

The core tenet of the Cloud is that infrastructure is code. Gone are the days of installing and tinkering with hardware, pulling cables and running around with CD-ROM drives. This not only means that provisioning of virtual hardware can be sped up, but that provisioning of entire applications, including their environments, can be fully automated. When you’ve done it once, it is as easy to set up and tear down an entire environment as it is to deploy a single software package. Deploying a 1000-node cluster takes the same effort as deploying a 3-node cluster.

The implication of infrastructure-as-code is that you cannot bring your old processes into the new world. I call this developing cloud-native processes. You need to fundamentally rethink how you provision and change infrastructure. Manual work is your enemy, as it is slow, error prone and scales poorly. Automation is your friend.

The key value herein lies in the vast improvement you can achieve in the pace of your development cycles and feedback loops. When you have the right development pipeline in place, you can bring ideas into production in days instead of months, gather feedback from your customers, and iterate to improve the service much faster than you would otherwise be able to.

In a world where your customer prefers to interact with you through digital channels and services, and the company that best serves the customer wins – the company that can realize ideas most quickly wins.

2. Leveraging the cloud to innovate

In addition to pouring enormous amounts of money into building datacenters all over the world, the large cloud suppliers employ thousands of software engineers in R&D, with the mission to develop the services available on the cloud platform. Few of these engineers with the virtual machine service. Yet surprisingly many think that the cloud is all about virtual machines, or “someone else’s PC”.

In fact, the virtual machine is only one of 100+ services in each major cloud supplier’s offering. A lot of development is happening in platform services, serverless computing, big data and artificial intelligence. It is in these platform services that the big differentiation exists between the cloud suppliers. A Linux Virtual Machine is virtually identical on Amazon AWS and Microsoft Azure, but the AI and cognitive services are quite different.

The main benefit of using these “higher value services” at the forefront of technology development is that they require virtually no investment on your part, and allows you to use technology that was literally developed last week, not five years ago. Achieving the same outcome using licensed software would often require a much larger investment – and time commitment – in purchasing licenses and installing software that will be outdated by the time you start using it.

However, using these “higher value” services has the key implication of accepting that you adapt to services that are to a certain extent unique to your cloud supplier. You pay the price of some level of lock-in with your service provider, to achieve access to this cutting edge technology. The more you use platform services instead of just infrastructure, the more invested you are in that cloud provider’s service offerings.

There is also a maintenance aspect of platform services: Although platform services will typically require much less maintenance than infrastructure services, they are less standardized and develop at a higher pace than infrastructure services. As a result, if you chose to take advantage of them, you need to have commitment from your development teams to adapt to changes over time in how these platform services work.

3. Saving money

Many organizations embark on a cloud journey to deliver on a commitment to save 30% of infrastructure cost. It may surprise some that there is no universal rule that says that cloud is always cheaper than on-premises infrastructure.

If you decide to embark on a cloud journey to save cost, you need to get an idea of where and how this cost saving will materialize. Pricing models are vastly different between cloud providers and incumbent infrastructure providers. The simple monthly price you pay for a server can translate to a mix of charges in the cloud world, for CPU time, disk accesses, network egress charges and so on.

When all costs add up, it is unlikely that a similarly specified server in the cloud will be much cheaper than what you get if you are a reasonably good negotiator with a well reputed “on-premises” infrastructure service provider.

Instead, you need to leverage the capabilities of the cloud to save cost. Using the sizing and scaling options in the cloud to “right-size” your infrastructure. Using automation to tear down and build up development and test environments as they are needed. Leveraging storage tiers to save cost for cold storage. Et cetera, et cetera. If you just lift and shift your existing infrastructure to cloud, you may find that your cost savings turn out rather disappointing in the end.

But if you dare to make the cloud step a little bigger, dare to rethink how your organization delivers software, dare to embrace the innovative platform services instead of sticking with infrastructure – you can find that the value that the cloud delivers goes beyond savings in infrastructure cost. That is wherein the real value of the cloud lies – in improved developer productivity, shorter cycle times and access to innovation. Use those advantages to bring unique offerings to market faster than your competitors, because they will take you far beyond what you can achieve by optimizing infrastructure cost.

Some recommendations to getting it right

“So, after all this lecturing, how do I get it right?”

Many organizations embark on a cloud journey with no better reason that “everyone else is doing it”. I would encourage everyone starting their cloud journey to spend a bit of time thinking of the why. What is the goal you are trying to accomplish? Start there and be explicit about it when you decide your guiding principles for your own cloud journey.

Regardless of what is your “why”, I have found that there are a few universal recommendations I can give that apply to most organization’s cloud journeys:

1. Don’t start by going private cloud first or limiting your use of cloud to sandboxes, development and/or test environments – set the goal to take your journey all the way to production, in the public cloud, in your first step. Why? Because you will learn little from playing around in a sandbox or private cloud that you will find useful when running production services in the public cloud. Instead, chose services that you consider “low risk” and start with them. If the service has a problem, it is not the end of the world, and you get the opportunity to learn and improve in a way that is meaningful when you move to more complex applications.

2. Don’t rely on a vendor / partner to do it for you – Although it may be tempting to ask someone to take care of your journey as it is hard, you need to realize that there really is no way around the need to take charge of the journey and build competence internally in your organization. The cloud is a different paradigm than on-premises infrastructure, and you need to experience it to understand what it means for your organizational development.

3. Don’t think that cloud is an infrastructure thing – it is not. As I’ve written above, it is an organizational change journey. It is a time to rethink how your organization develops software. If you haven’t already embraced agile and DevOps, now is the time to do so, since agile and DevOps benefit greatly from the automation opportunities provided by cloud. Without changes in how you work, you will find little value from the cloud.

4. Start small, iterate and learn – don’t start with a huge business case analysis, ending up in analysis paralysis – or plan for the perfect cloud architecture without ever starting. By the time you have it figured out, the market will have changed, and your plans will be outdated. Realize that in any paradigm shift, you can’t truly understand the economics of the new, or design the perfect operating model until you’ve tried, failed, learned and improved through a number of iterations.

Hope you found this useful and don’t hesitate to leave a comment or question below.

Good luck!