NHS Cloud exit strategy

When working with partner organisations there is always a risk that changes in either organisations priorities or business model may adversely impact the services they provide. Equally where an organisation is running services on behalf of the NHS disruptions to the services, they provide can impact the NHS. While the geographically dispersed nature of hyperscale cloud providers services reduces the risk associated with service disruption.

The risk of building on proprietary services is harder to mitigate and while there is clear value in utilising the “heavy lifting” a vendor is performing in providing a platform or component as a service. An amount of care is needed to ensure that any migration can be done in a structured way which minimises the risks to the solution and its customers.

This is not to state that cloud computing is an unreliable outsourcing option. On the contrary, many cloud computing services are often more reliable, than alternative hosting options or on-premises systems. A cloud computing provider's business model depends on its ability to provide secure, reliable IT services. These Cloud service providers build a robust infrastructure and pay particular attention to security and reliability.

We believe there are a small number of issues that would create a need to exit a vendor's platform entirely.

Examples include:

• a competitor's SaaS solution has grown beyond the capabilities of the one in use. In this case, an exit may be needed to acquire new features and capabilities needed to grow or keep the business competitive
• a cloud vendor decides to exit a market completely
• regulations introduced in one country might force the exit from cloud providers hosted in that country due to incompatibilities with such things as data privacy regulations
• political actions were taken by the UK or international government

There would be substantial and immediate challenges in an occurrence of any of the above. NHS and healthcare organisations must make risk management and mitigation an essential part of their cloud adoption plan. For NHS and healthcare organisations that are just starting their cloud adoption, a cloud exit plan must be clearly defined before the first application or data is hosted in the cloud. For organisations that are already consuming cloud services without an exit plan, remedying that oversight is essential.

Individual exit plans will be shaped by the cloud provider, cloud layer, alternative provider, type of application, amount of data, interdependencies, integration points, user base and much more. In most cases, the plan will vary based on whether the application will move to another cloud provider, hybrid hosting or back on-premise. Recommended areas to consider in the application exit plan is the following components, which are common to all exit-planning scenarios

• application movement plan
• data movement plan
• security and identity and access management (IAM) plan
• management plan
• personnel plan
• business continuity plan

The difficulty in moving an application from one public cloud provider to another provider depends on the cloud layer used to host the application. In short, the challenges in moving an application increase as we move from IaaS to PaaS to SaaS, because of the increasing reliance on proprietary features in the platform. The table below outlines the challenges for each scenario.

Application movement challenges

By different scenarios: 

Regardless of which scenario applies from the table above, extensive testing will be required after the application migration, and this must be included in any migration plan.

Moving any public cloud application back on-premise presents different challenges. In most cases, on-premise hosting capabilities fall short of the capabilities offered by the public cloud provider in terms of feature set. However, as time passes, an organisation may find that its on-premises services have matured to the point where it can now offer competitive application hosting to the public cloud provider. Here are some important aspects to keep in mind based on the cloud layer.

SaaS

The biggest challenge may be persuading the provider to support the application outside of its own SaaS offering, in which case, a new application will have to be selected. Assuming that moving the SaaS application in-house is an option, the organisation must assess its ability to host an entire stack (i.e., infrastructure, platform, and application). In many cases, SaaS solutions fulfil a niche need in the market and are something that is not a core skill set within the organisation. Organisations must consider the time, effort, and long-term desire to build an entire application stack and support it over the long run.

PaaS

Moving an application from public PaaS to in-house must focus on an assessment of the specific platform capabilities offered by the public provider. Key questions to ask in this scenario are

• does the organisation have the skills and experience to deploy the PaaS layer in-house?
• is a PaaS layer available that is API-compliant with the offering currently in use?
• how much of the application will have to be modified/rewritten to conform to the new PaaS layer?
• does the level of integration between development tools and application deployment infrastructure match development velocity requirements?

IaaS

The most straightforward internal exit is at the IaaS layer, but the same precautions apply as moving between two public IaaS providers (listed previously) in terms of hypervisors, features, provisioning models, and APIs. It's also important to consider such issues as data centre capacity, ability to meet availability requirements.

Although all public providers have good options for security and Identity Access Management (IAM), they vary widely in implementation. As a result, every provider is different, and there is little or no portability of IAM and security policy metadata between providers.

