Cover image for "This Probably Won't Solve Your Problem" — A Tough Pill to Swallow

"This Probably Won't Solve Your Problem" — A Tough Pill to Swallow

ben profile image Ben Halpern ・1 min read

We had Kelsey Hightower on the DevDiscuss Podcast this week.

Among several wonderful topics this podcast covered in the realm of "unpopular opinions" was the idea that Monoliths are often a better approach compared with microservices. A move from one monolithic application to a scenario with smaller deployables will bring a lot of power and luxuries in choice... but at the cost of a lot of extra complexity in orchestration.

The big underlying idea is that the problem lies elsewhere. If you have a monolith and it is giving yo problems, it's probably not the architecture, but instead a process or approach that needs adjustment along the way. If you trade in your monolith for microservices you've just traded one set of problems for another, but you're still grappling with the inherent difficulties of complex problem solving and trade-offs.

It was a great episode overall...

play pause DevDiscuss

For a fuller picture of what we discussed in the episode and all the player links, check out this post:

Posted on May 27 by:

ben profile

Ben Halpern


A Canadian software developer who thinks he’s funny. He/Him.


markdown guide

I'm currently migrating ExamPro from a Ruby on Rails monolith to "micro-frontends".

The challenge is:

  • decentralized/distributed authentication
  • the cost of multiple isolate DBs
  • analytics (you have to take all your db's and put them into an OLAP or dump somewhere in S3)
  • multiple pipelines

I think a lot of people solve the authentication/authorization problem utilizing an API gateway or auth micro service for one source of truth and SSO for multiple services. This is especially easier with JWT as you can validate the web token with a shared secret. Thought then rotation becomes a pain and needs an orchestrated mechanism. API Gateways are also good in terms of metrics on your HTTP gold metrics: request durations, error rates and request rate.


An insight from outside the world of dev has always been a useful guide of mine in general, and I've thought of it often when the monolith vs microservices pros and cons debate arises:

An extremely demanding, kind and insightful professor and mentor of mine (she taught Political Science) used to relate the advice she'd hand out again and again as students sought her help/feedback when they encountered difficulties during the writing of their term papers (for her class and those of other professors):

They'd always approach her using some variant of the phrase: "I'm having a writing problem."

She'd look over their work, notes, etc., talk through their processes, etc. Her diagnosis was almost always the same. She'd counsel them: "You don't have a writing problem, you have a thinking problem. If you start to write before you've solved your thinking problem, then you will always reach a point where your writing suffers and breaks down"

A well-thought-through monolith can be maintainable. As can a well-architected approach to microservices. But too often the organization or team jumps at the new form as the solution to all their present woes