[acjohnson55]

Microservices are not a solution, they're a capability. It's powerful for a team to be able to deploy a tiny service with the absolute minimum amount of explicit plumbing to meet operational requirements. Whether they should break their system up this way is a case by case judgment.

Every place I've been, the costs of microservices get overlooked in favor of the illusion of decoupling. Microservices will absolutely make simple features fully contained within a service easier, but as soon as a feature spans services or even impacts the contract of a service, you're in for more pain than in a monolithic architecture. Microservices sieze local simplicity at the cost of integration complexity.

Microservices, as a philosophy, is encoding your org design at the networking layer. I hope you get it the factoring right the first time, because it's going to be painful to change.

I'm all for small services where they make sense. But just like the advice that "all functions should be small" microservices has been myopically adopted as a design principle, rather than a debatable decision.

[satyrnein]

At a previous company. I had a team that chose to rebuild a feature from the monolith as a microservice to "contain" the complexity. They built the service off to the side, had automated tests validating its inputs and outputs, and they were quite proud of it. Then came integration, and it became clear they had not put any thought into how to migrate the data, what would happen if the service was unavailable when the monolith called it, how to generate reports across the monolith and microservice, etc etc.

In this case, using microservices was like getting drunk: a way to briefly push all your problems out of your mind and just focus on what's in front of you. But your problems didn't really go away, and in fact you just made them worse.

[geodel]

Indeed. I did simple calculation for myself. We kind of split a service in 5 microservices. Now if I look at e.g 5% integration related issues between 2 services, which would obviously not exist in monolith, we are actually looking > 20% chances of error in an end-to-end transaction.

To me this is pretty high chance of error on day to day basis. And in our case some errors are convoluted, so possibly getting missed and causing slow data corruption.

[amelius]

Your first question in a job interview should be: "do you use microservices?" If the answer is yes, you can save yourself a lot of time.

[mumblemumble]

I know microservices have passed the excitement phase of the hype cycle, but they're not useless. One of the most enjoyable systems I've worked on was a microservice architecture.

That said, I'm going make some wild inferences about what you were getting at in ordet to say that I agree that a microservice architecture is probably a solution in search of a problem in most cases. And, even in the cases where it is a good option, I can see all sorts of ways to mess up the implementation. The article is right; the trickiest things to get right about microservices are actually organizational issues, not technical ones. My hot take is that dev teams who are considering adopting microservices should take a serious look at how much ability they have to influence the org chart and inter-team and inter-departmental communication. If management is strictly something that happens to them, I would not give them stellar odds of achieving sustainable success with microservices. Perhaps some other form of SOA, but not actual microservices.

[acjohnson55]

I wouldn't underrate the technical issues. To really make it work, you've gotta get the tooling right, so you're not writing and maintaining plumbing (logging, tracing, runtime config, networking, deployment, API layer, repository, etc etc) for every single microservice, all in their little bespoke ways. I once decommissioned a microservice after noting that the LoC of all its plumbing and config outweighed the actual logic 5:1. Pushing that plumbing to the background, so it can be managed as a cross-cutting concern, isn't so easy.

[taeric]

I'd be more worried with, "do you just have shared infrastructure for all data?"

Hearing some places just have one giant database where all teams can add and remove columns is... Kind of scary to me.

[pooper]

> Hearing some places just have one giant database where all teams can add and remove columns is... Kind of scary to me.

Are you talking about Bank of America? My impression from the interview was that it is not a free for all but rather all teams are equal but some teams are more "equal" than others (compliance). I still don't get why they need write/execute access. I would be OK with other teams having read access to my database.

There was a discussion the other day about using views as an external interface to a "service" so basically we maintain rest, gRPC, or whatever but if other teams just need read only access to our data, we can expose a view to them

https://news.ycombinator.com/item?id=29357874 https://web.archive.org/web/20211201192151/https://news.ycom...

[taeric]

Facebook is the one I've heard of.

[satyrnein]

Assuming people will need reports that cut across team/microservice boundaries, all that data has to end up in one common place, possibly a data warehouse. At which point, other teams can still add and remove columns and break your reports.

Is there another way to do things?

[taeric]

Well, a data warehouse is one thing. I have heard of them just having a single live database that everyone hits. For all uses.

Edit: in contrast, I don't want anything about a user, except their id in a table for most features. Hearing of free for all's on data makes me question how they protect payment or just general private data.

[momirlan]

If you bill by the hour, it could be a long, fruitful contract.

[bsder]

> Microservices, as a philosophy, is encoding your org design at the networking layer.

Not always. One of the things where I desperately wish people would adopt the "microservices philosophy" is in applications which provide a scripting language.

For example, if I want to "script" OpenOffice, I am stuck with the exact incarnation of Python shipped with OpenOffice. Nothing newer; nothing older; exactly binary compatible. This is a really irritating limitation.

If, however, they simply provided a "microservice interface" that anyone could talk to rather than just the anointed Python, then you could run your own Python or script using a completely different language.

I'm picking on OpenOffice here, but this is not specific to them. Nobody who has a "scripting extension language" as part of their application has demonstrated anything better.

[p_l]

That's how a lot of Windows stuff and MS Office stuff is built - as (D)COM components you can arbitrarily connect to from anything that can speak COM.

It's also how Windows Scripting Host operates (it also makes the language interpreters into COM objects, so you can extend the list of available languages yourself)

[remram]

What you're wishing for is usually called an API. It allows third-party applications to interface programmatically.

[vineyardmike]

> Microservices, as a philosophy, is encoding your org design at the networking layer

Def the best/worst reason to use it, but it does - practically - make sense. Anyone who has had cross-team-monoliths will welcome this.