Eight DevOps things Heroku does (so you don't have to!)
Tags: heroku, devops, paas, webdev
Published: 2019-10-15 16:25:13

---
title: Eight DevOps things Heroku does (so you don't have to!)
published: true
description:
tags: heroku, devops, paas, webdev
---


You might know—vaguely, roughly, innately—that deploying an application to Heroku's Platform-as-a-Service would be a good choice to make. It'll save you from the struggles of setting up networks, managing infrastructure, and configuring services, freeing up time to focus on building features for your application, to deliver value to your customers. But maybe you aren't really sure _how_ Heroku does those things. Or maybe (_gulp_) you don't think Heroku can help you out much.

Heroku takes care of so many DevOps-y chores for you that its simplicity tends to obfuscate the number of concerns involved in deploying and maintaining a production-grade app. So in this post, we're going to take a look at just eight ways in which Heroku makes your development life just a little bit easier.

## 1. Manage machine images

Your application is more than just the code you've written. It also relies on the packages you've explicitly imported, the programming language you're writing in, and the operating system your code runs on. You know what that all adds up to? Maintenance. You've got to be on the lookout to make sure that your operating system is patched from security flaws and your programming language is updated for performance improvements, constantly.

Instead of sorting through package security updates, or figuring out how to take your site down and update to the latest Ubuntu, Heroku will take care of all of the security overhead for you. [Here’s a recent blog post](https://devcenter.heroku.com/changelog-items/1649) demonstrating what the process for the end user is to receive critical security updates (hint: it’s nothing).

## 2. Deploy a stack to multiple environments

The problem of machine maintenance scales linearly as you add more servers to your workflow, typically by way of needing more environments. If you need to introduce a staging environment into your setup, you may already have some automation scripts to set up that infrastructure, but now you need to pay close attention to their system dependencies as well.

Deploying the entire stack of a Heroku application is as simple as a `git push` to a new Heroku app. Rather than spending time re-provisioning the minutiae of your servers' needs onto staging servers, you can [just link your different environments and push your code out](https://devcenter.heroku.com/articles/multiple-environments) to a new environment instantaneously.

But maybe you have many environments, and you don’t want to keep entering commands to deploy the app to all of them. That’s fine; you can [set up a pipeline](https://devcenter.heroku.com/articles/pipelines) instead. A pipeline allows you to promote your app through various environments: development, review, staging, production. 

When it comes to environment variables, you can [get and set these through the command line](https://devcenter.heroku.com/articles/config-vars), too:

```bash
# set for production (by default)
$ heroku config:set APP_SECRET=XXX
# set for staging
$ heroku config:set APP_SECRET=YYY --remote staging
```


## 3. Administration and tuning your databases

Databases are at the heart of every application, from the very simple to the very complex. Applications rely on the presence of a database from which to store and retrieve essential information. If connections to this service stop flowing, it can completely kill your application. Tweaking the database engine itself can also eke out some performance gains, which can be critical for high-traffic sites.

Let Heroku's database administrators ensure that the installations are well-tuned, so that your engineers can work on other issues. They'll upgrade the database, automatically apply security patches, migrate you off of bad instances, and more. While your team is iterating on improvements, Heroku's DBAs will optimize your database for gains you didn't even know you needed.

Frequent maintenance of your backend isn’t just lip-service: [it’s a core value Heroku prides itself on](https://blog.heroku.com/frequent-maintenances-for-secure-heroku-data-services).

## 4. Log everything across every environment

Logs: they're not just for lumberjacks anymore! You're likely tracking various actions across the lifecycle of requests, whether that's to your web app, its worker queues, system components, or any backing services. Configuring all of those sources of information can be a challenge, and aggregating into something that can be consumed could be even harder.

Heroku's [Logplex](https://devcenter.heroku.com/articles/logplex) will not only slurp up information from any source you tell it to, it'll also spit it back out in a format that you expect, whether that's for long-term storage, a terminal somewhere, or any API endpoint. You can [build your own pipeline](https://devcenter.heroku.com/articles/logplex#sources-and-drains), or [tap into the existing add-on ecosystem](https://elements.heroku.com/addons/categories/logging) for log routing.

## 5. Monitoring and alerting

As you might expect from its extensive and flexible logging setup, Heroku's also got [a phenomenally beautiful monitoring system](https://devcenter.heroku.com/categories/monitoring-metrics). Although you can choose to integrate with third-parties on this, in many cases, you won't need to. Heroku's dashboard will show you much of what you need to know, from memory health (via GC times and overall usage), to HTTP request/response times, and even the overall health of your server's interaction with its resources. There are also [plenty of external integrations to choose from](https://elements.heroku.com/addons/categories/monitoring) if you’d prefer to hook into an external system like New Relic or Graphite.

For Professional dynos, you can also [set up alerts directly from the Heroku Dashboard](https://devcenter.heroku.com/articles/metrics#threshold-alerting). As you're configuring your thresholds, Heroku will tell you how many times it would've triggered notifications to your time, and advise you to adjust the metrics if they're too sensitive. There's also a native integration with PagerDuty.

## 6. Backups and recovery

Have you got a backup strategy for your application and its infrastructure? _And are you sure it works?_ With dependencies that your system might need—Redis, Postgres, Kafka—you have to set up data backup and recovery strategies, configure the granularity of its retention, and make sure that you've always got enough disk space on hand to keep the backups you need.

Since Heroku's on your side, and probably more nervous about data loss than you are, they've already thought through a thousand different disaster scenarios, and are able to store and restore your data in the safest manner possible. For example, [a single command through your terminal](https://devcenter.heroku.com/articles/heroku-postgres-rollback) can rollback your database to a previous state; if a Kafka node fails, [Heroku's automated systems will work to restore it](https://devcenter.heroku.com/articles/kafka-on-heroku#node-failure-exercise) to its normal operation.

For your Postgres database, you can even [set a schedule for the backups](https://devcenter.heroku.com/articles/heroku-postgres-backups#scheduling-backups) to be taken outside of peak hours. Redis backups/forks can also be set [through the command line](https://devcenter.heroku.com/articles/heroku-redis#migrating-to-heroku-redis).

## 7. Automatically respawn a downed server

It's not uncommon for applications to require the need of a process manager, in order to restart stalled—or completely crashed—applications. But as with backups, ensuring that this daemon is doing the right thing can be tough, especially considering that it "works" only when everything else doesn't.

In the event of the unexpected, Heroku will [restart your servers for you](https://devcenter.heroku.com/articles/dynos#automatic-dyno-restarts), whether that's due to resource exhaustion, a segfault, or just a plain logic bug. While attempting to recover, the runtime also has a cool-off period of several minutes to gracefully resume normal operations.

## 8. Forking primary databases

If your application is highly available, it needs to be in more places than one, which means more of everything--including databases. In the average HA setup, all data writes go to a primary database, and several region-specific secondaries are distributed across the world. Ensuring the proper throughout from the primary to the secondary is a bundle of networking and latency issues, chief among them being to ensure that your application does not read data that has become stale.

For Postgres ([The One True Database™️](https://dev.to/heroku/postgres-is-underrated-it-handles-more-than-you-think-4ff3)), Heroku provides [the ability to fork your primary database](https://devcenter.heroku.com/articles/heroku-postgres-follower-databases) more easily than you might believe possible. By creating a database through the command-line, and providing the `--follow` flag, you can create a read-only follower of your primary database. Changes from the primary are streamed in real-time, allowing for seamless migrations, data redundancy, and a hot standby.

## Concentrate on your needs, not your infrastructure

When you spend less time setting up and executing on your production needs, you’ll have more time for your users’ needs. Heroku runs eight million apps at 25 billion requests per day, and the developers building those apps benefit from a DevOps workflow that's managed for them.