Hacker News Reader

Comment by majjam | Hacker News Reader

Please can you explain why using microservoces is over engineering? Is it because it’s a relatively new approach? Im getting involved in a new project that is using microservices and a new framework...

View on HN

Because like any design pattern microservices should be used to address a specific problem. Martin Fowler describes that particular design pattern here in great detail: https://martinfowler.com/articles/microservices.html

Microservices however unfortunately have become a fashionable cure-all that's applied indiscriminately to software projects of all sizes, ages and purposes. Hardly anyone seems to be asking anymore why they're actually using microservices. Everyone uses them because everyone else does.

Microservices always incur overhead both in terms of engineering and network latency as well as maintenance / administration. If you have more than 1 microservice you need infrastructure for orchestrating and monitoring these services.

For all that to be worth it you need to have pretty solid arguments for using microservices in the first place. For a new project I'd usually advise against using microservices right from the start. Doing so is often rooted in the same kind of fallacy that has people worry about Facebook-scale scalability before they even have their first user.

If you start having problems that can be solved with microservices then good for you! This means your software is successful and has grown so much in terms of features and responsibilities it's starting to become intractable with standard approaches.

This is precisely why Martin Fowler argues for starting with a monolith first: https://martinfowler.com/bliki/MonolithFirst.html

A traditional monolith gives you the opportunity to learn about the problem domain first without having to worry about implementation details such as microservices.

I think the strategy of "monolith first" isn't a poor one, but it is a little humorous to see someone who makes part of their living helping companies break apart their monoliths advocate it.

I guess. My partner is currently starting a mushroom farm. She hopes one day it will be big enough to make use of a very large facility. Right now it isn't, though. Do you find the same humor in her real estate broker guiding her towards smaller properties initially even though if her business successfully grows the broker will make part of their living helping her move into a bigger location?

Makes perfect sense to me.

I get what you mean by saying it's humorous, but I think it's important that nobody easily dismiss what he says because of who he is.

A lot of what he's arguing against is cargo cult programming, and I think it's fair for anyone to argue against that. If your only explanation for why you chose one architecture or design pattern over the others (especially if that option introduces a lot of additional drawbacks) is "because that's just what you do", you need to stop and objectively evaluate what you're doing.

I second this. You can internally build your monolith in a way that makes a transition to microservices easy. Avoid global state and build single concern processes which have their dependencies passed to them on creation.

Also note that it is very, very difficult for anyone, inexperienced or experienced, to build a monolith that can later be pulled apart. You're two suggestions are a great start. You have to really design with the major blocks of functionality in mind, and carefully manage dependencies between these blocks AND third party dependencies. So many monoliths are balls of mud, that can't be pulled apart with any reasonable effort. The code may not be spaghetti, but the dependencies and interdependencies are.

Honestly, if one can not create a monolith that isn't a giant ball of mud, one has not chance at all of creating a distributed application, microservices or not, even ignoring quality.

In that case one not unlikely ends up with an anti-pattern known as The Distributed Monolith, which combines the worst of both worlds.

What about flow-based programming (https://en.wikipedia.org/wiki/Flow-based_programming)? How would you argue (or not argue) that differs from microservices? When would you advocate for a monolith first vs building one tool that does one thing and does it well and then pipes its output into another tool?

It is a design technique that can be used for designing microservices based applications or any other kind of application that is distributed. So, it's something completely different and the difference you asked makes no sense.

There is a link on that page for the more generic dataflow based programing. I'd advise anybody to follow it and simply ignore its specializations until they master the generic one. I'd also say that any program should be designed from multiple points of view, so do not stop at dataflow.

They work well when designed well - and for me that's more often designed organically. If they're designed badly, most bugs eventually reduce to trying to do distributed transactions across microservices.

That's my yardstick - if I see poor man's distributed transaction attempts happening across service boundaries I'll start to assume over-engineering / cargo culting. If I see services acting a nodes in an pipeline or a flowchart, preferably with multiple incoming lines, it smells better to me.

Did you read Honest status page? If you want your debugging session to reminiscent of a whodunit go with microservices.

If you are doing microservices, I hope you have a good reason for doing so. Because there are significant problems with using microservices.

not OP, but microservices can cause you to have to spend a disproportionate amount of time writing glue code between services. Starting with microservices is often a case of implementing separation of concern at the network rather than the functional layer, which is IMO too high in the stack. Microservices should be extracted for performance reasons, not build from the start because they are trendy.

Reply on news.ycombinator.com