Hosting and monitoring
Hosting
Apple Developer and Google Play
Digital is in charge of maintain/help support/be technical advisors on nearly all of the mobile apps obtained by the City. They can be found on these.
Amazon Web Services
We use Terraform for describing our infrastructure. See the digital-terraform repo.
Do not make one-off changes in the UI or with the command line. Everything should be updated through Terraform so we have transparency about what we’re running and why.
Terraform changes should be made through Atlantis.
Acquia Cloud
Acquia externally hosts our main website, boston.gov in their cloud instance.
Heroku
Heroku is appropriate for very one-off apps (such as the 311 crowdsource app) where we don’t mind not being on a boston.gov URL or waiting for the dyno to spin up after inactivity.
We only want to use free tier dynos going forward.
We need to get off all paid Heroku services, migrating to AWS/S3 as appropriate. Staging apps, however, should generally deploy to AWS to match production-like environments.
Monitoring
We should never be surprised by an outage. CloudWatch and/or Updown.io should be monitoring our apps and the services they depend on.
If an alarm goes off regularly, either its root cause should be fixed or the alarm should be adjusted or removed.
CloudWatch
We have a handful of CloudWatch alarms to monitor our instances, VPN, and services.
These alarms are sent to the digital-dev@boston.gov email address and posted in the #digital_monitoring Slack channel via a custom Lambda function.
Rollbar
We use Rollbar to track server-side and client-side exceptions.
Exceptions we cannot eliminate should be silenced on the Rollbar side or prevented from throwing in the first place. If necessary, they should be converted to logs that can be monitored.
Updown.io
We use Updown.io for blackbox monitoring of our sites’ availability.
Yes, parking tickets goes down every night and it’s annoying.
Last updated