Technology Infrastructure at MAPC
The Digital Services team at the Metropolitan Area Planning Council spends the majority of its time doing software development, but is also responsible for maintaining the software in production. Since the majority of our time is spent writing code we have chosen a production stack that outsources the responsiblity of maintaining and monitoring our applications to outside vendors. This approach has the advantage of minimizing maintaince tasks and labor, but also has the downside of limiting the amount of customization we can do. Below we explain why we have picked a few of the services we use and why.
Application Servers
We primarily run our web applications on Heroku, and our database servers on Amazon Web Services. Running applications on Heroku allows us to spend less time worrying about provisioning and maintaining production machines and to spend more time developing applications. Heroku also allows us to create temporary servers that house a new version of an existing application so users and developers can test it in an environment that is similar to our production environment. Heroku also has the advantage of having a large user base with most beginning Rails developers being exposed to it. This minimizes the barriers for a new developer to stand up their own instance of our application.
We run our databases on Amazon Web Services because it is more economical than Heroku’s basic database offering and also provides greater interoperality with our internal databases.
Logging and Exceptions
When we deploy Rails applications to production we have them log at the INFO level. Logging at the INFO level minimizes the extranous When our applications have errors or performance issues the first place we look for hints are in the logs. We have adopted LogEntries as our log file aggregator and monitor. LogEntries also provides alerting when the log is flooded with lots of messages, which is often a sign of application trouble. The reason we picked LogEntries over competing products like PaperTrail is it is easy to setup a log drain from Heroku or any other source, and the LogEntries UI seems easier to use. Its free tier is also more generous.
To make the process of analyzing log output easier we are investigating the use of the lograge gem with our applications. Lograge consolidates the log entries to use a single log line for each HTTP request. Currently many of our applications have verbose logs which might be helpful to debug issues on a staging server but make it more challenging to find relevant information on a production server. We can offload some of those tasks to other programs like Scout for showing us performance.
We use Airbrake to keep track of any application exceptions. When a Rails application has an exception Airbrake will create a record of the exception and allow developers to review its cause. It will provide a stack trace for debugging purposes and allow the technical team to keep track of whether or not they have resolved the exception. It also provides information about the client that triggered the exception.
Performance Monitoring
Some of our applications run Scout which provides both monitoring of the app while it is on the server and a tool for local debugging. Application performance monitoring is important so that developers understand how quickly their application is running for a user. They provide tools to let us know when spikes in load time occur or if errors are happening. They also provide tools for locating the source of performance problems. This is important because slow applications are not only challenging to use, but lead to disappointed users.
In sum this set of tools keeps our applications working smoothly and makes us aware of issues as they arise in production. They minimize the barriers for new developers to get involved and also can scale with us as our applications grow. Some of the services like Heroku might not be economical for applications that require a lot of server resources, but for now most of our applications perform fine.
