NHS Cloud Strategy adoption plan

The 13 objectives are to provide the foundations to allow informed decisions to be made along your cloud journey and highlight the NHS Cloud policies that are in place to maintain governance and provide assured cloud adoption.

1. Adopt the NHS cloud implementation principles into your thinking about cloud.
2. Do a hardware licencing audit to understand what you have in your estate.
3. Carry out a workload assessment to find out what you can and should do with application in terms of re-host, re-platform, re-purchase, re-factor, retain and retire.
4. Understand security requirements, considerations, and best practices for hosting in the cloud.
5. Understanding where you application data can be stored and processed within the cloud.
6. Understand cloud service offerings and where applications are best placed.
7. Create a Cloud Centre of Excellence to pool resources and understanding of cloud adoption across your organisation.
8. Understand hyper-scale cloud provider offerings and choose the right one to fit your product requirement not your organisation.
9. Understand lock-in and how to safely navigate an offering to provide a means to safely take advantage of a service. 
10. Have a cloud provider exit strategy
11. Where suitable migrate applications to the cloud.
12. Re-factor application to become cloud-native.
13. Understand when to use multi-cloud technologies effectively and efficiently.

The NHS cloud principles are the proposition of how cloud technologies and supporting services should be provisioned within the NHS and are aligned to the NHS architecture principles and best practices.

Cloud implementation principles

• design for cloud-first
• connect with the Internet
• secure from day zero
• automate everywhere
• decouple and connected to the many
• optimise, then observe, then optimise some more
• people make cloud happen
• be open, share, and learn from others
• tag, know what it's for
• evolve to survive
• use what's right not just because you need too

Supporting principles

NHS Cloud implementation principles

Part of the initial engagement needs to include an assessment of the organisation's existing hardware footprint and software estate.

The hardware part of this needs to include an assessment of the hosting environment including the data centre and facilities along with the hardware utilised, its age, and carbon footprint. The utilisation of that hardware should be covered i.e. the peak and average percentage of memory, cpu and storage resources used. Additionally, if virtualisation is in use the number of virtual machines along with their specification and utilisation should be recorded. The information on utilisation alone should provide the data which can be used as an indicator of how large the estate would be, if run at a higher utilisation using elasticity of cloud resources to ensure peaks in demand are met. Many cloud vendors also provide schemes to purchase hardware made obsolete by cloud adoption and provide cloud credit in its place.

With regard to licensing this needs to cover not only the software products in use and the model used to license them (open-source, commercial perpetual, right to use, etc) but also to provide an understand of the vendor’s restrictions and whether they can be utilised in cloud environments. Furthermore, it is important to ensure the audit covers the full software stack, including hypervisor (if used) operating system, middleware and application components. Major versions of software should be captured to provide information on the number of versions in use.

All this information will provide a useful starting point for the application workload assessment.

Supporting guidance

NHS Cloud sustainability guidance

To find out what you can and should do with your applications in terms of re-host, re-platform, re-purchase, re-factor, retain and retire.

The first step of the application migration process will be to perform an assessment of the existing estate and workload. Initially, this needs to cover the physical and virtual estate to identify what instances are running and what services they support - this will provide an initial view of what efficiency savings could be had from right-sizing the instances. 

The second stage of the assessment process will be to perform an assessment of the workload. This assessment will need to be performed by a mixed team consisting of cloud professionals and members of the existing application support/management teams. 

From the workload assessment activity, we should not only understand the potential migration path for individual applications but also the dependencies on them - these dependencies not only drive out order but also assist in highlighting risks such as challenges with internet connectivity.

Supporting guidance

NHS Cloud Migration guidance

Considerations and best practices for hosting in the Cloud

Cloud security is the protection of data, applications, and infrastructures involved in cloud computing. Many aspects of security for cloud environments (whether it’s a public, private, or hybrid cloud) are the same as for any on-premise IT architecture.

High-level security concerns like unauthorised data exposure and leaks, weak access controls, susceptibility to attacks, and availability disruptions affect traditional IT and cloud systems alike. Like any computing environment, cloud security involves maintaining adequate preventative protections so you:

• know that the data and systems are safe
• can see the current state of security
• know immediately if anything unusual happens and
• can trace and respond to unexpected events

