In-Depth
6 Workloads to Consider When Migrating to the Cloud
If you've been tasked with embracing the cloud, how exactly do you get there? Here's a rundown of the basic workloads to consider.
Contrary to a lot of the marketing you might encounter, migrating your workloads to the cloud isn't easy. Workloads can migrate to the cloud in a number of different ways, and each has their own challenges. So if you've been tasked with embracing the cloud, how exactly do you get there?
To start with, it's worth understanding the six basic types of cloud workloads.
IaaS
When IT operations teams think of cloud computing they're most likely thinking of Infrastructure as a Service (IaaS). IaaS allows IT teams to rent resources from a cloud provider that provide only basic functionality, requiring configuration and oversight from operations teams.
IaaS would include the provisioning of a virtual machine (VM) or allowing for the ability to spawn containers. These workload environments are presented in a relatively raw state. A VM may have an Operating System Environment (OSE) installed, and a container will be instantiated on top of a managed underlying OSE, but it's up to operations teams to configure these execution environments.
Once an IaaS environment is configured, operations teams then have to inject applications, configure those applications, as well as configure networking to allow access to the newly created workload. Multiple workloads can be combined to form a service, in which case networking access to the service from the outside likely will only engage a single execution environment's application (such as a load balancer), which will then provide access to other workloads that make up the service.
IaaS solutions might also include provisioning common workloads with a standardized configuration without requiring operations teams to configure the underlying execution environment. These workloads are usually elements of a larger service, such as a database.
Database as a Service (DBaaS) and similar offerings tend to get counted as IaaS, despite not requiring operations teams to configure the underlying execution environment in large part because they aren't of much use to end users on their own. They're considered to be a part of the invisible underlying infrastructure that users don't want to know even exists, and as a result are usually considered to fall into the IaaS definition. As with all technology definitions, however, IaaS is somewhat arbitrary, and the lines blur over time.
PaaS
Platform as a Service (PaaS) can be thought of as "IaaS for developers." The purpose of IaaS is to provide pre-canned stacks of workloads that are typically used together in a service. The traditional example is the LAMP stack: Linux, Apache, MariaDB and PHP. (Before MariaDB, it would've been MySQL.)
Today, there are a number of common platforms that provide a multitude of managed execution environments for developers of virtually any language. The goal of PaaS is not merely to make instantiating an environment to develop or run an application easier. PaaS also serves to provide a predictable standard set of execution environments.
Developers who develop an application on a PaaS platform can spawn an identical version of that platform for production uses. PaaS platforms are typically also fully managed by the cloud provider; execution environments are regularly updated, and they come configured as secure by default.
PaaS environments differ from IaaS in that PaaS is used almost exclusively to make cloud-native applications. Cloud-native applications separate data storage and configuration from the application, application configuration and the underlying application execution environment.
A properly built cloud-native application or service is fully composable, meaning that the entire PaaS platform on which it runs can at any time be torn down and instantiated without impacting the data upon which the application or service operates. This is frequently used as a first-line approach to any detected problems: If an issue is detected, the application environments are destroyed, new environments are stood up, known clean application code and configurations are injected, and then the data is reattached.
SaaS
Software as a Service (SaaS) is software offered ready for consumption by end users. No IT people need be involved. Enter your credit card information and start using the solution. In the case of SaaS, only application-level configuration (and usually a limited subset of that) is made visible to the end user.
The underlying execution environment, application and configurations are managed by the SaaS provider. They're responsible for security, updates and other basic tasks.
Hybrid and Multi-Cloud Services
Hybrid services consist of multiple workloads, where some workloads are operating on separate infrastructure from one another. The canonical example of a hybrid service would be a service where some workloads are on-premises and others are located on a major public cloud provider. Individual, none of the workloads accomplish a complete task. Together, they form a single solution.
A multi-cloud service can be either a hybrid service (where data is processed on multiple infrastructures at the same time) or a solution in which data is processed on multiple clouds in sequence. What separates multi-cloud services from hybrid services is somewhat nebulous, but the definition usually involves the amount of data being accessed.
A hybrid service might be something like a data protection solution involving a cloud storage gateway. Data is sent to a local device on-premises (the cloud storage gateway), which then compresses and deduplicates that data, as well as acts as a buffer. The cloud storage gateway then unspools the compressed and deduplicated data to the cloud provider, allowing for backups that occur at a single point in time (say, every night) to take all day to be sent to the cloud.
A multi-cloud solution typically has to make vast quantities of data available across multiple infrastructures. The term is typically invoked when it's deemed economically or temporally infeasible to send the data from one cloud to the next, even if processing the data sequentially is an acceptable approach.
Multi-cloud services are focused on providing a centralized storage solution to multiple cloud infrastructures. This may be accomplished by keeping data storage in a third-party datacenter that has high-throughput, low-latency connectivity to all of the clouds on which the production workloads in the service will operate.
Serverless
Serverless is less a workload or service type than it is a glue which holds workloads together. Serverless can be thought of as somewhere between a batch script and a TSR.
Serverless apps are essentially scripts that IT practitioners write, which monitor some type of input, take data from that input when it arrives, pass that data through one or more proper workloads, and then direct the output to a destination. In and of themselves, serverless apps don't generally process data. They merely act as a sort of programmable conveyer belt, shuttling the data from one location to the next.
Now that you know how workloads can be used in the cloud, let's look at what migrating to the cloud might entail.
Replacing Workloads with the Cloud
Arguably the method of cloud migration with the most long-term success is replacing on-premises workloads with an equivalent cloud-provided version. In almost all cases, this means replacing an on-premises solution that has to be managed by on-premises IT teams with a SaaS solution that requires little to no management.
Among the most popular targets for this sort of migration are financials applications and human resources applications. In the small business world, Quickbooks Online has gained a cult following while Saleforce.com has charmed larger organizations and, as a result, has become one of the most powerful technology companies in the world.
Not all applications can be migrated in this fashion. For such a migration to even be possible, a viable cloud-based application must exist in the first place. This isn't always the case, especially when talking about industry-specific applications.
Migrating to a SaaS application is as complex as migrating from one on-premises application to another. In the case of financials applications, getting the data conversion right can take months, or even years. Regulatory compliance issues, logging, monitoring and data protection all need to be considered, as well.
SaaS applications may be presented as an easy-to-consume service, but this doesn't mean that they solve all problems. Care and attention must be taken -- especially during the migration phase -- to ensure that the new SaaS-based offering will have all the same security, privacy and data sovereignty protections as the on-premises solution did.
Evolving Workloads into the Cloud
In some cases workloads and services can be "evolved" into the cloud." Microsoft Active Directory and Exchange, for example, can operate in hybrid mode. In the case of these applications, the SaaS offering and the on-premises offering work in lock-step, and allow the migration of users and data to the public cloud over a longer period of time. The goal in this case is to allow compatibility with older applications that are only capable of operating in concert with on-premises infrastructure while moving what can be moved up to Microsoft's Azure cloud.
Not all hybrid solutions are so blatantly unidirectional. Composable workloads, for example, will generally work anywhere. This can allow for the nearly mythical "hybrid cloud bursting," where public cloud instances of a workload are created when on-premises capacity is exceeded.
Hybrid approaches rooted in composability rather than as a vendor-designed migration path have the advantage of being able to move workloads back and forth at will. This has notable benefits when it comes to cost control.
Organizations deploying compsability based hybrid solutions tend to think less about migrating to the public cloud as some sort of end goal and more about using the public cloud as an extension of their on-premises infrastructure. Infrastructure automation solutions like Terraform, as well as configuration management solutions such as Puppet, Chef, Ansible or Saltstack are usually part of such an exercise.
Failover to the Cloud
Data protection solutions can also be part of a cloud migration exercise. For data protection to work in most scenarios a basic level of workload composability is required. At a bare minimum, networking needs to be made composable for most disaster recovery (DR) solutions to work.
Because data protection solutions take care of moving both workloads and data from one infrastructure to another, they're a great way to initially seed a cloud solution to which you intend to migrate workloads. DR failovers are for all intents and purposes a migration of an IaaS (or sometimes PaaS) workload, meaning there's no reason they can't be used as something of an easy button.
While the failover approach has a lot to offer, there are also drawbacks. IaaS, if done improperly, can be expensive. Similarly, IT infrastructures aren't simply workloads. There's often orchestration and automation that glues workloads together. Data protection is often part of this -- and it should again be emphasized that workloads always need data protection, even when they're in the cloud -- but most organizations also have a middleware layer that shuffles data between workloads.
This middleware layer sometimes integrates with on-premises hardware such as printers, point-of-sales terminals or Internet of Things (IoT) devices. In some cases, the middleware may be responsible for taking data out of one workload and presenting it to a system not owned by the organization, but which lives on-premises. The canonical example here is a computer-provided courier service that must physically live in the shipping department.
DR solutions may be able to ignore some of these things because they're designed to operate in a disaster. You don't care much about the courier computer in the shipping department if the shipping department burned down, or is under water. When failing over production workloads using DR tools with the idea of using the destination infrastructure permanently, all of the little intra-workload "glue" really matters.
Over time, as technical debt is resolved, it won't be necessary to move entire workloads. Once everything's composable only the data storage and configuration needs to go anywhere. Of course, once your workloads are fully composable, you're not likely to be thinking about workload migration as a single process or a specific event, either. At that point you'd simply run your workloads wherever makes the most sense at the time.
Like everything else in IT, how your organization might migrate to the cloud depends on a number of circumstances. Few organizations will have a single migration path for all workloads, and many organizations will continue having on-premises IT for years to come. Regardless of whether you see a migration to the cloud as a one-time event, or as a broadening of your infrastructure options, understanding what those options are is always important.
That, and backing up your data -- no matter where the production copy happens to live.