Hacker News Reader

Comment by throwaway9870 | Hacker News Reader

So you embed S3 into your app? Do you embed your ERP system? How about your marketing e-mail system? Your CRM? Do you use an in-process database?

Everyone already has a service based architecture whether they want to admit it or not. The question is the efficiency and granularity of it.

If you interface with any external systems that have data records (ERP, CRM, etc), your database is already spread out. You need to deal with it and be sure you understand the data efficiency and reliability of it.

I don't know what a monolith is that people talk about. Please show me one that doesn't talk to anything else.

View on HN

Microservices are about fine granularity, not just "talking to other things." There's an enormous difference between "talking to a database" and having to figure out how to roll back transactions because your write to $lastNameService failed after you already wrote to $firstNameService when updating a username. The kinds of problems you run into with microservice based architectures aren't a result of "having services."

Microservices is not the same, though.

I don't see that distinction being made. The counter argument is things like libraries vs microservices. Those articles ignore the common case that probably is true for 99% of the apps - we live in a service based architecture. The Internet is service based. Everything an app talks to is service based. So quit arguing about it.

Microservices don't address any of the issues I ever faced or people on Hacker News talks about like mixing languages, building code around organizational structure, isolating faults, etc. Microservices are way to granular to address those issues well. The only time I ever wrote a microservice is when I had to wrap some stupid SiteMinder binary apache mod blob.

Also, almost nobody writes a monolith, if they say they have a monolith they are probably lying. Do they have a database? S3? ERP, CRM, blah blah blah. Nobody in their right mind would build microservices, that is nuts unless they have some really special architecture. So can we quit the endless debates about stuff and instead focus on the real issue: how to build robust and maintainable service architectures? How to partition systems properly so you can manage avoiding having conflicting data? Eventually consistent systems, etc.

This is as dumb as the CISC vs RISC debate I lived through in the 90s.

Lucky you, that you haven't been hit by the purists.

I am currently getting a hard intro into a microservice first architecture. Where customers are managed in one service, users are managed in a different one, user operations are in a third one. All have their own databases and much of the data is copied between them. There are microservices, that are used by only one other microservice.

That's where we are now - arguing about the validity of "microservices are the best/first" approach.

Microservices are defined as self contained, highly granular, separately developed and deployed horizontally scalable systems.

Think about the debates about Linux vs Hurd, that's where we are.

The idea that no true monolith exists because you didn't write your own kernel is really strange and peculiar. No one has ever claimed that a monolith has 0 external dependencies.

Well, the efficiency and granularity is the crux of the issue. It's what defines a microservice.

Reply on news.ycombinator.com