Over the past few months, the Government Digital Service (GDS) and the National Cyber Security Centre (NCSC) have worked together to review the government’s cloud guidance to make sure it’s relevant and useful.
We’ve also been sharing user research, collaborating on early drafts, and making sure the guidance that we publish is consistent on GOV.UK and the NCSC website.
So, when GDS published the cloud lock-in guidance, we wanted to write a joint blog post to show how security fits into the picture when you’re managing lock-in.
Value versus portability
The GDS guidance emphasises how managing technical lock-in is a balance between value and portability.
By value we do not just mean value for money. We also include all of the other benefits that cloud services offer that you could not provide yourself or that would be too expensive to build, like integrated security monitoring or automated load-balancing. By portability we talk about how easy it would be to move that service to another cloud provider.
With many cloud services you have to sacrifice value to get portability. Completely avoiding lock-in is impossible, but you can often reduce it by using services that offer less value.
One of the biggest benefits of using managed cloud services is that they can do a lot of the security management for you automatically. While we often discuss cloud-specific risks, a good cloud service will often mitigate the risks we’ve had to deal with in the past. For example, patching, threat hunting, system hardening, and configuration management are all much easier to achieve at scale.
The more cloud-native your design, the more effectively the cloud can mitigate these risks.
We’ve also talked about the patching benefits of using serverless components before, but the amount of patching you can get from the vendor often depends on how much lock-in you accept. For example, Infrastructure as a Service (IaaS) servers and containers will receive some patching from the vendor, such as firmware, chip microcode, and the hypervisor.
Serverless components have more lock-in, but the vendor will also patch the operating system, local binaries made available to you, and possibly the language runtime. Software as a Service (SaaS) will be fully patched by the vendor, as you provide nothing that could need patching.
What to do when portability is reduced
Another important part of managing cloud lock-in is understanding where it makes sense to accept reduced portability. The GDS guidance says that when portability is very low, organisations should consider how they will change their cloud provider in future. This is sometimes called an exit strategy, and it is a useful way to plan for what would happen if you needed to change provider where the loss of portability is worth the added value.
The most important thing you should do is make sure that your data can easily be exported in a format that could be moved into another provider. Considering that requirement as early as possible in the procurement process will help to prevent severe technical lock-in.
However, it is typically good practice to try to make architectural decisions that make the use of cloud-native components as portable as you can. The NCSC had some great ideas about how to do this. For example, you could deploy your services using infrastructure as code so that you can focus your migration effort in a single place, or you could use a language or framework that you know works on several providers where you’re writing code.
Using cloud-native services
Some cloud-native services have less lock-in than you might expect. Serverless functions tend to contain so little code that even rewriting them completely will typically take less work than refactoring a tiny percentage of a big application that is running in IaaS.
If you use cloud-native services that other providers will have equivalents to, such as identity or logging, then you just need to change those APIs when switching provider, making future refactoring easier.
Similarly, where one of your components is widely used elsewhere, you may prefer to use a standard protocol or define separate APIs that abstract the underlying service from its consumers. This enables you to change the underlying service without disrupting your consumers, which NCSC did with its Signin service. By loosely coupling where necessary, it becomes easier to migrate from one provider to another.
Taken together, techniques like these could be very powerful ways to minimise portability risk while keeping the amount of value you get from the cloud as high as possible.
Future guidance
GDS and the NCSC will continue to work together on ideas for future guidance, case studies and blogs.
We’d also love your feedback on the cloud lock-in guidance and where you think the NCSC or GDS should focus next.
Please let us know via email at cloud-strategy@digital.cabinet-office.gov.uk or leave a comment below.
