In part one we explored some of the reasons that Cloud reversal/repatriation is a 'thing' in 2024 and how we need to evolve our thinking around Cloud-first strategies to avoid repeating the mistakes of the past. In part 2 we are going to explore the CDW Right Workload | Right Platform mantra, and how it can help ensure you adopt Cloud when it is right and relevant to your organisation.    

In part three we will then dive into how to adopt this mantra and make decisions aligned to business outcomes.  

Contents

Cloud when right and relevant 

Cloud-first, what does it mean to you in your organisation? To me, it should be defined as the Cloud being the primary consideration when the business value is aligned, with other locations considered when the Cloud does not deliver the correct value. The problem is that we see too many people implementing it as Cloud-only, with every workload forced into a Cloud provider without due consideration. We are seeing a change in mindset slowly, but this needs to accelerate to avoid more repatriation conversations in years to come. I am happy to keep Cloud-first, but Cloud when right and relevant could be a more accurate term to adopt.   

This is why we developed our Right Workload | Right Platform approach to ensure Cloud-first strategies have a defined workflow for workload placement, that is, combined and aligned to value outcomes.  

Right Workload | Right Platform 

The first part of our Right Workload | Right Platform approach to the Cloud is to define the different execution environments for the various workloads you need to run. An execution environment is just a place where compute, storage and networking reside. 

We start with the Edge, Core, and Cloud approach, but believe there is a need for more definition. We divided this into sub-categories: 

Not every organisation will need all six of the defined execution environments. I would expect many organisations to adopt both Edge use cases and then one from each of Core and Cloud depending on requirements.   

Defining these high-level requirements and architecture can help drive a responsible Cloud adoption framework. Even if you don’t deploy all of them on day one, understanding what the ‘art of the possible’ is should be a focus. We can then assess each workload against the value each execution environment brings and make informed decisions. We will cover more on how to make those decisions in part 3 of this series. 

The final part of this concept is Cloud as an operating model. This is a term that can be traced back over a decade now in most cases to Mark Russinovich, Microsoft's Azure CTO.  

While the original definition has morphed and changed over the last decade, the core concept remains. We must view the Cloud as a model of operation that should transform how we deliver IT services to underpin organisational outcomes. The modern adaptation is that these new operating paradigms are no longer only available in the public Cloud.  

Cloud - how should we define it? 

One of the key things I think needs to be clear in the leadership teams for every customer is the definition of the word 'Cloud'. We are seeing everyone put some word in front of ‘Cloud’ (Meta, Super, Adaptive, Multi, Hybrid etc) to try and drive an agenda or product outcome.  

A decade ago, the word ‘Cloud’ was linked 100% to the public providers that pioneered the change in operating models. These automated platforms allowed organisations to operate in new ways; unlocking developers and removing blockers that traditional siloed IT functions could not deliver. The world has moved on in 2024, and the technology now exists to deliver these operating models in multiple different locations, providing choice and commercial flexibility.  

While not exhaustive, the following nine tenants could define what is needed to deliver a Cloud operating model.  

If you can define your list of functional/non-functional requirements, you can start to assess the needs of applications, data and developers against capabilities.    

Target Operating Model 

The goal is to move to a new target operating model where Cloud principles are adopted and delivered across all execution environments. Wrapping Orchestration and Automation around everything, and linking this up into your ITSM tooling removes IT from the provisioning and lifecycle process. Additionally, there is a focus on holistic security and end-to-end observability.   

This final point is key; moving from Monitoring to Observability is going to be critical to managing SLA and Mean Time to Resolutions (MTTR) in the complex landscape of modern hybrid Cloud environments.  

Building and managing a successful Cloud environment requires a range of core capabilities to ensure reliability, scalability, security, and efficiency. Without wrapping the right process and governance around it there is a big risk we end up back in Cloud reversal land. Modern Cloud management platforms (CMP) can now provide the overarching orchestration to deliver a unified Cloud experience across multiple execution environments, allowing for a single operating model underpinned by multiple architectures and commercial models. 

Tiered approach    

One possible way of looking at all of this is a three-tiered approach. 

The foundation tier is the static workloads that need to run 24x7 and don’t need access to any Cloud-native features. The middle tier is that burstable capacity to meet new requirements that might not be long-term projects. The top tier is the public Cloud provider offering seasonal burst and native PaaS features to innovate with.  

All three tiers can be OpEx (if required), and all three can be developer-ready and operating under Cloud principles. Workloads can easily move between tiers (foundation and middle being easiest) allowing for ongoing cost optimisation. That Foundation tier will provide the lowest cost-per-resource over a 3–5-year term, with the top tier offering the most value and innovation. The middle tier enables that burst capacity to cover short-term needs to the time delay in adding capacity to the foundation tier.   

Consider how the analogy of when you stay in a hotel, rent an apartment or look at buying a house.  

The cost per night is higher in the hotel but the features and services are included and easy to access and consume. This is great for short stays or meeting immediate requirements in new locations, like a conference or short-term holiday. If you are going for a longer trip in a single location, renting an apartment is likely to be more cost-effective, but you sacrifice some of those on-demand features for that cost optimisation. For long-term habitation though, many look to buy a house and balance the total cost over 20+ years. 

Summary 

We need to make sure everyone involved in the future of an organisation’s platforms is aligned with a single vision of the Cloud and how adoption will drive business value. In Part 1 we covered why reversal has become a conversation, and in this part, what a modern Cloud approach looks like and the art of the possible in technology. In Part 3 we will look at how to approach adoption, so it aligns with your organisation’s outcomes.