What Type of Workloads Should You Consider When Migrating to the Cloud?

It should come as no surprise that enterprise workloads are increasingly moving to the cloud. According to a recent survey, 83% of them are anticipated to run on cloud platforms in 2020. By Amy Hawthorne, VP, Global Marketing, iland.

  • Monday, 18th March 2019 Posted 5 years ago in by Phil Alsop

Businesses might not expect the move to be especially challenging – after all, simplicity is a key cloud benefit. However, it takes careful consideration to make sure that your security is on point, your budget is optimised and your responsibilities are clearly defined during a cloud migration. Don’t forget to take all of your workloads into account, as well. In a report sponsored by iland, Trevor Pott has compiled a list of the workloads you should consider when migrating to the cloud. Here is an executive summary of the report, hopefully you find this helpful as you:

 

Infrastructure-as-a-Service (IaaS)

IaaS, alongside Software-as-a-Service (SaaS) and Platform-as-a-Service (PaaS), is one of the main categories of cloud computing services. In an IaaS model, your Cloud Service Provider (CSP) provides you with a virtual machine, with processing power, memory and permanent storage.

Containers can be spawned but the workload environments are pretty basic, this means that operations teams get to manage the configuration of these execution environments. Once they’ve done so, applications can then be injected and configured. At this stage, networking also needs to be configured to make the new workload accessible. You’re probably wondering how to do this when you have multiple workloads and the answer is quite straightforward: you can combine all of them in a service so when accessing it from the outside, this will only engage a single execution environment’s application which will then provide access to other workloads that make up the service.

Provisioning common workloads with a standardised configuration can also be included in IaaS solutions without needing your operations teams to configure the underlying execution environment. Keep in mind that, most of the time, this type of workload is part of a larger service, such as a database.

 

Platform-as-a-Service (PaaS)

Let’s move on to the second workload to consider, the PaaS, which is often seen as ‘IaaS for developers’. Its purpose lies in its ability to provide pre-canned stacks of workloads that are typically used together in a service.

There are a wealth of common platforms providing managed execution environments for developers of virtually any language. The purpose of PaaS is to make instantiating an environment to develop or run an application easier. It’s also a good way to get a predictable standard set of the execution environment.

When developing an app on a PaaS platform, developers can duplicate a version of it to use in production. The platform itself is more likely to be entirely managed by your cloud provider, so you don’t have to worry about security or updating your execution environments.

While PaaS might seem similar to IaaS environments, they are actually slightly different in that PaaS is mostly used to make cloud-native applications. Data storage and configuration are separate from the cloud-native applications, their configuration and execution environment. On top of that, because cloud-native applications and services are fully composable, the PaaS platform can be torn down and instantiated without having any impact on your data.

This means that, when you detect an issue, the application environments are destroyed and new ones are created. Clean code and configurations can then be injected, and your data reattached.

 

Software-as-a-Service (SaaS)

Next in the list is SaaS, which is software ready for consumption by end users. It couldn’t be easier to use: all you have to do is enter your credit card information, then you can start using the solution.

With this type of service, the end user can only see application-level configuration, and usually a limited subset of that. The underlying execution environment, application and configurations are managed by the SaaS provider. They’re responsible for security, updates and other basic tasks.

On a last note, it is worth mentioning that by opting for a SaaS solution you can replace your on-premises workloads by replicating them in the cloud, and therefore lighten your IT team’s work.

 

Hybrid and multi-cloud services

When it comes to hybrid services, multiple workloads run on different infrastructures – they can be on-premises, in a private cloud, or in a public cloud. Combining these workloads forms the whole solution. In short, a multi-cloud service is either a hybrid service requiring multiple infrastructures or a solution requiring multiple clouds.

Still can’t see the difference between hybrid and multi-cloud services? Ok, let’s put it this way: it’s only a matter of the amount of data being accessed.

A multi-cloud solution implies that a consistent quantity of data should be available across multiple infrastructures, while a hybrid service can be any solution involving a cloud storage gateway that then unspools both compressed and deduplicated data to the cloud provider. The latter allows for backups that occur at a set point in time to take all day to be sent to the cloud.

To clarify, multi-cloud services aim to provide a centralised storage solution to multiple cloud infrastructures. This involves keeping data storage in a third-party data centre that has high-throughput, low-latency connectivity to all of the clouds necessary for the production workloads in the service to operate.

 

Serverless

Serverless is not really a workload or “service as such,” but more of a tool holding workloads together - it can be thought of as somewhere between a batch script and a TSR.

As Trevor Pott explains in the eBook, serverless apps are essentially scripts that IT practitioners write, which monitor some types of input, take data from that input when it arrives, pass this data through one or more proper workloads, and then direct the output to a destination. Note that, intrinsically, serverless apps don’t process data.

 

Conclusion

Any organisation moving to the cloud aims to maximise migration benefits, reduce costs and minimise risk. While I would strongly advise that you carefully pick the right cloud provider to meet your requirements and support you with your migration, defining a formal project plan and tracking every activity, is just as important. As you can imagine, a successful migration is one that meets the goals you set. This is why you should pre-define a Statement of Objectives (SOO) which will help you to verify the efficiency of your services in their new environments.

Hopefully, this article will help you to keep in mind the workloads you need to take care of and thereby make the transition as smooth as possible. But, if it still seems unclear to you, you can always ask our team for some help.