NHS and healthcare organisations considering moving an application from one provider to another should start by identifying each feature or control (for example security monitoring, intrusion detection, and firewalls) in use at the existing provider. The next step is to map those capabilities onto the new provider and plan how to create similar functionality. For example, if the primary cloud provider handles server-side encryption and key management as a service, but the alternate provider does not, the application team must build a key management capability and encryption service implementation at the new provider. Alternatively, the organisation can buy something comparable from a third party.

Because IAM is handled very differently among leading providers, it's important to consider all the administrative and user accounts, policies, and controls that must be migrated and define processes to

• export all existing IAM accounts, roles, delegated access, and policies assigned at the primary provider
• re-create a comparable structure at the alternate provider and
• define the process to force users to create new passwords

Many of these problems with IAM can be avoided by implementing identity brokers that centralise IAM access across multiple providers. Additionally, the use of federated directory services can greatly reduce the complexity of application integration middleware (AIM), especially across multiple providers.

Enterprise management is the core of IT operations and is critical to ensuring compliance with regulations. Unfortunately, large public cloud providers represent islands of management, largely relying on the cloud service provider's own tooling to monitor the infrastructure and applications, and with little or no ability to work with other cloud services. As a result, moving to an alternate cloud provider inevitably disrupts enterprise management processes built around the current provider. Processes like asset, change,  configuration, incident, problem and financial management are all sure to change, and the exit plan must take this into account.

In addition to changes to system management and monitoring, application teams must plan for changes to the processes that result from moving to a new provider. For example, the application team may rely on standard logging of all cloud events, such as create and terminate, at the primary cloud provider. Moving to a new provider without a similar logging service could mean the application team must establish its own audit logging system for these same cloud events.

In some cases, leveraging a third-party cloud management broker might facilitate or abstract underlying provider changes and allow organisations to change providers without as much disruption.

Systems are defined as a combination of people, processes, and technology, so it's unwise to move an application without thinking about the impact on the skills of your people within your organisation. A people plan must be structured to account for:

• administrators: Staff responsible for managing the application will have to become familiar with the management capabilities of the new platform
• support staff: Staff responsible for end-user support on the application must be familiar with the new platform and make changes to support documentation where necessary
• end-users: At the end of the day, end-user familiarity with the new application is critical to a successful migration. It doesn't matter if the new application works perfectly if the users can't work out how to use it

The Business Continuity Plan (BCP) typically encompasses such things as backup and recovery, as well as Disaster Recovery. It can impact the exit plan at two levels:

• aid to exit planning
• exit plan invalidates the business continuity plan

One of the key concepts in Disaster Recovery (DR) is the recovery time objective (RTO), which defines how long any failover to the DR site should take, with more critical applications having RTOs measured in seconds. The cost of meeting the RTO is inversely proportional to the length of the RTO, i.e., the smaller the RTO the higher the cost.

The concept of an RTO can be extended to exit planning, where it's critical to determine how quickly an application must be able to exit the current provider. For example, if the application owners are happy to wait for months while the exit plan is implemented, costs will be low. An application that must be prepared to exit in days will have a much higher cost.

In some cases, it may be possible to combine the DR implementation with that required for the exit plan. In effect, the same procedures are followed in both cases and the alternate site for the exit plan and the DR site is the same. This is particularly attractive in situations where the RTO and the "time to exit" are similar

• there's no need to run a DR site and a hot exit plan site, which significantly reduces cost
• the same procedures can be used for a DR failover and the exit plan
• testing of DR and exit plan operations can be carried out as a single exercise

The challenge is that typically, the DR implementation does not involve changing providers. That is, in a typical DR scenario, the primary and secondary sites would be in different data centres run by the same provider.

Setting up a remote DR site at an alternate provider requires addressing multiple challenges, such as:

• dross-provider data replication
• IAM across providers
• building the application in a way that can work across providers
• re-routing incoming connections when one provider fails

However, many of these problems will have to be solved as part of the exit plan, so the additional work is not as great as it appears at first glance. Building a DR configuration across providers is not something that makes sense for many applications, but in cases where RTO and engineer to order (ETO) are similar, the extra expense and complexity may be worth considering.

Changing providers will have a significant impact on standard BCP, such as backup and recovery, site-to-site replication, and disaster recovery. Key issues to address are

• impact on backup and recovery operations, such as where and how data is backed up when the provider changes
• any DR plan that involves a secondary site for hot/warm/cold standby must be modified to reflect the new provider
• data copies resulting from backup or DR operations held at secondary sites belonging to the current provider must be erased once the exit process is complete