5 traits of teams that make on-call less terrible for developers

By Derek Bullet_white Comments Comments

Over the past two weeks, there's been considerable discussion on whether developers should be on-call.

I understand the frustration of the anti on-call party. If you go to school to be a doctor, you know that being on-call is likely in your future. You didn't know that being on-call would be a part of your job when you started writing code.

on-call

Like the anti on-call party, I find no immediate joy being on-call. But today, you're swimming upstream if you are a developer and don't want to be on call. In Who owns on-call?, Increment surveyed over thirty industry leaders about their on-call rotations. All but one had developers on call (Slack), but that is changing:

Crowley says that they’ve recently started to see scalability problems with the old way of operations, however, which led Slack to create a secondary on-call rotation full of developers; software and performance bugs, he says, are becoming much more common than low-level infrastructure problems—bugs that only the development teams know how to fix.

To me, it's a no-brainer: if the root cause of most incidents are hardware and network partition failures, then it makes sense for operations to be on-call. They are the ones familiar with those systems. However, if the majority of problem lie within code, a developer needs to write the fix. The underlying infrastructure our apps sit on top of is becoming remarkably more reliable, which means developers are gaining more responsibility (that's a positive spin, right?).

Over the past decade, I've primarily worked on small, fast-moving development teams. I've always valued my time away from the office and believe our developers should too. Developers have always been apart of these on-call rotations and I haven't hated this experience. Below are five traits I've seen from teams that have a healthy relationship with being on-call:

Read More →

 

Deploying a Faktory worker to AWS Fargate

By Derek Bullet_white Comments Comments

Looking for a fresh, 2018 approach to deploying a Rails app to AWS? We've partnered with DailyDrip on a series of videos to guide you through the process. We're covering how to Dockerize a Rails app, AWS Fargate, logging, monitoring, setting up load balancing, SSL, CDN, and more.

In the previous post of this series, we deployed the Faktory service to AWS Fargate and created our first background job. Today we'll setup a Ruby worker service to pull jobs from the Faktory server and execute them.

Read More →

 

Deploying Faktory to AWS Fargate

By Bradley Price Bullet_white Comments Comments

Looking for a fresh, 2018 approach to deploying a Rails app to AWS? We've partnered with DailyDrip on a series of videos to guide you through the process. We're covering how to Dockerize a Rails app, AWS Fargate, logging, monitoring, setting up load balancing, SSL, CDN, and more.

In today's video, we're setting up a background job server for our Rails app. There are several implementations we can choose from, including delayed_job, resque, and Sidekiq, to name a few.

However, today we'll be using Faktory, which was created by the father of Sidekiq, Mike Perham.

Read More →

 

Scout <> Rollbar Integration: unifying your stability metrics 🚀

By Derek Bullet_white Comments Comments

When things are going wrong, the more signals you can view from one screen, the better. Today, we're excited to announce an integration with Rollbar. This brings Rollbar's best-of-breed error monitoring into Scout's performance-focused UI, creating a single source for your stability metrics:

Read More →

 

AWS Disaster Recovery: Configuring a Read Replica and a Multi-AZ

By Bradley Price Bullet_white Comments Comments

We've partnered with DailyDrip on a two-part series guiding you through Automated Backups and Disaster Recovery on AWS. This is part 2. You can read part 1 here.

This is the second portion of a two-part series on automated backups and disaster recovery for AWS. In part 1, we summarized the main options: database snapshots, read replicas, and multiple available zones (Multi-AZ) and walked thorugh the simplest solution: backups. Today, we'll setup a read replica and multi-az.

Read More →

 

AWS Disaster Recovery: an overview and a backups tutorial

By Bradley Price Bullet_white Comments Comments

We've partnered with DailyDrip on a two-part series guiding you through Automated Backups and Disaster Recovery on AWS. This is part 1. Read part 2, which covers read replicas and multi-az.

Have you ever lost data? It can make for a bad day.

Now, imagine you lose your customer's data. That can make for a bad week, if you're lucky. If you're not so lucky, it can cost money, customer trust, bad publicity, and much more.

In today's episode we are covering disaster recovery on AWS. In particular, we will be focusing on a few techniques to deal with data loss mitigation and resiliency.

Read More →

 

Older posts: 1 2 3 4 ... 67