While many people understand the benefits of cloud computing, they’re equally deterred by security threats. It’s a dynamic environment where things are always changing like security threats. The thing is that, for the most part, cloud security is IT security. And once you understand the specific differences, the word “cloud” doesn’t feel as insecure.

The cloud can be made highly secure and many major government agencies are running critical and sensitive services on the major cloud providers. However, it is important to remember, the responsibility for ensuring these services are secure does not sit with the provider in most cases, but with the owner of the services – the cloud is not secure by default. 

Dissolving perimeters

Security has a lot to do with access. Traditional environments usually control access using a perimeter security model. Cloud environments are highly connected, making it easier for traffic to bypass traditional perimeter defences. Insecure application programming interfaces (APIs), weak identity and credentials management, account hijacks, and malicious insiders may pose threats to the system and data. Preventing unauthorised access in the cloud requires shifting to a data-centric approach. Encrypt the data. Strengthen the authorisation process. Require strong passwords and 2-factor authentication. Build security into every level.

Everything is now in software

Cloud computing infrastructures along with all the data being processed are dynamic, scalable, and portable. Cloud security controls need to respond to environmental variables and accompany workloads and data while at rest and in transit, either as inherent parts of the workloads (for example encryption) or dynamically through a cloud management system and APIs. This helps to protect cloud environments from system corruption and data loss.

Sophisticated threat landscape

Sophisticated threats are anything that negatively impacts modern computing which - of course - includes the cloud. Increasingly sophisticated malware and other attacks like Advanced Persistent Threats (APTs) are designed to evade network defences by targeting vulnerabilities in the computing stack. Data breaches can result in unauthorised information disclosure and data tampering. There’s no clear solution to these threats, except that it’s your responsibility to stay on top of the cloud security practices that are evolving to keep up with emerging threats.

The National Cyber Security Centre (NCSC) has put together some helpful guidance with regards to understanding security within the cloud which can be found below

Cloud storage is a cloud computing model that stores data on the Internet through a cloud computing provider that manages and operates data storage as a service. It's delivered on-demand with just-in-time capacity and costs and eliminates buying and managing your own data storage infrastructure.

As cloud storage and processing services can operate at the country and global level it is good to understand legislation around how data can be stored and processed. In the past, this has caused some confusion due to the difference between data storage and data processing. By default, data can be stored within the UK, but Cloud services that process data are not always available with the cloud service providers UK region. This can halt innovation or workaround being developed which can be complex and difficult to maintain.

Cloud Data Storage in digital, machine-readable medium is sometimes called cloud storage. Cloud storage is one of the core functions of a general-purpose computer. Electronic documents can be stored in much more efficient ways and accessed by a number of your services rather than storing within your own data centres. Cloud storage also supplies you with the function of automatic data storage policies that can move infrequently accessed documents into archive storage at a much lower cost.

Cloud Data Processing occurs when data is collected and translated into usable information. This can be done using several services within the cloud and is dependent on the outcome you require. The raw data can be processed into information that can be used for operational purposes such as medical appointment reminders, data transformed into information for reports, and data used within the research for detecting patterns and anomalies that can be used for future medical functions.

In the past, there has been confusion and misinformation around where data can be stored and processed. This has led the NHS to hold back on its adoption of cloud. However, with this guidance we are now putting a definitive understanding in place that your data must be stored within the cloud service providers UK region. If a suitable cloud data processing service is not available within the UK then, as the UK maintains ‘adequate’ data protection laws, data can be processed in the EU.  

With regards to using cloud data innovation, you can use any cloud service globally but must not use personal identifiable information and must not connect to any production service. However, you are free to use services within any of the cloud service providers regions to get a better understanding of the technology, with an aim to then show how a cloud service if brought back to the UK or EU regions, would benefit the NHS. Then working with the cloud service provider to put a case together to enable this service for NHS use within the UK.

Supporting guidance

• NHS cloud storage and data guidance
• ICO guidance on cloud computing
• NHS cloud innovation guidance

One of the goals of public cloud adoption is to free teams up from performing activities that add little direct business value.

When deciding what cloud service model should be adopted it is is recommended to reduce the amount of work and overhead. IaaS services should be used as sparingly as possible, removing the need to manage operating system and runtime environments, which would include tasks like patching, OS upgrades and other administration.

to pool resources and understanding of cloud adoption across your organisation

