Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microservices are hard

code-held.com

Post reply on HN
Print view View original

251–260 of 356 posts

Re: Microservices are hard

#251

Post by garethrowlands »

nostrebored wrote: post #9
PlumpyGER wrote: post #4

Earlier quoted context omitted.

The problem with standardizing these things is, that it makes them hard to change. A breaking change in the way you deploy must also work for all other solutions - otherwise you immediately loose your standardization. And this will happen eventually. For all this different kind of problems it is near impossible to avoid inconsistency and force rules on them. So, imo you either have a (very) large organization with in…

No, standardizing these things makes them hard to change for devops. How many breaking deployment changes have you seen in reality? You're right that microservices shift burden onto infra. But that does not make it a big ball of mud -- infra has gotten progressively easier over the past two decades. If you want me to create the 'ball of infra mud' mentioned in your article, I can do it -- and make it repeatable -- in…

Who is this devops of which you speak? Did you just mean that standardising these things makes them hard to change? Or, by 'devops', do you mean a particular group of people?

Re: Microservices are hard

#252

Post by John23832 »

Start with a monolith, that will take you VERY far.

When the organization gets big enough (AND ONLY THEN), add an additional domain oriented service. FULLY implement deployment and infra. Only once you do that can you think about adding another (using the pattern you just built out).

Micro-monoliths.

Organizations explode the number of services, half ass the infrastructure (the hard part of microservices), and then crumble under the organizational complexity.

Re: Microservices are hard

#253

Post by jeffbee »

d_watt wrote: post #118
jeffbee wrote: post #73

Earlier quoted context omitted.

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 tha…

> 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. Yo…

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.

Re: Microservices are hard

#254

Post by hdjjhhvvhga »

sidlls wrote: post #154
hdjjhhvvhga wrote: post #31

Earlier quoted context omitted.

> Why have a single database when we can silo our data across 200 mini databases? First, many orgs using, say, Kubernetes still run their database separately in a traditional way with replicas etc. Second, those who do run their DB inside Kubernetes, probably using an operator, gain scalability and additional resiliency (it also depends on the DB, but these days even PostgreSQL operator works quite reliably).

A common pattern in microservices architecture is that each service has its own database: that's what the person is referring to.

Well, I'm of the same opinion as the guy that wrote this short piece in 2018:

https://oprearocks.medium.com/blasphemy-multiple-microservic...

Insisting on always having a separate db for each service is not a pattern, it's pure madness.

Re: Microservices are hard

#255

Post by JAlexoid »

waselighis wrote: post #130

All of these articles against microservices are so annoying because I rarely see a good argument against microservices. Often the arguments are purely anecdotal and without substance. There are only two good arguments I can make against microservices. First, it's not the right architecture choice for all projects. Second, microservices don't magically solve the problem of complexity. But I can name countless benefits…

The argument against microservices is simple - there should be a clear use case for a microservice. Don't go - "we do everything as a microservice". Almost 20 years ago we had "we do everything using SOA"... Same thing.

And your own comment shows that microservice advocacy are inconsistent:

> Individual microservices are far less complex than monoliths, which allows even a single developer to work on a microservice, run and test it on their local machine

> database system can be considered a microservice, and that's hardly simple or tiny

DBMS is as much a microservice, as many other microservices are. You cannot just replace a DBMS with another transparently, just like in many cases you cannot just deploy a different version of a microservice without coordination.

Re: Microservices are hard

#256

Post by [deleted] »

amelius wrote: post #11

Linux distributions are essentially a bunch of microservices running together (managed by e.g. systemd). It works well most of the time, of course until it doesn't. Not sure what a better approach would be, though.

[deleted]

Re: Microservices are hard

#257

Post by JAlexoid »

bobleeswagger wrote: post #122

If your microservices are hard to test you've designed shitty microservices. Period.

You microservice can be easily tested.

But then you may end up with - is your whole system testable and how do you do good integration tests?

Right now I work in a pure microservice architecture, where there are no proper system or integration tests. And we had minor bug fixes break things spectacularly.

Re: Microservices are hard

#258

Post by throwaway9870 »

JAlexoid wrote: post #87
throwaway9870 wrote: post #48

Earlier quoted context omitted.

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…

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.

Re: Microservices are hard

#259

Post by JAlexoid »

sisve wrote: post #158

I really do not understand the debate on monoliths and microservice anymore. Context matters so much. Should you have absolutely everything in 1 system. No. And I think no one thinks that anymore. Should you spilt your system into as many pieces as possible? No, of course not. You are prop. storing files one place and have a data in a database another place. And most likely none are on the webserver receiving request…

> Should you have absolutely everything in 1 system.

Yes, you should build your system initially like that. One team builds one system and splits it out as necessary.

Re: Microservices are hard

#260

Post by philote »

gen220 wrote: post #162
photonbeam wrote: post #58

Earlier quoted context omitted.

You’d have to force everybody to use only one or two languages. For a time at Uber the direction was go/java only

I worked for a company that did microservices well, and this was the norm, too. The term in my head is "golden path" or "sandbox". The languages were Go and Python, speaking protobufs over gRPC. Developing software outside that sandbox was not disallowed, but you were "on your own" in terms of infra support if you chose to do so. FWIW, the main "tricks" we found were (1) using a good build tool (2) use a good ci/cd t…

Just curious, why is using a monorepo a useful trick? I would think it'd be better to have internal libraries that provide common functionality across services, and have a repo for each service. Otherwise, you're deploying code changes for one service that could, in theory, mess with another service that you don't maintain.
Post reply on HN