Before diving into the specific topic of IT workloads, it’s critical to define why these are worth talking about in the first place. After all, we don’t hear about them nearly as much as we hear about digitalisation or the cloud. And why is that? Because these days, almost everyone in the working world has touchpoints with digitalisation or digital transformation at some point. These initiatives aim to incorporate digital technologies into an organisation’s operations and thus generate improved efficiency (among various other benefits) throughout the organisation. In this article, we outline the role workloads play in a business’ journey to the cloud.
Table of contents
But isn’t cloud the key component of digital transformation?
The cloud is often seen as the platform enabling digital transformation or the component which can accelerate it. At the same time, it’s important not to become so caught up in the technology storing your data that we forget to think about what it is actually storing and the requirements here.
Before we dive into the details of what requirements your data might have, let’s lay out some definitions first.
What are IT workloads?
IT workloads (also known in the IT sphere as simply “workloads”) are essentially data, programmes or applications that exist to perform a certain task. It has recently become common for workload, program and application to operate as synonyms for one another. Data centres or clouds host workloads, and multiple workloads built together constitute a service.
Many businesses are currently motivated to move workloads into the cloud as part of their digital transformation efforts. Often driven by industry mandates, sustainability or factors such as cost and resources, the primary goal of this modernisation is to save money and improve efficiency.
Before jumping into a migration with both feet first, it’s important for organisations to realise two things:
1. Not all workloads are suitable for migration (yet)
Depending on the workload’s makeup and all of the other workloads and/or servers it links to (otherwise known as dependencies), migrating to the cloud might be more than a simple “lift-and-shift”. This is especially true for legacy applications. Furthermore, a lift and shift won’t save money, and will likely increase complexity — the opposite of cloud’s intended benefits. Rather, transformation and building applications and services in a new way should be prioritised when moving workloads to the cloud.
2. It’s essential to move suitable workloads to the cloud at the right time and in the right order
Migrating a workload without considering its dependencies and requirements can result in downtime, general poor performance and thus a poor user experience for an organisation’s end users.
Which workloads are suitable for the cloud?
This question has three distinct layers: The current infrastructure, dependencies and the role the workload plays in daily business operations
1. Current infrastructure
Before thinking about moving workloads to the cloud, understanding the current underlying infrastructure is key. For the purposes of the following example, let’s assume that the workload you’re interested in moving is an application.
Is the application you’re looking to move stored on physical architecture linked to a particular host or piece of hardware? Or does it run on an operating system installed inside a virtual machine? The former will be much more difficult to move than the latter, as physical servers are notoriously hard to migrate.
2. Dependencies
As highlighted above, it’s critical to understand what dependencies exist throughout the environment. The workload might run on a server of some kind, and that server might run on a storage volume. And that’s an example of just a few dependencies — many workloads have more, needing to connect to databases or authentication server(s) as well, for example
Many businesses are unaware of how their applications are built and are unable to identify dependencies until they migrate workloads. By the time they’ve encountered performance issues pointing to a critical dependency, it’s too late — their employees and/or end users will already be suffering the consequences in terms of poor performance when they try and access the application.
The best way to prevent this from happening is by creating a service catalogue. This is essentially a big list of an organisation’s services and applications that they use either internally and/or externally.
If a company isn’t in the position to perform this mapping themselves, a third-party provider can help. They will look at the whole infrastructure and either map it manually or do a larger-scale scan depending on what level of information is already at hand. They’ll then classify the applications and services and show the organisation how their IT environment is built.
3. How business-critical is the workload?
Sometimes businesses are under pressure and have to fast-track things. In these scenarios, it’s easy to overlook best practices like those described in the previous section. For that reason, it’s always a good idea to first migrate the workloads which don’t constitute the main pillars of your IT environment. Choosing secondary or non-production workloads and servers is therefore a good test of a cloud migration.
Which workloads aren’t suitable for the cloud?
In addition to the considerations outlined in the previous sections, the organisation will have some unique insights into their workloads which will help answer this question. These are:
- How sensitive is the workload?
- How critical is it?
- How old is it?
- What does the business want to do with this workload in the future?
Answering these questions is key to keeping end users happy and preventing unwanted downtime caused by shifting unsuitable workloads around.
A good rule of thumb is to “keep close” anything that’s sensitive and requires high performance. These workloads should be kept either in a company’s own data centre or on dedicated assets that they own but are running elsewhere (known as colocation). On the other hand, workloads that are less sensitive or a bit more generic are great candidates for a migration to the cloud. The same goes for anything around data exploitation — meaning artificial intelligence and machine learning are also good candidates for the cloud, as long as they don’t have any integral dependencies holding them back. Workloads that aren’t static and need to be able to burst or scale quickly on demand are also good examples of potential cloud workloads.
Proact’s experts are happy to assist you with your organisation’s data visibility and help you evaluate which workloads can help you move forward in your digitalisation journey. If you’d like our assistance on any of the points raised above, please contact us using the button below.
