Since around June, I’ve worked on 18F’s cloud.gov product and this week marked my last quarter on the team. We end every quarter with a so-called “innovation and planning” sprint. The product managers do the planning and the team members do the innovating. Innovating in this context means working on parts of the product that will benefit users that aren’t part of the normal business work. I chose to work on improving the WordPress example app we maintain for our users.
If you’re not familiar, cloud.gov is a Platform as a Service built by federal employees and designed around the specific security and regulatory concerns federal agencies need to consider before they’re authorized to launch a web product. No matter how big or small, whether it has open data or national secrets, all information systems operated by the federal government are required to undergo some kind of evaluation against standards published by the National Institute for Standards and Technology (NIST). The result of this process is the granting of what’s called an “Authority to Operate,” or ATO. Basically, an ATO says that the system meets the requirements outlined by NIST and the agency has accepted any risks the system might present. If an agency runs several websites they end up with a lot of repetitive documentation for components that may be the same across each individual app. cloud.gov attempts to solve this problem by standardizing many of those common components so that the agency only has to worry about the parts of the application that serve their mission directly.
It’s a fully open source and based on the Cloud Foundry PaaS project. Compared to how I’ve launched and managed WordPress sites in the past it’s a pretty big shift in how to think about the product. The main shift is finding ways to not rely on the filesystem.
To do that means pushing your uploaded files straight to S3 or another cloud storage service. It also means session information needs to be stored in a cloud service like redis. Most of the example we cribbed from Cloud Foundry’s example WordPress app but due to slight differences in our infrastructure environment, we needed to make a few alterations. The most significant was the recommended plugin for connecting to S3. Cloud Foundry’s example used a more robust AWS plugin but one that required extra effort for us to connect to Amazon’s GovCloud environment. Using that plugin meant installing two plugins from WordPress and then writing and maintaining our own helper plugin to interface with them. Human Made’s plugin was a drop in plugin that already pulled credentials from the environment and was much simpler to configure for cloud.gov.
Getting this up and running reminded me of the work I did at CFPB getting their then-WordPress site — the last major WP site I worked on — into a stable, easily deployable production environment and how much easier that all would have been with cloud.gov at our disposal.
We configured WordPress very similarly to how cloud.gov arranges the pieces. Uploads were synced to S3 and we heavily cached the site — including the local session. The difference is that we spent weeks, maybe even months, writing and maintaining a Fabric project that could install plugins, update the themes, and manage the version of Core we ran in production and then getting our CI server, Jenkins, to automate the deployment of it all. We ended up with a well-functioning DevOps flow for consumerfinance.gov that didn’t require any of us to be physically around whenever someone needed a deployment to happen. All of that was good and important work, don’t get me wrong, we were rightly proud of what we did. The point is that a product like cloud.gov could have saved us a ton of time because a lot of that orchestration is done behind the scenes.
If we’d had a platform like cloud.gov to start from, we could have saved ourselves a lot of that work and focused on other things closer to our mission.
WordPress was the first open source project I ever worked with and the one that taught me how to be a professional developer. cloud.gov has the potential to make government web applications faster, more reliable, and more secure. The two of them together make up a giant stack of open source code. I’m glad I had a chance to bring these passions together.