Are you ready to get SAD?

After having recently been promoted to Director of Technology Strategy at my job, I am now explicitly getting paid to think about how to more effectively deploy technology. I decided to essentially steal from my employer and publish my thinking for you all to read for free, which not many people do, thus it’s really hard to find free stuff on the internet.

I mostly work on web backends, and I’ve recently been thinking a lot about how to make code more maintainable, and reduce deployment and operational complexity, which is director-talk for “making stuff easier to run and change”, and justifies my salary better. For the end result of that thinking, I present to you, the Single-Application Deployment strategy!

(Yes, the acronym spells SAD, because you’re never going to be happy writing large-scale software, never, so you might as well get used to it.)

The SAD strategy is an alternative to a more traditional microservices deployment. It focuses on reducing complexity in various aspects of the software application lifecycle, which, again, is director-talk.

In this article, I’ll break down the problems we face with the current popular approach, (micro)services, and how the SAD strategy solves a few of them and improves on others. As a warning, there’s probably going to be lots of fancy talk in the article, such as synergies and micro-optimization and hyper-local, and I’m going to need you to imagine that I’m making a silly face every time you read one.

Let’s dive in:

The current problems

How microservices are written.

We’re all more-or-less familiar with the problems of services: They’re the worst strategy we have, except all the other ones we’ve tried, except a few.

  • They’re hard to debug, and need specialized tools.
  • If you start getting wrong results (rather than outright crashes), finding which of the service that misbehaved in the vast web of dependencies is not fun at all.
  • Deployments need to be orchestrated and backwards-compatible, as it’s hard to upgrade all services at once.
  • Changing the contract of an HTTP API is fraught with uncertainty and fear, as you can never be sure what clients speak what, and whether you managed to upgrade them all, and when.

Of course, a service architecture also comes with some Good Bits™, that we’ll ideally want to keep:

The Good Bits™ that we ideally want to keep

Just livin' that microservice life.

Some advantages that services have are:

  • They basically force you to separate your concerns.
  • They allow you to use multiple languages in your architecture, even programming ones maybe.
  • They let you manage your library dependencies separately for each service.
  • They are better-isolated, so a failing service won’t take down ones that don’t depend on it.
  • They allow you to scale on a per-service basis, allocating appropriate server types according to each service’s load.

The SAD strategy achieves most of those objectives, but fails on a few. In my opinion, and as I’ll detail below, its advantages far outweigh the disadvantages.

The SAD strategy

Not so happy now, are we.

Epilogue

What is the difference between SAD and a monolith, you ask? It sure sounds a lot like a monolith! Well, for one, the name is different, and naming is very important. For two, this is a bit more opinionated in some aspects, but yes, it is essentially a monolith with extra bits.

If I had said that in the beginning, though, you would have stopped reading, so enjoy having been tricked!

If you have any feedback, questions, or flamebait, please feel free to Tweet or toot at me, or email me directly.