Running Our Own Heroku ...and are we out of our minds?
18F is a development shop within the federal government, which builds applications and tools for other agencies. Working in and for the federal government, 18F has some fairly unique requirements and constraints around hosting. This talk will cover the considerations of our DevOps team, the different tools we have tried, and our current work moving to a platform-as-a-service (PaaS).
In the year of our existence, 18F started with hosting our apps on AWS and configuring them with Chef. This worked fine...for a while. None of our applications are especially large or complex, but we have a large number of them; a product team might have hundreds of people working on a single application, whereas we have twenty+ apps for thirty-ish people on our tech team, times however many staging instances of each. Keeping a single “deployment” of an application running was fine, but spinning up new ones or changing configuration became a hassle. It began to feel that a configuration management system (at least by itself) wasn’t going to be enough.
Our team is technologically diverse, so we wanted a consistent way to host our Ruby, Python, Node, and Go apps, as well as static sites with a variety of build processes. In evaluation options, we also wanted an option with good “developer ergonomics”: make our applications easy to deploy, easy to update, and easy to configure, with minimal dependence on the DevOps team. I’ll talk through the options we looked at, our (ongoing) move to Cloud Foundry, and the cool things we’re able to do by having full control of an open source platform.
I am a developer first and have only recently started helping out with this DevOps work, so will be presenting from the developer perspective.
Aidan Feldman is a developer by day, modern dancer by night. When he's not working on open source for the federal government, he organizes Hacker Hours, eats burritos, bikes, and teaches at CUNY and NYU.