DevOps

I have really enjoyed Micah’s recent posts, Embracing NoOps and Are you really ready for serverless?. We share a firm belief that all code is a liability, and that includes “infrastructure as code” code.

GitHub Actions, the new offering for CI/CD and other automated workflows, is still in beta just out of beta and looks promising. In order to get myself acquainted with GitHub Actions, I used the nodenv test suite as a chance to try it out.

Easily one of my favorite things about developing apps with Heroku is its bevy of console commands that make it easy to manage Postgres databases. Recently, however, as one of my apps crossed the threshold from a small “hobby” tier database to a larger “standard” database, the heroku CLI started warning me that several of my favorite commands could risk degrading the database’s performance and its availability to my production application.

When it comes to deploying your application, we’ve been advocating for a NoOps philosophy for some time now. What we mean by this is to encourage your team to focus their efforts on developing features for your application, rather than configuring containers or fiddling with resource management for the hosted product.

Recently, I’ve noticed there’s an alarming, yet subtle, trend in the industry that characterizes serverless as something you absolutely must adopt in your engineering practices. If you’re unfamiliar with serverless, I refer you to the excellent Serverless Architectures article by Mike Roberts.

In The Olden Days™ of web development, a single FTP server and a bash script were all that was necessary to deploy and serve an application. If it worked on your machine, it was good enough for the rest of the connected world.