The Delivery Newsletter #57
#57 OCT 14, 2020
The Delivery Newsletter

On Call Shouldn't Suck: A Guide for Managers

Charity Majors believes:

If you're asking engineers to be on call for their code -- and you should -- you owe in return:
  • enough time to fix what's broken
  • hands to do the work
  • closely track how often they are interrupted/woken

She clarifies that this applies to "24x7 highly available services"

Have a feedback loop

This post tangentially relates to continuous delivery. It's more about continuous reflection, which can lead to software delivery performance improvements if that's the focus. Jonas, the author, writes that analyzing your performance leads to questions:

Questions are my way of moving onto bigger and unknown flaws. Such as "Where do I waste the most time currently?" or "What's slowing me down" or "Where should I go next?".

We should continually analyze the pain points in our software pipelines. This post offers one method to do that.

Observability 101: Terminology and Concepts

I came across this introductory-level post after talking with a new newsletter subscriber. I know there's a lot to learn in your first year of software development. This post may come across as another barrage of terminology in a seemingly endless storm. Please glance over it 😁 Conversations about operations at work will feel less alien with time and repetition.

Why the Serverless Revolution Has Stalled

Despite the click-bait title, this post brings up the main difficulty I've encountered while contemplating serverless:

Your successful monolithic app probably shouldn't become a series of four dozen functions connected to eight gateways, forty queues, and a dozen database instances. For this reason, serverless suits greenfield development.

If you've (successfully or not) ported a monolithic app to serverless, please reply to this newsletter! The email goes straight to me, and I'd love to talk with you about the journey.

🔊 Podcasts

Gitpod: Cloud Development Environments with Johannes Landgraf and Sven Efftinge

Standardized, accessible dev environments appeal to me as a yet unobtained ideal. Johannes brings up an excellent point about code reviews and cloud dev environments. He talks about the context switching that occurs when you're working on something, and a co-worker asks you for a code review. You have to stash your work. You have to put your environment in a state for the code review. Switching state may mean running database migrations. There are several particular steps that you have to take before you're ready to review the code. Each step takes you farther away from the work you were doing. Cloud dev environments like Gitpod offer a way to make that happen at the push of a button. Listen on for other advantages to ephemeral dev environments.

🎥 Videos

What the H*ck is Observability? (with Shelby Spees) — Learn With Jason

Need another introduction to observability? If video is more your speed, check out this episode of Learn with Jason. Shelby Spees and Jason live code a Honeycomb integration.