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

Some thoughts on microservices

filipnikolovski.com

Post reply on HN
Print view View original

131–139 of 139 posts

Re: Some thoughts on microservices

#131

Post by acjohnson55 »

mumblemumble wrote: post #47
amelius wrote: post #46

Earlier quoted context omitted.

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.

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

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.

Re: Some thoughts on microservices

#132

Post by kakoni »

"microservices is a psyop by big tech to make deploying & maintaining software so insanely difficult that future potential competitors are too tied up trying to keep the cloud equivalent of "hello world" afloat to present any real threat"

https://twitter.com/htmx_org/status/1462636513578135556

Re: Some thoughts on microservices

#133

Post by ratww »

foobarian wrote: post #129
ratww wrote: post #126

Earlier quoted context omitted.

> That's maybe a bit unfair. There are a lot of microservice shops, but I haven't heard many who do this Franken-monolith thing. Remember that infamous microservice dependency graph from Uber? I guess Facebook was famous for doing a monolith but I don't know if it was purely PHP or not. Your original example was that you "needed to let a remote team add some functionality to my, say, Spring backend but they really pr…

> You don't get to change the constraints ("I already know how to setup X") after an answer just to say the answer is wrong/worse and expect not to be called out on it... I don't see it as being called out, it's a constructive discussion. The purpose of my example is to see how practical it would be for me to set up a monolith-based CI/CD that could support multi-lingual, multi-repo teams. I have a better idea now, m…

Publishing to Maven definitely works.

Updating SQL drivers, etc, is not trivial because you don't have control over the code, but if you have enough integration tests (or at least proper failure handling) for your separate library then you can update with the same frequency as microservices.

I think it's fine to do this thought exercise, but you're massively discounting the difficulties of microservices, while making up obstacles and mocking ("Franken-monolith") every other suggestion. Any company that doesn't already use microservices (and doesn't also have people with experience building infrastructure for them, rather than just using) is gonna have a harder time with a microservice solution than you currently do. It is perfectly fine to extrapolate from your own experience, but you're discount things without any research whatsoever and saying "nobody knows about it" or "nobody uses it" in a very disrespectful way. Another post of this discussion about code ownership is exactly the same: it takes literally seconds to write a simple codeowners file in GitHub, while you make it seem like it would be an Sisyphean task ("an uphill battle") compared with microservices just because you're not aware of it. Some things are not hard, maybe you just didn't heard of them yet.

Re: Some thoughts on microservices

#134

Post by BerislavLopac »

belter wrote: post #15
cjfd wrote: post #3

One should probably not even think of microservices if one employs fewer than 100 programmers. In many cases microservices are introduced because of fashion and/or resume driven design not because it actually makes sense. I prefer refactoring a poorly structured monolith to refactoring poorly structured microservices in every case.

The whole problem starts with calling them microservices. Just call it a service oriented architecture please. The whole micro thing is already an indication of the kind of trouble you are getting yourself into. More respect to the monolith please.

My favourite phrase here is "distributed systems", and that includes any system with discreete components that communicate over a network internally (i.e. consuming a third-party API does not count; obviously there would always be some gray areas).

And yes, a simple SPA is a distributed system, even if the backend is a monolith.

Re: Some thoughts on microservices

#135

Post by BerislavLopac »

UglyToad wrote: post #52
belter wrote: post #15

Earlier quoted context omitted.

The whole problem starts with calling them microservices. Just call it a service oriented architecture please. The whole micro thing is already an indication of the kind of trouble you are getting yourself into. More respect to the monolith please.

I'm going to build a lucrative personal brand / consulting business by hyping mesoservices, neither micro nor macro, just right.

Also known as "Goldilocks services". ;)

Re: Some thoughts on microservices

#136

Post by p_l »

bsder wrote: post #115
acjohnson55 wrote: post #24

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

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

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)

Re: Some thoughts on microservices

#137

Post by jjav »

FinanceAnon wrote: post #14

Fundamentally, I don't really see much difference between monoliths and microservices. In a monolith, you just call another function/class, but in microservices that function is a http call. I guess the benefit of microservices is the ability to independently scale different microservices, being able to choose different languages for different microservices and less conflicts in the repo as more people work on it, bu…

> Fundamentally, I don't really see much difference between monoliths and microservices.

> In a monolith, you just call another function/class, but in microservices that function is a http call.

That right there is the fundamental difference.

For one thing, calling a function in the same process is going to be orders of magnitude faster than a network connection call and all that it entails. Even if performance doesn't matter at all in some use case, it's also additional cost to be running all these additional instances.

And then, complexity went up since a network call can fail in all kinds of additional ways that a jump to a function address in the local process cannot. So the code has to deal with all those. The complexity of correlating your logs and diagnostics also just went up. Your deployment automation and versioning complexity also now went up.

All these are solvable problems, of course. It just takes more people, time and budget. If the company is large enough sometimes it's worth it for the dev team decoupling aspects. If the company is tiny, it's approximately never worth taking on all this extra work and cost.

Re: Some thoughts on microservices

#138

Post by choeger »

clintonb wrote: post #104
choeger wrote: post #80

If I was CTO of a company, microservices would give me nightmares. How do you do due diligence on used free software (licenses and security updates)? How do you plan the resource usage of your whole setup if every developer can add a new autoscaling service? Who is actually keeping track on deployments so we don't accidentally overload the system? How do you refactor a cross-service feature consistently? And the wors…

> How do you do due diligence on used free software (licenses and security updates)? Use the same process you would use if you had a monolith. The rest of your issues can be solved by planning out your services, rather than giving everyone free reign to make a new service. Switching to services doesn't magically mean your teams stop talking and designing together.

Yeah and the inter-service specification lives where? How is it monitored, tested, enforced?

I have the feeling that with the (quite possible!) addition of an inter-service codebase we would end up with a distributed monolith, i.e., a program that doesn't target a single computer but a particular substrate. I don't know whether that's a good design, though.

Benefits: The program becomes more transparent and resilient to nonfunctional problems. It is also much easier to replace parts of the program. Downsides: Executing on a developer's workstation (critical for productivity and quality, IMO) might become harder. Efficiency gets reduced by orders of magnitude in certain spots.

Re: Some thoughts on microservices

#139

Post by papito »

afarrell wrote: post #118
papito wrote: post #86

Earlier quoted context omitted.

How many startups out there have run into the problem of "oh no, we got too big too fast"?

A fraction of the ones that are successful. I suppose what I really mean is: If your leadership subordinates (especially new joiners) are starting to struggle to coordinate, consider the possibility that you might already be at that point yet emotionally attached to the notion of staying small as you double or quadruple in population.

I can guarantee you that most systems out there could serve production traffic on an old laptop, with well-written code and lean database queries. I have done things in MySQL v3 in 2006 that should not be done with a modern database even today (a taxonomy search engine 3 levels deep. Never again).

In the age when database trips and network trips are treated as "free", we somehow arrived at MORE complicated solutions, like microservices.

A "hello, world" problem in 99% of the cases is a "hello, world" problem. At Google - it is not. It's a scale problem. Everything is a scale problem at Google first, and a business logic problem second. The FAANG alumni has convinced the new generation of developers that everything is a scale problem.

Post reply on HN