We previously wrote about looking into offering a platform to host digital services. This post is about the technology we chose for the beta and how we made that decision.
The first thing we did was look in detail at the various open source and proprietary options available. I’ve previously written about how we compared the open source options and I mentioned that the front-runners were Cloud Foundry, Deis and Tsuru.
Deis was a very good option, but we ruled it out for our prototype for two reasons: it didn’t have the granularity of user permissions we needed, and it didn’t have a mature service broker, which would allow us to connect to external services, eg Postgres. Both of these things are on their roadmap, but the timing wasn’t going to work for us. However, we had a very interesting conversation with the Deis team and this is definitely a technology to keep an eye on.
With the proprietary options, the method of comparison was slightly different because the source code isn’t available to look at, and because it’s not usually as easy to get a sample platform up and running.
There were four proprietary vendors we were particularly interested in: Apcera, OpenShift Enterprise (Red Hat), Pivotal Cloud Foundry and Stackato. Each one of the vendors answered questions to a similar level of detail as we were able to learn by investigating the open source solutions ourselves. Because of commercial confidentiality, I can’t share the detail here but it allowed us to compare the proprietary solutions, and then again with the open source ones.
They all had advantages, but the one that most suited our requirements was Apcera.
We wanted to get a prototype up and running quickly so we could start showing it to our users in government to see if we were on the right lines. So we decided to start with an open source solution because there are no licensing issues.
We built a prototype using Tsuru, because it’s easier to get started with Tsuru than Cloud Foundry. Then we used that prototype in our user research - we wanted to make sure we understood which features were most important to our potential users.
We then built another prototype in Cloud Foundry to compare its features, ease of use and maintenance requirements to those of Tsuru. Simultaneously, we spent some time exploring a trial installation of the Apcera platform with our engineers providing feedback about each of the three different options.
Licence: Creative Commons Attribution Paul Downey
This is how we apply those categories:
If the technology we choose is not open source, the product would be the proprietary option. So in effect, we’d just be recommending a product to other departments, and they would then have to build their own platform and incur costs over and above supporting and developing the platform. But having the code available for use by other departments as a platform would encourage collaboration with our colleagues in those departments.
Using an open source solution brings a number of other important benefits. The chance to contribute code upstream means we can help make the product useful to us and others in a similar position. Maintaining and building open source components and the ‘glue’ (ie the code required to keep it all together) builds skills and learning in-house. And it also echoes our tenth design principle: ‘Make things open: it makes things better’.
The three technologies we looked at in more detail had a lot to recommend each of them.
While each of the technologies we looked at had advantages, the open source requirement is important to this project, so we had to rule Apcera out for now.
It was a very close contest between Tsuru and Cloud Foundry. After a lot of consideration we chose Cloud Foundry for our beta. The maturity of Cloud Foundry, as well as the size of its community, were the most significant factors in this decision.
However, all three technologies are very good and if your team’s requirements are similar to ours then it’s definitely worth considering them all.
We hope to share more detail about what we learned about each technology in future posts, but in the meantime we’re now starting the beta build using Cloud Foundry. We’re coding in the open, and aiming to be hosting live services early next year.
This post originally appeared on the GDS Government as a Platform Blog.