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

Goodbye Microservices: From 100s of problem children to 1 superstar

segment.com

Post reply on HN
Print view View original

91–100 of 782 posts

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#91

Post by jrs95 »

scarface74 wrote: post #81
ivan_gammel wrote: post #70

Earlier quoted context omitted.

Not really. For example, it's easier to mock a microservice, than a module, for testing purposes. Let's say you have component A and component B, A depends on B (dependency implemented via runtime sync or async call), B is computationally intensive or has certain requirements on resources that make it harder or impossible to test on developer's machine. You may want to test only A: with monolithic architecture you'll…

Mocking modules for unit testing has been a solved problem for decades in almost every language.

And running an integration test on a single modular application is easy. Doing it for a distributed system is very hard.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#92

Post by nickthemagicman »

tracer4201 wrote: post #29

Too many smart folks that I've worked with, for some reason, just stop thinking critically when it comes to certain ideas. I was a product manager on a team of really rockstar developers. They all earn at least $200k a year. Instead of demanding more ambitious projects, you could keep about 99% of them happy by just letting them use the new framework of the week to build their next web app. Their excitement when they…

It's highly possible that you..the project manager..were the one who was ill in-formed when it came to the technology aspect of why 200k per year developers were excited by React.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#93

Post by scarface74 »

I don’t see any reason you shouldn’t always design a system as domain specific micro services.

Now those micro services shouldn’t always be out of process modules that communicate over HTTP/queues, etc. A microservice can just as easily be separately compiled modules within a monolithic solution with different namespaces, public versus private classes, and communicate with each other in process.

Then if you see that you need to share a “service” across teams/projects, or a module needs to be separately, deployed, scaled, it’s quite easy to separate out the service into versioned packages or a separate out of process service.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#94

Post by jrs95 »

Q6T46nT668w6i3m wrote: post #89
thermodynthrway wrote: post #3

I've always said if the Linux kernel can be a giant monolith, in C no less, than there's maybe 100 web applications in the world that need to be split into multiple services. I've worked with microservices a lot. It's a never-ending nightmare. You push data consistency concerns out of the database and between service boundaries. Fanning out one big service in parallel with a matching scalable DB is by far the most sa…

Linux isn’t a giant monolith! Linux is composed of subsystems with independent maintainers.

Yes, but "monolithic" web applications can be built in the same way. It might not be a 100% accurate usage of the term, but microservice/SOA advocates love to call modular applications monliths anyways, to the point that it's something that most people seem to do.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#95

Post by thinkmassive »

wilde wrote: post #37
dualogy wrote: post #17

Earlier quoted context omitted.

"Need to" and "sane" are among my favourite subjective terms! (Further below, I'll go into in which contexts I'd agree with your assessment and why. But for now the other side of the coin.) In the real world, current-day, why do many enterprises and IT departments and SME shops go for µservice designs, even though they're not multimillion-user-scale? Not for Google/Netflix/Facebook scale, not (primarily/openly) for h…

In my experience if your developers were going to make choices that lead to tight coupling in a monolith, they’re going to make the same choices in a distributed architecture. Only now you’ve injected a bunch of network faults and latency that wouldn’t have been there otherwise.

In this case it sounds like they started with a microservice architecture, but CI/CD automation necessary for robust testing and auto-scaling was not in place. The problem of queues getting backed up might have been addressed by adding a circuit breaker, but instead they chose to introduce shared libraries (again, without necessary testing and deployment), which resulted in very tight coupling of the so-called microservices.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#96

Post by matwood »

jacquesm wrote: post #36

100's of problem children sounds like a step too far. A few services > monolith monolith > 100's of services. The big trick with any technology is to apply it properly rather than dogmatically and if you are breaking up your monolith into a 100's(!) of microservices you are clearly not in control of your domain. That's a spaghetti of processes and connections between them rather than a spaghetti of code. Just as bad,…

Great point. I like separate services, but would cringe at 100s of services in any system I have seen.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#97

Post by briandear »

scarface74 wrote: post #80
mockingbirdy wrote: post #51

Earlier quoted context omitted.

I think he doesn't have a problem with that. > Building another dumb website with the new framework, yay. He's just astonished how excited they are although what they build is "another dumb website" in his opinion. Many developers love the "how?" and don't care about the "why?". I don't judge it, but it can explain some of the excitement. Angular, React and Vue are great for development. But Ember, Backbone and other…

The reality is that since the days of the social contract between employer and employee are long gone - i.e. I show a company loyalty and they will keep me at least at market rates and not lay me off to “increase shareholder value. Developers have to use the new and shiny to keep themselves marketable and be ready to jump ship at the first opportunity or out of necessity.

How frequently are developers being laid off? And why should companies just keep people around if they aren’t adding value? The lack of that “social contract” has resulted in much higher wages. Look at developer salaries in Paris compared to New York. Since there is more job security in France, the trade off is that “market rates” are dramatically lower.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#98

Post by thermodynthrway »

NickBusey wrote: post #72
thermodynthrway wrote: post #3

I've always said if the Linux kernel can be a giant monolith, in C no less, than there's maybe 100 web applications in the world that need to be split into multiple services. I've worked with microservices a lot. It's a never-ending nightmare. You push data consistency concerns out of the database and between service boundaries. Fanning out one big service in parallel with a matching scalable DB is by far the most sa…

Right, but the thing that makes Linux actually useful isn't really the kernel is it? I would say what makes it useful is all the various small, targeted programs (some might call them microservices) it lets you interact with to solve real world problems. If Linux tried to be an entire computing system all in one code base, (sed, vim, grep, top, etc., etc.) what do you think that would look like code base/maintainabil…

With web apps the main concern is data consistency between relations. On the OS level you have these same concerns with memory and disk, and there's database-like systems in the kernel and drivers to handle it. Essentially all these utilities are running within the same "database" which is disk and memory management handled by the kernel. Usually microservices have their own databases, which is where consistency hell begins

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#99

Post by xj9 »

topicseed wrote: post #10

I think that with the rise in popularity of functions as a service (lambda, gcf, azure), we are heading more and more towards nanoservices. Small services are easier to develop with several teams, in my opinion. Each team knows what to input, and output. They can do whatever in between as long as these two contracts are respected. But the overlooking of all these moving pieces changing at different paces is tough. An…

> Reusable Reproducible Composable Software

https://github.com/fractalide/fractalide/

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#100

Post by sbov »

cortesoft wrote: post #55
the_arun wrote: post #30

Micro Services solve for logical smaller teams, speed, deployment isolation & ton of other problems. Every solution comes with a trade off. There is no perfect solution. It is up to us to decide whether we need a monolith or micro service for our need & use case instead of comparing them.

Not only that, but there is a lot of room between a 'monolith' and 'micro services'. How about medium services? You break somethings up and leave other things combined.

Some people call this... microservices! Common advice is that a microservice should align with a bounded context in domain driven design, which can involve a LOT of code.

Many large companies have millions of LOC behind their microservices. Your average startup probably doesn't.

Post reply on HN