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

The costs of microservices (2020)

robertovitillo.com

Post reply on HN
Print view View original

371–380 of 410 posts

Re: The costs of microservices (2020)

#371

Post by pjmlp »

lmm wrote: post #301
slowmovintarget wrote: post #221

Earlier quoted context omitted.

OSGi and Java Modules would like a word. Too few developers use the facilities available for that kind of in-process isolation, even when it is possible. (Don't tell me Java isn't popular... It may be the new COBOL, but it's still mainstream.)

> OSGi and Java Modules would like a word. OSGi is the one that's deprecated and Java Modules is the one that can't actually provide that functionality yet, right? Or is it the other way round? Either way you get the point.

Java modules are doing alright since Java 9, are the foundation for Java's linker and code stripping on AOT, while Eclipse keeps using OSGi just fine.

Re: The costs of microservices (2020)

#372

Post by ljm »

tsss wrote: post #367
jocaal wrote: post #248

Earlier quoted context omitted.

> If you do so much IPC that you have to design your language around it you're probably doing it wrong... I'm gonna have to disagree with this. Often when languages add features to their core, it allows for a very different (and often better) approach to writing code. Think Lisp with first class functions, or Rust with the borrow checker. Why should concurrency be any different? This feels like a Blub moment and I wo…

If you need that much IPC then you aren't doing microservices correctly. Microservices are supposed to be independent, self-contained domains wherever possible. Purely technical boundaries like dedicated caching services that you see in very large companies like Google are more of an exception and should only be used when the non-functional requirements absolutely dictate it. A language that is designed around IPC wa…

The theory is that microservices are supposed to be independent and self-contained, but such a wonderful implementation of DDD is a theoretical fantasy that rarely plays out in practice. It's not just a technical difficulty but an organisational problem where communication between teams also throws a spanner in the works.

If your typical microservice setup is simply distributing your call stack over a network (and oftentimes that's all it is), then you might as well use a language designed to operate in such a manner and reap the benefits of it. That kind of microservice architecture only really exists as a function of the organisation's structure such that teams can work more autonomously.

Re: The costs of microservices (2020)

#373

Post by sgarland »

marcus_holmes wrote: post #359
renegade-otter wrote: post #321

Earlier quoted context omitted.

These are almost never pragmatic decisions. Giving teams independence over the stack usually results in resume-driven development, and now your JS developers are forced to maintain a Go server because some jock thought it was a cool thing to do . Due diligence in these cases is rare.

I've seen this play out for reals at a place a few years ago. Every team used a different tech, and all of them selected because of resume-driven development. People moving teams to get a particular tech on their resume. No common method for deployment, and endless issues getting things deployed. Everyone's a newbie because we were all learning a new, cool, stack. And everyone making stupid newbie mistakes. Never aga…

The worst part about this type of org (speaking as an SRE / DBRE) is that they also don’t do SRE correctly, so these piles of shit get yeeted into prod, fall apart, and then the already over-burdened SREs and DBREs have to figure out how it works so they can fix it.

I didn’t know how to troubleshoot Node, but I did know how to read docs. Suddenly I can troubleshoot Node. Hooray.

I concur with your sentiment, and would also be an absolute dictator for tech stack and workload management. We’re not using Node, we’re avoiding React if at all possible, every dev touching the DB in any way will know SQL, and no one is using Scrum.

Re: The costs of microservices (2020)

#374

Post by devjab »

jabradoodle wrote: post #351
devjab wrote: post #347

Earlier quoted context omitted.

It depends on how you do it. We have 5 engineers and around 50 services and it’s much easier for us to maintain that than it was when it was monolith with a couple of services on top. Though to understand why this is, you would have to know just how poorly our monolith was designed. That’s sometimes the issue with monoliths though, they allow you to “cut corners” and suddenly you end up with this huge spiderweb mess…

> designed. That’s sometimes the issue with monoliths though, they allow you to “cut corners” I find this hard to relate to, the idea you have the discipline and culture to do microservices well if you can't do it with a monolith. More likely is you migrate away from the monolith you never invested in fixing, and once you get to microservices you either call it a mistake and migrate back, or you have to eventually fi…

With the microservice architecture it’s easier to lock things down. You can’t have someone outside of your team just give access to a dataset or similar because excel can’t get a connection directly into your DB. Which is an argument you could rightfully make for monoliths, except in my experience, someone always finds a sneaky way into the data on monoliths, but it’s too hard for them to do so with MicroServices.

If you gave me total control over everything, I’d probably build a couple of monoliths with some shared modules. But every time the data is centralised, it always somehow ends up being a total mess. With MicroServices you’ll still end up with a total mess in parts of the organisation, but at least it’ll be in something like PowerBI or even your datawarehouse and not directly in your master data.

Or to put it differently, for me MicroServices vs monoliths is all most completely an organisational question and not a technical one.

Re: The costs of microservices (2020)

#375

Post by LelouBil »

charcircuit wrote: post #311
LelouBil wrote: post #295

Earlier quoted context omitted.

With microservices, you can also version them independently. In a monolith you can't roll back "a part" of the app to the latest version if you pushed multiple unrelated features at once.

> a monolith you can't roll back "a part" of the app to the latest version if you pushed multiple unrelated features at once. git revert

Well yes, but if you used a compiled language you have to make a new release based on this commit.

What I mean is, if you have v2 of your software that introduces a bugfix for module A that's perfectly fine and a bugfix for module B that breaks everything, you can just roll back just module B directly with your deployment pipeline.

There's no need to go back to the code base and make a new release.

Re: The costs of microservices (2020)

#376

Post by collyw »

alrs wrote: post #344
shados wrote: post #342

Earlier quoted context omitted.

It's a pretty common issue. If you have 2-3 services, it's pretty easy to manage. And if you have 1000, you likely have the infra to manage them and get the full benefit. But if you have 20 engineers and 60 services, you're likely in a world of pain. That's not microservices, it's distributed monolith and it's the one model that doesn't work (but everyone seems to do)

A "microservice" solves scaling issues for huge companies. If you have 60 microservices, you should probably have 600 engineers (10 per) to deal with them. If you're completely underwater and have 10 services per engineer, you're 100% absolutely play-acting "web-scale" for an audience of really dumb managers/investors.

I ended up getting into a few arguments at work with the over excited engineer in my last place. He wanted microservices. I said it was just going to add complexity. The app was already a mess, adding network calls rather than function calls wasn't going to help. We had a small teas - 3 backend devs, one of them doing mostly devops and two frontend.

Re: The costs of microservices (2020)

#377

Post by collyw »

gedy wrote: post #147
eduction wrote: post #89

Earlier quoted context omitted.

Wouldn't this just be "having one or two services"? I don't think that's the same as "microservices". Correct me if I'm wrong, but isn't "microservices" when you make internal components into services by default , instead of defaulting to making a library or class?

For some reason, most of the people I've worked with recently are either fully into monoliths or lots of fine grained, interdependent microservices. They don't seem to understand there's a useful middleground of adding fewer, larger data services, etc. It's like SOA isn't a hot topic so people aren't aware of it.

Start with a monolith and scale out the parts as needed.

Re: The costs of microservices (2020)

#378

Post by sanderjd »

BHSPitMonkey wrote: post #299
sanderjd wrote: post #296

Earlier quoted context omitted.

> you just need to know each juncture where that strand weaves into other strands. No I don't, that's what computers are for. It's why static analysis is good. Instead of knowing what calls what, you say, "yo, static analysis tool, what calls this?".

The comment you quoted is talking about the non-monolithic situations where static analysis tools cannot help you, e.g. when the callers are external and difficult to trace.

I don't think so? The full quote that I pulled out a piece of was:

> The monolith crowd claims it's easier to change/rewrite code in a monolith because it's all one big pile of yarn and if you want to change out one strand of it, you just need to know each juncture where that strand weaves into other strands.

I'm saying, in the monolith situation, with proper static analysis tooling - which even languages like python and ruby have nowadays - you don't "need to know" how all the strands weave into the other strands, you rely on the tooling to know for you.

And in my experience, static analysis tooling for navigating across service boundaries is, at the very least, far less mature, if not just entirely non-existent.

Re: The costs of microservices (2020)

#379

Post by collyw »

eterevsky wrote: post #58
lr4444lr wrote: post #27

Don't disagree with the article, but to play Devil's Advocate, here are some examples of when IME the cost IS worth it: 1) there are old 3rd party dependency incompatibilities that you can spin off and let live separately instead of doing a painful refactor, rebuilding in house, or kludgy gluing 2) there are deploy limitations on mission critical high available systems that should not hold up other systems deployment…

1) Why is it better than wrapping it in an interface with a clear API without extracting it into a separate service?

More moving part. A network call can fail in more ways than a function call. Also something no one has mentioned until now, the more "services" you have the more of a pain in the arse it is to get a development environment running.

Re: The costs of microservices (2020)

#380

Post by collyw »

insanitybit wrote: post #38
jihadjihad wrote: post #2

Microservices grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug https://grugbrain.dev/#grug-on-microservices

Network calls are a powerful thing to introduce. It means that you have an impassable boundary, one that is actually physically enforced - your two services have to treat each other as if they are isolated. Isolation is not anything to scoff at, it's one of the most powerful features you can encode into your software. Isolation can improve performance, it can create fault boundaries, it can provide security boundarie…

It's also something else that breaks. A lot more than function calls.
Post reply on HN