Pre-application migration starting in the organisation will need to form a centre of excellence team and build the organisations cloud landing zone(s). The landing zone provides a compliant company-focused structure in the public cloud(s) of choice with structures that allow product teams to create accounts/subscriptions and deploy products in a structured manner that does not lead to organisational risk.

The Centre of Excellence team (CoE) is a cross-functional product team to provide the following functions to the organisation they are part of

• build, maintain and develop the enterprise landing zones in whichever public cloud providers the organisation is deploying into. This assumes frequent interaction with the product teams who are deploying to the cloud
• produce and maintain the organisation specific guardrails and policies 
• provide consultation services to the wider organisation on cloud best practice, ideally using a common framework as a basis.
• provide a catalogue of Infrastructure as Code (IaC) modules/patterns to support common deployments and encourage reuse and collaboration across the organisation
• provide a clear process to support contribution to any of their assets from the wider organisation 

and choose the right one to fit your product requirement not your organisation

Where the organisation's maturity in the cloud is low the preferred approach will be to pick one of the hyper-scale providers to use their framework to support migration. While this approach puts a large dependency on a single provider it gives the organisation time to learn what good cloud deployment looks like and work through some of the inevitable challenges with a consistent set of technologies.

Once the organisation has 18-24 months of experience building and maintaining cloud-native architectures, new solutions or substantial changes should be reviewed against multiple providers offerings. A decision to use multiple cloud platforms shouldn't be taken lightly as it will require involvement from multiple business areas including.

Finance: what does the billing look like and how does deploying into multiple providers affect levels of discount?

CoE/landing zone team: what does the new platform require from a landing zone. what level of adoption is likely and what level of automation is suitable to support this?

Product team: What does the new platform do differently, are there new technologies we need to learn, is our existing tooling suitable?

and how to safely navigate this to take advantage of an offering

Lock-in is generally seen as a negative effect of consumption of vendor-specific capabilities or features especially when considered alongside the cost and risk of migrating a product between vendors' products. Avoiding Lock-in is frequently referenced when cloud strategies pick IaaS or containers over PaaS/SaaS. This is frequently an oversimplification of the problems and rather than providing a platform that supports a workload migration between providers, it puts the customer in a middle-ground where they are unable to take advantage of the capabilities provided by the platform. This requires substantial engineering support and compromises internally to build to the differences in the individual cloud providers. Gartner sums this up well with the following quote⁷:

“Even if you think you are avoiding lock-in by doing something yourself, you are actually still locked in — you are simply locked into your own IT team, rather than being locked into a vendor.”

Lock-in is in some ways part of building technology products, while it should be understood and decisions made on a product by product basis it is worth considering what avoiding vendor lock in will provide:

• consider lock-in and portability from an application rather than infrastructure perspective, it is far easier to move an application to another provider than it is to move infrastructure components without starting to build from scratch.
• understand that the commodity IaaS foundations of public cloud differ massively between vendors, there are no standards and are unlikely to be cross-vendor standards in the future. The market is highly consolidated and vendors do not compete on cost.
• be very wary of containers as a method to remove vendor lock-in, while containers ease some portability challenges and can provide development and operational management benefits they are not a panacea.
• While abstraction layers promise to improve portability between vendors they introduce their own lock-in (what portability or options are there between providers of abstraction layers?) and reduce the functionality of the underlying platform. In addition, the differences between providers are likely to be the USP of the specific vendor and removing these negates the value of a specific vendor.
• consider the following aspects of the application: Performance how likely is it the application will scale to the point where a single cloud provider cannot meet the demands? Resiliency - does the application have availability needs that are unlikely to be met or are likely to be at risk if it is deployed into a single vendor's platform?
• identify the barriers to portability: consider technology, people, processes and tools, data volumes, contractual obligations, and the ecosystem (partners working with the vendor) consider both the cost and time required to switch for each element

It is highly unlikely that a single event (outage) would trigger an organisation to exit a cloud vendor, what is more, likely is the vendor's priorities will no longer align with the organisations and for cost or other market reasons, a gradual transition away from a provider will be required.

When making solution decisions look carefully at the provider options and understand where on-premise alternatives exist. Many vendors provide opensource based product offerings alongside bespoke or custom offerings. While decisions on technology fit should not be made solely on availability outside of a specific cloud vendor it is worth considering whether a truly open-source software-based solution is available and doesn't create further compromises and overhead.

