When evaluating the cost of Cloud, now, more than ever it’s critical to have both a detailed understanding of your existing IT budget and to be certain costs won’t spiral out of control.  In Part 1 of my 3-part blog series I examine how to evaluate the economics of cloud. In Part 2, I outline how you can get a forensic understanding of cloud versus legacy costs, before finally in Part 3 looking at key ways to de-risk cloud projects.

The recent pandemic has underlined the risks and limitations of on premises workloads and by contrast the importance of cloud in mitigating those risks. Cloud creates a layer of value that is hard to beat. Arguably, the business case for cloud is now more compelling than ever.  But how do you put forward the case for migrating to the cloud against a backdrop of IT budgets being squeezed harder?
 

The Economics of Cloud

When evaluating cloud as an option and beginning to research cost models, one of the biggest issues is that many organisations don’t have an accurate picture of current on premises costs.

That’s why when considering cloud costs it’s critical to understand the full picture. For example, it’s important to have detailed costs attached to running your own datacentres, including the power and the staffing costs.  And don’t forget less obvious costs, such as the cost of risk.

Compared to on premises, cloud is much more agile, scalable and carries less risk. I speak to many different organisations and shifting risk is now a significant driving factor in moving to cloud. Especially for CAPEX-sensitive sectors such as charities. Typically they have a mix of hardware vendors and hardware lifecycles at play, as well as support staff churn. Public Cloud helps smooth this out.

Other customers simply don’t want to run their IT anymore; they prefer a small team of two or three staff to liaise with technology partners like us. In fact, one organisation I work with is in the process of selling its datacentre to a third party who will then provide it back to them as-a-service. Cloud is about the demarcation of roles, responsibility and risk as much as it’s about the technology.

And lastly, don’t forget the opportunity cost. This is difficult to measure but by not investing you could miss out on the continuous innovation that comes with Public Cloud. For example, the benefits of having your workload close to the latest analytics, AI and storage technologies and the capability to exploit them. You’ve got to be in it to win it, as they say!

Knowing Which Apps to Migrate

What is a cloud-ready app? Admittedly, it’s been a long time since I was asked this kind of softball question but there are still plenty of legacy applications out there, so it is still a valid question.

It might be simpler to ask, which apps aren’t cloud-ready? A good example would be a monolithic SQL based single server system often seen in hospitals or other environments with a large mix of vendors. This type of workload, being contained on a single virtual server must be made highly available with redundant hardware (hopefully) across separate datacentres, so the application can run in the other location during an outage.

It's also worth noting, if the application is an off-the-shelf third-party app, the choices are limited for modernising the application yourself. If, however, the application has been developed in-house then we have options to modernise the application by separating out storage, memory, runtime and other aspects into more independently managed cloud native services.

You could say a modern cloud-ready app is like a modern cloud-ready workforce: asynchronous, distributed and resilient.

Understanding Cloud’s Operating Model

`

Recently, I wrote a proposal for an Azure-based application environment for a manufacturer. As part of the proposal they requested a clearer understanding of the operating model as this was their first cloud project. They were savvy enough to know that if they just used Azure as another server room, they would be setting themselves up for problems further down the line.

I think it’s important to flag when working with a customer we don’t just hand over a ‘black box’. Instead we get the relevant stakeholders involved as soon as possible to ensure a smooth operating model is in place.

We also use the “Azure Landing Zone”. This ensures a framework for cloud adoption is woven into the design process of the Azure cloud foundation.

There are typically multiple design cycles as the application environments are built out. But for the initial foundation, we spend time working with the customers’ technical team to define governance including naming conventions, policies for security, resource deployment and zero-trust networking. This is invaluable for teams who have only previously worked in on premises environments.

It also provides customers with a permanent reference point for how they consume their cloud services. In turn, helping to drive consistency and avoiding the pitfalls of an individual team member going off on a tangent

Additionally, we help organisations understand how different team roles will map to strategic cloud roles.  Below is a neat illustration from Microsoft’s cloud operating model of how roles translate to a cloud-based environment.

Figure 1 - Roles Translation for Public Cloud.
Source: Microsoft

In Part 2 of my 3-part blog, I will outline the key steps to understanding your cloud and legacy costs in forensic detail.  In the meantime, if you would like to find out more about evaluating cloud costs, or more information on how to start your journey in Public Cloud, please get in touch.

Andrew Shawcross

Cloud Solutions Architect