Cloud Workloads, Simplified

Since its inception, cloud computing has come a long way, yet people still possess misgivings and misunderstandings about what it can do, particularly when it comes to workloads.

The Annals of The Cloud

The history of cloud computing, if only conceptually, stretches back further than you may imagine. The cloud genesis, so to speak, dates right back to the 1960s, when renowned computer scientist J.C.R. Licklider dreamed of an "intergalactic computer network." Licklider imagined a time when everyone on the planet would be interconnected and able to access programs and data from anywhere at any time. He may never have specifically called this grand plan "the cloud," but its similarities to what we now utilize daily are striking.

But while this idea has been "in the air" — if you'll excuse the bad pun — for 50 years or so, it's only recently that we've started to realize its potential, primarily because of the significant bandwidth now offered by the internet. The cloud is in many ways still a relative newcomer to our technology stacks.

When it first become a reality, the cloud's predominant focus was on using APIs to access elastic infrastructure (akin to IaaS). The cloud's capability and capacity have significantly advanced over the last decade, but many people's comprehension remains rooted in the past, and herein lies the cause of most people's misunderstandings.

Historically, people viewed workloads as simply being "data + a basic understanding of how it should be processed," which has been a tricky misinterpretation to shake off, especially with this definition extending to cloud workloads. In reality, modern workloads do so much more.

Workloads and the Cloud: 2.0

On the surface, workloads are easy to define. They're simply independent services, collections of self-contained tasks that need to be completed or code that needs to be executed. Workloads can be small or complete applications that are defined by two characteristics:

1. Their interfaces are consistent
2. They have situation-specific rules and priorities

Workloads are, in essence, well-planned services. However, the sheer breadth of what they incorporate is staggering and covers data as well as the configuration of applications, hardware configuration, supporting service(s) and networks.

Efficiently managing your cloud workloads comes down to the connections you build, as the cloud requires workloads to be handled in a highly abstracted manner. This abstraction should be a way of keeping technical details from impacting the end-user. By adding this level of abstraction to your cloud workloads, you should be creating a service which makes it easier to provide a well-defined function with a definitive purpose.

Clearly defined connections allow developers to cleanly link services. Moreover, by creating well-organized containers, you introduce a highly flexible environment which can support changing workloads.

So, when we talk about cloud workloads, we're really discussing the need for configuration of different components in a virtual environment. The well-informed cloud user understands how to configure the communication between each of these disparate elements effectively.

Cloud Workloads or Traditional Workloads?

While each and every one of the above components could theoretically run from the cloud, it doesn't always make business sense to migrate them. Certain Tier 1 business-critical applications, for instance, make more sense to remain on-premises, because these crucial applications should always be accessible and within your care.

With cloud adoption comes a new raft of learning hurdles which must be cleared. There's been a history of users just "dumping" applications and processes into the cloud, and while this may provide serviceable results, it's far from optimal. Not all of your workloads and applications need to be migrated to the cloud. The best strategy is approaching each instance, case by case, and asking yourself: what would the advantage really be of keeping this process on site? What would the impact be of migrating it to the cloud? And the cost? If the pros don't outweigh the cons, or the cost exceeds the potential returns, then in all likeliness the process can and should remain as is.

Digital transformation is all about becoming as fast, accurate and agile as possible. By orchestrating the (virtualized) moving parts of the cloud, you can truly harness its full potential.