Last time we blogged we talked about building a platform to host digital services and how we chose cloud foundry.
Before we move on to what we are up to now, here's a quick reminder of what we are doing and why.
Hosting is one of the most time-consuming barriers for new digital services. Often teams spend significant time solving the same problems in different ways over and over again.
There's a better way.
We want to make it faster, cheaper and easier for service delivery teams to build fantastic digital services, without having to manage complex infrastructure.
What are we building?
So, let’s start with one of the official definitions from our friends at nist.gov (they love defining things).
'PaaS - a capability provided to the consumer to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider.'
Very precise, but a little heavyweight, so here’s a simplification in picture form:
Service teams work on the parts of the system that are unique to the services they run. These are the user-facing front end, supporting back end services, scheduled tasks and the security of their applications.
We'll deal with all the things ‘below the surface’ like infrastructure, logging and monitoring, backing services for things like storing data, securing the infrastructure, ensuring high availability, networking and so on.
As we build out the service, the list of backing services we provide will grow.
Our beta and fundamental service needs
Our beta is focused on meeting the fundamental needs of all services that use our platform, not just the individual needs of specific services. We identified these fundamental needs in our alpha. Let’s take a step back and remind ourselves what they are.
Referencing Maslow’s Hierarchy of Needs, Gojko Adzic eloquently explains in his post on redefining software quality, that to create an ‘awesome’ service we need to make sure that what we build is useful, useable, secure, performant, functional and deployable. These are fundamental user needs and they apply to all services, not just our platform.
User feedback from our alpha tells us that the problem we're solving for service teams, is both ‘useful’ and ‘usable’ as per Adzic’s model. We'll be conducting more user research on this in the future to make sure that this remains the case throughout.
The diagram depicts some lower level needs, specifically for the platform we're building. Here's how these translate into specific areas of work.
Deployable
It's crucial that we update the platform without interrupting user’s access to hosted applications. During our beta we need to make sure we can:
- apply the Cloud Foundry releases every two weeks
- patch security vulnerabilities quickly
- improve the platform
Available
The platform must be resilient. One of our beta goals is to make sure that the recovery of the platform’s most important functions is automated within 30 seconds of a component failing.
The most important functions on our platform are:
- the hosting of applications that can handle web traffic
- users (also known as ‘tenants’) being able to deploy and scale out applications
To make sure these functions keep running after we make changes to Cloud Foundry or our configuration, we’ve written a set of automated tests which replicate failures.
Performant
Our users need a platform which is continually high-performing and effective - we call this ‘performant’. So if we have to make changes to the platform, the capacity of users' applications shouldn't change significantly.
In addition, the platform needs to respond to user requests, such as scaling out an application within a reasonable time.
Secure platform
The platform needs to be well defended against unauthorised activity. So we need to have:
- a good understanding of the risks we face
- measures to prevent unauthorised activity
- the ability to detect or respond to the highest priority risks
We now have a good understanding of these risks and we're working to build better defences.
Secure applications
We need to explain to users how the platform addresses the Cloud Security Principles so they can make an informed decision about what to use the platform for.
Users also need to know what their technical security responsibilities are. We’ll publish a shared responsibility model to help with this.
What’s next?
In our next post we’ll take a look at the needs of the first services to be hosted on our platform. In the meantime, please get in touch if you have any questions, or let us know if there are topics you’d like us to cover in future posts. Or you can leave a comment below.
And if you work in central government and are interested in using GOV.UK PaaS in your service, email Cordia Lewis.
Follow Rory on Twitter and don't forget to sign up for email alerts.