Hacker News Reader

Comment by ThereIsNoWorry | Hacker News Reader

Yeah, it's crazy the hate microservices get. I happen to work on a product that needs to scale to handle millions of transactions distributed all over the world and the cloud microservice system is just flawless for this purpose. Is it harder to debug than a monolith? Sure. You need a team that has a good understanding about distributed systems (most coworkers have degrees and the ones without are really good at self-teaching, kudos to them). Could you easily develop our system in a monolith? No, it would be a nightmare, if even feasible given the same availability, security and performance constraints. I totally agree not everyone works on stuff I love to work on (huge scalable systems), but Google and co didn't engineer this tech because they felt like it, but because there was a clear need for it.

View on HN

And all the post is saying is that it doesn't apply to everyone. It applies to Google and many other companies including your's, but not all. As a matter of fact, it applies to a very small subset of use cases. If your software handles millions of transactions distributed all over the world, there's a good chance it's within that sweet spot. But most software written in the world doesn't fit that category.

Often the microservices hate is around sole developers ranting about how a waste they are, and how everything would be way better if only everyone was very careful and had good practices totally as second nature.

And it's similar in nature as the hate around high level languages: "If only everyone had decades of experience with C, "toy languages" wouldn't exist and programs would be lighter and faster today".

It is perhaps unfair to compare with Google, since the question of "how will we store the web" clearly calls for a distributed system, whereas the microservice haters are often speaking of systems with an ultimate user base in the low single digits. It _is_ true that with modern hardware you can monolith your way to serving thousands of users at 1 query per second. It is not true that you can incrementally modify that architecture to handle more users and traffic. One must carefully judge such things before committing to either the costs of a distributed system or the limitations of a monolithic system.

A reason this succeeds at Google is that many of the microservice counter-arguments boil down to "yes, but what if I am a jackass?" If you are afraid of having to reimplement your structured logging framework for 11 different languages, I suggest you simply do not do that. Initially everything at Google was in C++ alone, then python, Java, and Go[†] were slowly added. Even after 25+ years of being Google they are not out there trying to diversify languages. You don't need to be Google to exercise good taste and restraint.

†: You needn't correct me regarding the niche languages that popped up here and there because I am aware.

> It is not true that you can incrementally modify that architecture to handle more users and traffic. One must carefully judge such things before committing to either the costs of a distributed system or the limitations of a monolithic system.

I'm a little confused by this, microservices or monoliths can both be distributed systems. A monolithic architecture (eg a Rails app) still usually has a separate database. You can even deploy that monoloth in different configurations (Web vs Worker).

You can then deploy many nodes of that same monolith, pointed at many different shards of a database to handle huge scaling needs. This is especially easy to do if the problem domain lends itself to horizontal scaling, like B2B saas.

I feel like the definition of microservices has gotten a bit murky here.

Well, if you use a scalable SaaS like Cloud Spanner, do you then comfort yourself with the idea that you avoided microservices? Because that seems a little hard to defend on the facts.

Not sure what you're trying to get at here - from the standpoint of developers, Cloud Spanner is the opposite of a microservice.

https://en.wikipedia.org/wiki/Microservices

> A microservice architecture – a variant of the service-oriented architecture structural style – is an architectural pattern that arranges an application as a collection of loosely-coupled, fine-grained services, communicating through lightweight protocols

> A microservice is not a layer within a monolithic application (example, the web controller, or the backend-for-frontend).[8] Rather, it is a self-contained piece of business functionality with clear interfaces, and may, through its own internal components, implement a layered architecture. From a strategical perspective, microservice architecture essentially follows the Unix philosophy of "Do one thing and do it well".[9] Martin Fowler describes a microservices-based architecture as having the following properties:[2]

A typical monolith would use Cloud Spanner as a layer, not as a microservice.

Most people's criticism of microservices isn't about never having independently deployable services, but rather the service boundary being based on business domain decomposition, rather than essential technical characteristics. In other words, different types of storage (due to their technical characteristics, i.e. blob storage for photos vs relational database for transactional entities) being served by different services for technical reasons is eminently sensible and not something most people would have issues with and has been around for much longer than microservices. The problem is more around people deciding that for a hypothetical financial website backend that "bonds" and "stocks" should be two separate microservices, rather than just two endpoints served by the same monolith, even though they differ merely in terms of business logic and do not require any special handling from a technical perspective.

>"Could you easily develop our system in a monolith?"

You have a specific requirement and constraints that call for your system to be distributed. However solutions applicable to majority of regular businesses do not require high scalability and can get easily away with monolith.

I've personally built both types of systems: distributed and monoliths. My take is to always stick with the monolith until you can't.

> cloud microservice system is just flawless for this purpose

> Is it harder to debug than a monolith? Sure.

Doesn’t sound flawless to me

I feel the same way about go-to statements. Crazy hate. Harder to debug, sure, but they make things so much easier.

The "hate" is directly proportional to the failure of microservice zealots to deliver on the ultimate, everlasting, universal prosperity and harmony, that they promised.

Reply on news.ycombinator.com