Migrating Critical Workloads

Introduction

As part of our ongoing “Champions of Cloud” blog series, we have been looking at the key considerations for regulated organisations wanting to adopt Cloud in Malaysia. In this article, we’ll examine the area of migration, specifically the migration of critical workloads. But what is a critical workload and why would we want to target these for migration?

As per Bank Negara Malaysia’s (BNM) definition, a “critical system” refers to:

As discussed in a previous article, systems falling under this definition have specific steps that need to be undertaken in order to move them to cloud. However, thinking beyond the regulatory definition, a critical workload is one that supports the principal business activities of the organisation. Alternatively, due to reputational considerations the public facing website of the organisation can fall into this category too. Therefore, although many of these applications may be complex, there is significant opportunity and value in a successful cloud migration.

Why move critical apps to cloud?

Many of the standard justifications for a cloud migration are inapplicable or require significant contextualisation for critical workloads. For example, reducing infrastructure cost may be less significant against the overall cost to run, and standard deployment methodologies may not be suitable. However, there are areas where cloud can provide significant value as part of a critical workload migration.

One of these areas is resiliency. Critical workloads usually come with strict service-level agreements (SLA), requiring heavy investment to satisfy as well as deep operational maturity. By leveraging cloud, workloads benefit from the capabilities of the cloud provider in running multiple datacentres in region, as well as the ability to operate out of a different region in a business continuity scenario. Moreover, many of the fundamental managed databases, compute and content delivery services available in cloud can provide high-availability as standard. This allows the organisation to move from an “active/standby” model to an “active/active” model with the associated simplification of disaster recovery planning.

Another advantage of leveraging public cloud is the scalability this affords the organisation. Given many critical workloads are transactional in nature, it is expected that they will have highly variable usage patterns which may correspond to trading hours, salary cycles or retail activity. Meeting this demand is challenging in an on-premise environment were peak capacity must be catered for, but in the cloud capacity can be added on-demand. This helps organisations right-size their infrastructure as well as allowing for both planned and unexpected bursts of activity.

A third and perhaps under-appreciated aspect of running workloads in cloud is the level of observability that comes baked-in. Every infrastructure component in cloud generates detailed metrics as to its state and performance. By surfacing key metrics from the workload into the same observability plane, we can generate key insights into the performance and usage patterns of the workload and user behaviour.

Lastly, the opportunity to retire legacy platforms cannot be ignored. Many critical workloads are running on specialised hardware and software, which may have high runtime costs and scarce availability of expertise. Most vendors will have versions of their applications that can run on cloud VMs or containers, unlocking the ability to use commodity cloud services and support services.

Approaches

Given the complexity of many critical workloads, there are a range of approaches that could be used to achieve a cloud migration. A critical workload may be made up of several components and supporting systems, and additionally may exist in multiple environments such as development, SIT and production.

Conceptually simplest is the all-in approach, where the workload and supporting services is migrated as a unit. While this would unlock the maximum benefit, it’s also likely to be a significant investment in time and effort to mitigate any additional risk introduced with this approach. There are alternate approaches that can progressively deliver benefit with lower investment.

One alternative approach is to migrate based on environment. In this model, lower-order environments such as development and testing are migrated or rebuilt on cloud, while production remains on-premise. The organisation will get some benefit from cloud scale and utility pricing, and the ability to scale testing environments dynamically. This is also a good opportunity to gain expertise in cloud concepts and operations before committing to a more complex outcome. Focused effort on upskilling the production operations and BAU teams will be required as there is a risk they lag behind the other teams that are responsible for the lower order environments.

Another approach is to consider the ecosystem of systems surrounding the critical workload such as application programming interface (API) gateways, service buses, reporting systems and so forth. A migration plan can be constructed for this surrounding ecosystem, progressively delivering cloud adoption benefits and familiarity with cloud. This is also an opportunity to refactor or replace key components of the ecosystem. A final option that should be considered is vendor management. Many independent software vendors (ISV) will have a model whereby the workload can be operated on behalf of the organisation, either in a customer-owned or vendor-owned cloud environment. This can be an opportunity for the organisation to leverage the scale of the vendor and refocus on delivering value.

Key Considerations

While there are standardised methodologies for cloud migration that can and should be leveraged, there are some special considerations for critical workloads that need to be managed.

Given the high likelihood of critical workloads being used to process sensitive data, the need for a rigorous security and compliance framework cannot be understated. The organisation should have a robust set of controls in its cloud environment that reference both cloud best practices and the requirements of the regulator. As referenced previously, the requirements of the regulator to report or consult  must also be observed. Finally, the tech risk functions of the organisation should be equipped to govern final outcome.

Budgeting for the migration is also an important consideration. Based on the approach selected above, the cost for the given approach needs to be understood as well as the outcome. Organisations should also be aware of funding opportunities made available by the cloud providers, such as the AWS Migration Acceleration Program, which can unlock significant funding for partners to assist organisations with their cloud migrations.

Outside of the cost to migrate, the organisation should undertake detailed modelling of the cost to operate in cloud, taking into account any savings that may be possible due to leveraging managed services such as relational database service (RDS). This calculation is also an important input into securing cloud provider funding.

Lastly, the organisation should be clear on the functional outcome of its migration strategy, set expectations and track accordingly.

Getting Started

The best way to get started on a critical workload migration is an assessment by a suitably experienced partner. The assessment should take into account the strategic goals of the organisation, the lifecycle of the workload, canvass a range of approaches and articulate the benefits that accrue to each. As part of the assessment, a key outcome is an actionable roadmap for achieving the organisation’s goals.

As mentioned above, cloud partners can make available funding for the purpose of conducting these assessments, as they have a strong incentive to ensure that your migration programme is successful. Once the approaches and benefits are clearly understood, the organisation can start executing on the defined roadmap and plan. Depending on the approach selected above, this could well span 3-5 years, and deliver multiple smaller functional outcomes along the way.

Conclusion

Aaron Lauer

Aaron is a Senior Consultant with Sourced with over 15 years of experience in the IT industry, designing cloud architecture and migrating workloads across multiple public cloud providers. He specialises in providing learning and enablement programs to help our clients in their adoption of cloud technology.

Ian Donaldson