What Is a Workload?
At its core, a workload is an independent service or collection of code that can be executed. Some industry experts include the application, operating system, and middleware in their definition of a workload. Because a workload is executed across computer assets, another way to look at it is the amount of work that needs to be accomplished by computer resources in a certain period of time.
Of course, different workloads have different characteristics, and the best platform for a particular workload to run on depends on the nature of the specific workload.
All workloads aren’t the same
Batch workloads: These workloads are designed to operate in the background. Typical batch workloads tend to process huge volumes of data. These workloads may include the data produced from a set of cellphone bills or the results of months of online transactions. These workloads require considerable compute and storage resources. Batch workloads are rarely time sensitive and can be scheduled when few real-time tasks are running. Because this data is well documented and predictable, automating this type of workload is relatively easy. Generally, batch workloads are executed on a regular schedule and can take advantage of the economies of scale of public cloud services as a way to process these workloads. Again, as in any cloud environment, the decision of where to execute batch workloads is determined by business rules, governance, and security regulations.
Transactional workloads: These are the automation of business processes such as billing and order processing. Traditionally, transactional workloads were restricted to a single system. However, with the increasing use of electronic commerce that reaches across partners and suppliers, transactional workloads must be managed across various partners’ computing environments. So, there’s a need to focus on business processes with these transactional workloads. These workloads are both compute- and storage-intensive. Depending on the cost-benefit analysis, it’s likely that complex transactional workloads are best suited to a private cloud.
Analytic workloads: Organizations may want to use analytic services in a cloud environment to make sense of the vast amounts of data across a complex hybrid environment. This requirement isn’t simply a technical one; it’s necessary for business partners to benchmark the success of their partnerships and to make adjustments to increase success. In an analytics workload, an emphasis is placed on the ability to holistically analyze the data embedded in these workloads across public websites, private clouds, and the data warehouse. These types of analytic workloads tend to require much more real-time computing capability.
High performance workloads: These have a specialized process with scientific or technical requirements. These workloads are complex and typically require significant compute capabilities. Thus, they’re well suited for specialized public clouds optimized for performance.
Database workloads: These are the most common type of workload, and they affect almost every environment in the data center and the cloud. A database workload must be tuned and managed to support the service that’s using that data. A database workload tends to use a lot of I/O (Input/Out) cycles. In some situations, data workloads are small and self-contained; however, in other situations, the data workloads are huge, and the performance requires a sophisticated approach. For example, high-performance database workloads may be implemented on bare metal (directly on the hardware’s operating system) to support the business requirement.
Table 12-1 Workloads in the Cloud
Workload Type |
Focus |
Is It Time Sensitive? |
Batch workload |
Processes large volumes of data in the background |
Not time sensitive |
Transactional workload |
Focuses on large volume of current transactions |
Typically requires real time |
Analytic workload |
Affects large amounts of data for decision making |
Depending on the business, could be either batch or real time |
High-performance workload |
Has scientific or technical focus |
Requires huge amounts of compute resources |
Database workload |
Is highly tuned to application needs |
May require specialized hardware integration |
Workloads not suited for the cloud
Just as some workloads are suited for the cloud, some are not. A few examples of workloads that you don’t want to move to the cloud include:
Workloads that need high-performance network storage. Because these workloads may need to be accessed very quickly, they may not be suited for the cloud where you’re dependent on the Internet for network speed.
Legacy application workloads that require very low latency. Often, legacy workloads weren’t architected to run in a distributed computing environment. They may serve a particular purpose, and it may not make sense to move them to the cloud.
Database clustering that requires very high throughput (speed) on the network. A large grouping of databases that requires millisecond response time may also not be suited for the cloud.
Abstraction and workloads
Workloads can be abstracted in cloud environments, meaning that the workload is isolated from the hardware it’s running on. In fact, in most situations, the average customer has no idea where the workload runs. Although an individual workload doesn’t depend on external elements, it’s typically combined with other workloads to execute a business process or task.
The notion of abstraction is critical for how workloads run in the cloud and it’s even more important in a hybrid cloud. The only way to create a distributed computing environment consisting of multiple services in multiple locations is to have well-architected, abstracted workloads.