Need to consider carefully the effort involved in exiting a provider against the effort involved in building and maintaining a set of platform components over-consuming them as-a-service. Is it possible to limit the platform technologies used by the organisation to reduce the effort involved in maintaining them rather than consuming using the as-a-service model?

Given the frequency and likely timescale involved with exiting a provider, it would be recommended to look at the exit on a per-product basis as part of the product roadmap, similar to how mature product teams would evaluate whether there were advantages to consuming services from a different provider.

Supporting strategy

NHS cloud exit strategy

Application migration should be seen as an early step on the migration journey and one that is being performed as an organisation rather than on a per-team or per-department basis. Data from the previous assessment needs to be used alongside application product team knowledge. Applications should be migrated in “tranches” where applications with shared dependencies or commonalities are migrated side by side. This approach should also provide a quick feedback loop to improve migration success as the teams progress, starting with applications that have low complexity and business criticality and moving onto the more complex migrations as experience improves.

Supporting guidance

NHS Cloud migration guidance

Depending on the migration path taken the application modernisation process may be as simple as understanding when during the migration the re-architecture needs to occur or as complex as a lift and shift migration followed by a roadmap to evolve the product into a more cloud-native solution. Ensuring that the goal is seen as modernisation rather than purely a migration activity is key to unlocking the goals of this strategy.

The focus of modernisation should be not only on the application facets but the capabilities of the team supporting them. 

Cloud-native is all about changing the way you think about constructing critical business systems and the way systems are designed to embrace rapid change, large scale, and resilience.

Applications have become increasingly complex with users demanding more and more. Users expect rapid responsiveness, innovative features, and zero downtime. Performance problems, recurring errors, and the inability to move fast are no longer acceptable. Cloud-native is about speed and agility. Business systems are evolving from enabling business capabilities to being weapons of strategic transformation that accelerate business velocity and growth. It's imperative to get ideas to market immediately.

Here are some companies that have implemented these techniques. Think about the speed, agility, and scalability they've achieved.

Designed to thrive in a dynamic, virtualised cloud environment, these systems make extensive use of cloud infrastructure and managed services. They treat the underlying infrastructure as disposable - provisioned in minutes and resized, scaled, moved, or destroyed on-demand via automation.

Consider the widely accepted DevOps concept of pets vs. cattle. In a traditional data centre, servers are treated as Pets: a physical machine, given a meaningful name, and cared for. You scale by adding more resources to the same machine (scaling-up). If the server becomes sick, you nurse it back to health. Should the server become unavailable, everyone notices?

The cattle service model is different. You provision each instance as a virtual machine or container. They're identical and assigned a system identifier or tag such as Service-01, Service-02, and so on. You scale by creating more of them (scaling out). When one becomes unavailable, nobody notices.

The cattle model embraces immutable infrastructure. Servers aren't repaired or modified. If one fails or requires updating, it's destroyed and a new one is provisioned. This is all done via automation.

Cloud-native systems embrace the Cattle service model. They continue to run as the infrastructure scales in or out with no regard to the machines upon which they're running.

Cloud platforms support this type of highly elastic infrastructure with automatic scaling, self-healing, and monitoring capabilities.

Supporting guidance

NHS cloud development guidance

There are multiple benefits as well as a number of challenges to splitting deployments between multiple cloud service providers. While cloud adoption is in general low and teams have relatively little exposure to cloud platforms there is substantial value in picking the initial migration use cases so that the deployments are into a single provider and looking at multi-cloud as the organisation's maturity improves and the migration candidates become wider.

What is seen as productive multi-cloud is making a decision about the product destination based on the requirements of the product and the capabilities offered by the respective cloud providers. It is recognised that this approach will require a level of maturity in the organisation to ensure decisions are made in a consistent manner. Currently, there are fewer values seen in approaching multi-cloud for either

• the ability to run or migrate a single workload (application) between multiple CSP’s as a BAU activity.
• the desire to architect solutions so they are able to run on any providers infrastructure.

Both of these objectives would mean either only IaaS services were consumed limiting the value that can be taken from cloud providers or substantial amounts of upfront work would be required to get any solution live which would not be cost-effective.