I have been doing some holiday reading on:

  1. Edge computing (CloudFlare workers, Fastly Compute@Edge, misc. WebAssembly thingies)
  2. Serverless as it exists in 2022
  3. Jamstack

Collectively, these technologies feel like “the future” in the minds of many devs because so much of the content we consume tells us so (circa 2022).

The marketing of these technologies has an unstated assumption that your team will use a microservices architecture because if you don’t then, well, they don’t have anything to sell you. So implicitly “microservices are the future” too.

I’m not mad at the marketing/dev-rel/early-adopter folks out there just doing their jobs but the rounded off version of this message is “We should start with microservices because it’s the future”. Anecdotally from interactions with clients this year and the content I consume in the dev space, this idea seems to have a lot of traction right now. I am unreasonably annoyed by this because this idea is dead wrong.

Of course microservices architectures have their place but know they are mostly a technical way to solve a social problems. The complexity cost of microservices approach is really high (nobody disagrees on this) but in some situations that cost can be worth it e.g.

  • “we have so many engineers working on the same monolith that merging anything is a nightmare”
  • “Our server load is really expensive and really spiky”

Or let me put it another way: If your small team of devs (<20) chooses microservices you will almost certainly waste a huge amount of engineering time (aka money) solving problems you would not have if a more monolithic approach.

This isn’t a unique insight by any means. I just want to highlight the link between these “things that are supposedly the future” and Microservices.

Sam Newman’s Building Microservices 2nd Edition (Basically the book on microservices) says:

Microservices aren’t without significant downsides, though. As a distributed system, they bring a host of complexity, much of which may be new even to experienced developers.

Microservices have become, for many, the default architectural choice. This is something that I think is hard to justify, and I wanted a chance to share why.

And these are some tweets on the topic which I found insightful:

I’m happy to see a lot more open skepticism about microservices in the last year. They’re a bad match for most systems, but programmers (and especially programmers’ career aspirations) love complexity. https://twitter.com/garybernhardt/status/1603494283935637505

Just as with microkernels, the justifications for microservices often stem from the inability to conceptualize compile-time modularity as distinct from runtime modularity. https://twitter.com/Ngnghm/status/1603605738890444800?s=20&t=fqc4tHV6ShPGN71qadTOGA

Microservices are a technical solution to an organizational problem of having too large an engineering team with too many interdependencies. It optimizes to reduce number of meetings by replacing them with service interfaces. Once you internalize this, you will know peace. https://twitter.com/Carnage4Life/status/1592958912940380160

So what to do? Just be aware that vendors are selling what they have available in 2022, not what is necessarily best for the long term health of your app.

This space is evolving quickly and, over time, I expect vendors will be able to offer greater flexibility.

While “serverless” isn’t exactly a well defined term but I don’t think it inherently has to be limited to Microservices style architectures. Arguably, something like ECS Fargate gets you there without dictating any architectural patterns to you.