Moving to the Cloud is NOT about the Cloud

One of the questions that I get asked very regularly by customers, colleagues and friends is “Why do I need to move my … to the cloud?“. Almost every time this question comes up, the conversation very quickly gets into technical capabilities of the cloud, cost saving or the last service that this or that cloud vendor has released. These are all valid reasons, but that’s not what drives people, teams or organizations.

Take for example the decision to buy a new house. Surely, it can be driven by the fact that one is simply interested in getting a new shinny home. But very often, it is about providing, yourself or your family with more options. Whether it is upsizing or downsizing to adjust to a growing or shrinking number of people living under the same roof. Getting a backyard so your kids can practice their favorite sport. Or remodeling to fit new family needs. It’s rarely about the house itself, it’s about the value it adds to your family’s comfort.

Shortening Time to Value

One of the upmost aspirations of any business leader is how fast they can get “new” value in the hand of their customers. Imagine, you want to build a brand-new information technology capability, test it, deploy it, secure it and monitor it. In addition, you need to have your globally distributed teams work on it.

Traditionally this would require:

• An engineering system to host your development team activities: code, build and test.
• Test environments to allow validating the features in isolation and as an integrated product.
• Secure production environments that elastically scale to respond to growing or shrinking demand.
• Finally, most of this net new investment would be in a form of a capital expenditure (CAPEX).

Setting aside all the cost saving that results from using the economy of scale. Getting the prerequisite logistics ready in the cloud, for the example above, could take few minutes to provision. It could switch the investment model from CAPEX to an OPEX. And it could be scaled down or discarded in minutes in case of changing priorities.

For instance, let’s attempt an experiment on Microsoft Azure. I want to achieve the goals I have listed in this small use case in a matter of a minutes.

1 – I am going to start by creating a “DevOps project“. (don’t worry of you don’t know what DevOps is)

2 – It then asks me what kind of language/technology I want to use:

3 – It then asks me what basic architecture components I will need:

4 – Then I choose how I want to host it. I am choosing Kubernetes, so that if I want to take it anywhere else, I can with no code modifications:

5 – I then specify few information and choose the initial infrastructure size I want:

The end result is:

• A backlog to plan, manage and track work required for my investment.
• A git repository to host my source control securely.
• A build pipeline to build, validate and test my application.
• A release pipeline to continuously deploy new value and release it to my end users.
• A Kubernetes cluster to host my application in a secure and elastically scalable way.
• A private docker registry to host my application docker images.
• Last but not least, monitoring capabilities to allow me to track the application usage and learn about opportunities for improvements or expansions:

Accelerating innovation

You should be thinking that you can’t possibly compare a “hello world” sample to a production ready application. That’s absolutely correct. But I have already prepared everything I need to start building the real application.

If you already have your own code, clone the sample application locally, replace the sample code with yours, push it to the git repo and let the Pipeline do its work. This allows you to focus on the business goals you want to achieve rather than the infrastructure you possibly could need. The on demand, self service capabilities of the cloud accelerate your innovation velocity.

For instance, as I take my initial sample application from demo form to product ready, I might decide that the initial Kubernetes cluster size I chose is not enough, then all I have to do is choose my new size. Better I can scale up and down based on the demand from my new user base.

Enabling agility

One of the biggest advantages, in the use I have used so far, is the ability to shift technology strategy, pivot the application business goals or even fork it to different verticals. None of those are now dependent on initial technical choices:

• My application is portable to any cloud: public or private.
• My development technology is cross platform.
• My hosting model is elastically scalable.
• My code base is in a distributed source control system that can allow parallel development efforts.
• And all my investment aspirations are managed in a lean board:

What we have seen in this small example, is that the cloud itself is not the goal. The ability to achieve your business goals faster, in a cost-effective way or adjust your aspirations as needed are most likely going to be the answer to “Why do I need to move my … to the cloud”.