Andrew Snow

You've set up a new server in AWS EC2, and you want your team to be able to access it by SSH. This means authorising access via an EC2 Security Group. Best practice dictates you don't leave this port open to the entire world of hackers and miscreants, but how

At Chargify, we lean heavily on Elasticsearch for data storage as well as search, but upgrading Elasticsearch major versions requires a full cluster restart. We came up with a plan for upgrading with no noticeable downtime, although the cluster was placed into "read only" mode for some time.

In order to upgrade Elasticsearch in-place from v2 to v5, one of the road blocks we faced was that the built-in upgrade feature did not support indexes created with v1 of Elasticsearch. We had several of those left over from a previous upgrade from v1 to v2. So prior to

Applications that generate a stream of events need a way to store them centrally for search and analysis. Elasticsearch is a decent choice for aggregating event logs, but how do you get the data in there? Although an application can write events directly to Elasticsearch, this can become a bottleneck

😱 A nightmare scenario for any business: needing a backup that isn't there! Procedures for performing and verifying backups have always been necessary, and if this can happen regularly, automatically, monitored for any failures, this will give peace of mind and a high degree of confidence in the disaster recovery plans.

In this final part, the locking techniques in Chargify's background job system will be explained. Commonly you need a job to run only one at a time, no matter how many there are waiting to run. We refer to this as job locking, where a job running excludes another one

Here's a few more interesting aspects of our background job system. Make sure to check out part 1 first if you haven't already. Callbacks We've created several callbacks for job classes to use: on_busy when a job lock could not be acquired within the timeout. This is used to

Many Rails apps have some kind of job queue. While the "out of the box" experience with Rails and Sidekiq keeps getting better over time, here's a collection of ways we've improved on the basics at Chargify, to help keep things running smoothly and efficiently in our background

Redis is an in-memory database which has become the default choice for background job queues in Rails applications, because it helps with scaling to large numbers of background job workers. The Chargify application was no exception, having started out years ago with the SQL-backed delayed_job, moving shortly thereafter to