I have been doing a little holiday reading on the current state of some of the hot new web development technologies:

• Edge computing (using CloudFlare workers, Fastly Compute@Edge, misc. WebAssembly)
• Serverless
• Jamstack

Collectively, these technologies feel like ‘the future’ in the minds of many developers. This is largely because so much of the industry content we consume tells us so.

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. Implicitly, ‘You should start with a microservices architecture because it will let you use the technologies of the future’.

Anecdotally from interactions with clients and the developer content that I consume, this idea seems to have a lot of traction right now. I am unreasonably annoyed by this because this idea is completely inaccurate.

The right architecture for you

Of course microservices architectures have their place. However, it’s important to understand that they are mostly a technical solution to social problems. The complexity cost of a microservices approach is really high (nobody disagrees with this) but in some situations that cost can be worth it.

For example:

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

However, let’s look at a microservices approach from another perspective. Say your small team of developers (<20) chooses microservices, you will almost certainly waste a huge amount of engineering time (and money) solving problems that you would not have if you use a more monolithic approach.

Are microservices justifiable?

It is a great marketing strategy to highlight only the benefits of shiny, emerging technologies. However, if you just accept the benefits and overlook the costs, you aren’t making responsible or effective decisions.

This isn’t a unique insight by any means. I just want to highlight the link between industry promotions of ‘the technologies of the future that also happens to be our new product line’, and microservices as an emerging best-practice for all web applications, regardless of context.

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 these are some tweets on the topic that I found insightful.

@garybernhardt “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.” 

@Ngnghm “Just as with microkernels, the justifications for microservices often stem from the inability to conceptualise compile-time modularity as distinct from runtime modularity.”

@Carnage4Life “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.”

My final thoughts

So what to do?

My advice is to just be aware that vendors are selling what they have available in 2023, not what is necessarily best for the long term health of your app. However, this space is evolving quickly and, over time, I predict that vendors will be able to offer greater flexibility.

While ‘serverless’ isn’t exactly a well defined term, I don’t think it inherently has to be limited to microservices style architectures. Arguably, something like ECS Fargate can get you there without dictating any architectural patterns to you. And that may be a topic I share my thoughts on next time.