One of our principles in Government as a Platform (GaaP) is to avoid being tied to a single supplier. We often get asked how we’ll apply this principle to the GOV.UK Platform as a Service (PaaS). This is a reasonable question and we’ll answer it in this post.
Portability allows those who build and run services to choose the most appropriate supplier, based on features, cost and price, regardless of who is currently providing that service to them. A portable service is one where the cost of migration to an alternative supplier is low.
The benefit of GOV.UK PaaS being portable is that services running on it are still able to purchase alternatives from a competitive market, at a competitive price, without being locked to us as their supplier. This means they’ll always be able to procure the cheapest and best option for their users.
What do we mean when we say lock-in?
Lock-in is a situation where high migration costs force an organisation to continue using a technology, or supplier, despite the availability of less expensive or better alternatives.
High migration costs are caused by:
- features or functionality exclusive to one particular supplier
- business data being stored in proprietary formats
- having to rewrite code to work with proprietary APIs
Portability, therefore, is the ability to move to an alternative technology at low cost within a given time frame.
How do we keep applications portable?
The value of a platform as a service (PaaS) comes from the applications running on it. If all the applications can be moved to an alternative platform at low cost, then the practical consequences of a PaaS becoming locked to any particular supplier aren’t serious.
Service teams building applications are responsible for making sure they’re portable. This should be factored into their technology choices as they make them.
The core of GOV.UK PaaS is Cloud Foundry, an open source product with several commercial implementations. It can be purchased as an installable product or as a hosted service available on the Digital Marketplace. There’s a certification programme to ensure the core product remains compatible between providers - this helps ensure portability.
Almost every application needs to read and write data to a long-lived data store, or share it between instances. Applications running on Cloud Foundry do this using backing services. The core platform provides users with standard ways to add and remove backing services. However, there’s no standard that asserts which backing services should be present on all Cloud Foundry instances. If you use a backing service on one provider, there's no guarantee it’ll be available on another.
To ensure their applications are portable to alternative suppliers, we recommend service teams should use:
- a PaaS such as Cloud Foundry, which is offered as a hosted service by several providers
- backing services, which are offered by multiple providers
How we’ll help with application portability
Being open
We publish all source code modifications we make to Cloud Foundry and service brokers. We submit them to the original project, but only when the project is still active.
We document key architectural decisions, mostly for our own benefit, but they may also be of interest to suppliers and users.
Building the right backing services
When prioritising backing services, the GOV.UK Platform as a Service team will treat application portability as an important requirement.
We’ll only provide backing services based on open source technology that could be made available on any Cloud Foundry installation. We won’t use datastores tied to a specific infrastructure provider.
We may, however, take advantage of existing hosted services. For example, we've chosen to use Amazon Relational Database Service for our first PostgreSQL implementation. We don't think this poses a significant portability problem because there are alternative hosted PostgreSQL implementations.
We’ll prioritise providing backing services to meet the most common needs
We’re planning to provide:
- a relational database (we support PostgreSQL, and MySQL support will be added soon)
- a key-value store suitable for in-memory storage or it could be used as a cache (likely to be redis)
- document indexing and search retrieval (likely to be Elasticsearch)
- a schemaless document database (likely to be MongoDB)
- a message queue
Portability of the GOV.UK Platform as a Service
Although application portability is the most important way to avoid lock-in, we do need to be able to move GOV.UK PaaS to alternative infrastructure providers.
During alpha we explored the possibility of simultaneously running on two infrastructure providers. This wasn’t a feature needed by most of the teams we spoke to, and it comes with a high engineering cost. So we chose to build our beta on a single provider. This meant we could take advantage of some platform-specific features, and move faster.
We're keeping an eye on how much engineering effort we’d need to create another instance of GOV.UK PaaS on an alternative infrastructure provider. And we’ll continue researching the needs of our users in relation to hosting on multiple providers.
What this means for service teams
You can develop using the GOV.UK PaaS knowing there’s a set of backing services, which meet the most common user needs. Also, it won’t lock you into a specific infrastructure provider.
You’ll be free to choose your own external services when using GOV.UK PaaS, but we recommend that you check to make sure you won’t be locked in.
You’ll also have a choice of other Cloud Foundry providers you can move to (or run in parallel on) if they provide features we haven’t built. As GOV.UK Platform as a Service develops, and more features are added and supported by us, you could move back.
To find out more about GaaP components have a look at the Service Toolkit. You can see the range of tools and guidance available to support your work creating and running services.
Subscribe to this blog to hear the latest from the Government as a Platform teams.
2 comments
Comment by Charlie Llewellyn posted on
Very interesting read, thank you.
I'm interested in the backend services you mention, specifically in the choice of RDS. Is this abstracted behind the open service broker API as presumably doing this would significantly improve portability especially considering this is being adopted by many other PaaS solutions like Kubernetes and OpenShift. With this happening we will likely see more service providers being able to provide valuable backend services in a consistent way.
Comment by grahambleach posted on
Hi Charlie,
Yes, Cloud Foundry uses the Open Service Broker API to talk to service brokers, so in theory they could be used by other PaaSes, now that they've adopted it, although we've not tried an integration with any of them so far.
The source code of our RDS broker is available here: https://github.com/alphagov/paas-rds-broker and the BOSH release we use to deploy it is here: https://github.com/alphagov/paas-rds-broker-boshrelease