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

411–420 of 782 posts

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

#411

Post by tabtab »

wmccullough wrote: post #388
deanCommie wrote: post #367

Earlier quoted context omitted.

You missed a crucial detail: > * Everyone slowly goes back to the old technology, forgetting the new technology. This step is just as misguided as cult-y as "Everyone adopts this new technology and raves about how great it is now that they have just adopted it." In some cases the technology WAS the right idea, just implemented incorrectly or not sufficiently broadly, and the baby ends up getting thrown out with the b…

I agree completely. I think that regardless of whether microservices works for anyone or not, they came about to address a real issue that we still have, but that I’m not sure anyone has fully solved. I think that microservices are an expression of us trying to get to a solution that enables loose coupling, hard isolation of compute based on categorical functions. We wanted a way to keep Bob from the other team from…

The problem is it's not clear when to use what. Some get confused and use it in the wrong place. Here are some questions to ask before you use microservices.

Does the service need an independent and dedicated team to manage its complexities, or is it a "part time" job? Try a Stored Procedure first if its the second.

Is the existing organization structure (command hierarchy) prepared and ready for a dedicated service? (Conway's law) Remember, sharing a service introduces a dependency between all service users. Sharing ain't free.

Do you really have a scalability problem, or have you just not bothered to tune existing processes and queries? Don't scrap a car just because it has a flat tire.

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

#412

Post by filleduchaos »

SahAssar wrote: post #384
filleduchaos wrote: post #229

Earlier quoted context omitted.

That sounds like a rather narrow definition of science that will become even more obsolete in the years to come. With how far mankind has come, it's a little silly to think that "natural" systems will remain the only things that science is concerned with.

I think that their point is that "Computer Science" does not seem very very interested in the provability of their science (the "Science" part) nor the applicability for general purpose computing (the "Computer" part).

> "Computer Science" does not seem very very interested in the provability of their science

...uh, what computer science are you talking about? Formal verification is a huge part of CS, and provability is a tiny part of what makes science science - systematic study through observation and experimentation. Science is a discipline, not in itself a fact to be proved.

Also, what parts of CS do you think are inapplicable to general purpose computing?

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

#413

Post by jashmatthews »

philwelch wrote: post #297
copperx wrote: post #187

Earlier quoted context omitted.

I can't find the right place for Ruby on Rails here. It doesn't fit.

After Rails burned through the hype cycle, its entire niche had disappeared. The skinny-jeans hipsters had moved on to single page apps and Node.JS and the "let's try and use Rails to write backend services" crowd had dispersed to a variety of better technologies.

That might be how it seems if you hang around on HN but activity in the Ruby and Rails communities is still increasing. New conferences, new implementations, and thousands of new developers.

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

#414

Post by ericdykstra »

StavrosK wrote: post #164

Let me write a meta technology hype roadmap, so we can place these sorts of articles: * Old technology is deemed by people too troublesome or restrictive. * They come up with a new technology that has great long-term disadvantages, but is either easy to get started with short-term, or plays to people's ego about long-term prospects. * Everyone adopts this new technology and raves about how great it is now that they h…

Hundreds of new languages, technologies, frameworks, etc pop up every year, but the odds of any one of them being durable in the long run is extremely low.

See: The Lindy effect https://en.wikipedia.org/wiki/Lindy_effect

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

#415

Post by exabrial »

The thing people failed to realize is that microservices are a way of structuring people in teams in an organization, not a way of structuring a product architecture.

To use words that are mine, microservices are a hack on Conway's law. One team should be responsible for 2-3 microservices and should have a lot of autonomy.

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

#416

Post by sciurus »

I like that they highlight the tradeoffs between isolating faults and optimizing resource utilization. However, you don't need microservices to achieve isolation. You can have different worker pools of the monolith configured to handle different destinations. The monolith actually gives you more flexibility in how you approach the tradeoff. With microservices you're forced into one pool of workers per destination, but with the monolith you can choose any mapping of pools to destinations that makes sense.

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

#417

Post by tluyben2 »

StavrosK wrote: post #164

Let me write a meta technology hype roadmap, so we can place these sorts of articles: * Old technology is deemed by people too troublesome or restrictive. * They come up with a new technology that has great long-term disadvantages, but is either easy to get started with short-term, or plays to people's ego about long-term prospects. * Everyone adopts this new technology and raves about how great it is now that they h…

I have been doing some tech advice jobs on the side to see what's going on in the world and it's really scary what I found. Only yesterday I was talking with the cto of a niche social networking company that has a handful of users and probably won't get much more who was telling me the tech they use; Node, Go, Rust, Mongo, Kafka, some graph db I forgot, Redis, Python, React, Graphql, Cassandra, Blockchain (for their voting mechanism...), some document database I had never heard of and a lot more. A massive, brittle, SLOW (!) bag of microservices and technologies tied together where in 'every micro part' they used best practices as dictated by the big winners (Facebook, Google, whatever) in Medium blogs. It was a freak show for a company of 10 engineers. But this is not the first time I encounter it; 3 weeks ago, on the other side of the world, I found a company with about the same 'stack'.

People really drink the koolaid that is written on these sites and it is extremely detrimental to their companies. PostgreSQL with a nice boring Java/.NET layer would blow this stuff out of the water performance wise (for their actual real life usecase), would be far easier to manage, deploy, find people for etc. I mean; using these stacks is good for my wallet as advisor, but I have no clue why people do it when they are not even close to 1/100000th of Facebook.

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

#418

Post by tabtab »

nevir wrote: post #304
chrisco255 wrote: post #275

Earlier quoted context omitted.

There's nothing declarative about HTML except for its extremely limited use case of rendering text.

HTML is purely declarative. Each HTML document describes what it wants to have rendered, but does not describe how it should be rendered.

In theory, maybe. In practice, no. I've been round and round on ADA issues, and there is no clear distinction between "meaning" and "presentation". Clean separation is either a pipe dream, or too complex for most mortals to get right. I should become an ADA lawyer because I can now pop the purists' BS and win case$.

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

#419

Post by wsy »

ljw1001 wrote: post #399
wsy wrote: post #378

Earlier quoted context omitted.

It's exactly the other way around: If you can afford all your components sharing the same database without creating a big dependency hell, then your problem is _too small_ for microservices. If your problem is so large that you have to split it up to manage its complexity, start considering microservices (it might still not be the right option for you).

like all those simple airline reservation and banking systems?

Yes, they do fine as examples. I have worked both on decades old booking systems and banking software. Both were dependency hells. Refactoring was impossible. Everybody was super-careful even with tiny changes because the risk to break something was just too high.

If it could be avoided, these systems were not touched anymore. Instead, other applications where attached to the front and sides.

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

#420

Post by scarface74 »

ivan_gammel wrote: post #385
scarface74 wrote: post #158

Earlier quoted context omitted.

It’s basically a feature flag. I don’t like feature flags but it is a thing. But if you are testing an artifact, why isn’t the artifact testing part of your CI process? What you want to do is no more or less an anti pattern than swapping out mock services to test a microservice. I’m assuming the use of a service discovery tool to determine what gets run. Either way, you could screw it up by it being misconfigured.

First of all it is the test code, no matter whether it's implemented as a feature flag or in any other way. Test code and test data shall not be mixed with the production one for many well-documented and well-known reasons: security, additional points of failure, additional memory requirements, impact on architecture etc. >But if you are testing an artifact, why isn’t the artifact testing part of your CI process? It…

What exactly are you trying to accomplish?

If you are testing a single microservice and don’t want to test the dependent microservice - if you are trying to do a unit test and not an integration test, you are going to run against mock services.

If you are testing a monolith you are going to create separate test assemblies/modules that call your subject under test with mock dependencies.

They are both going to be part of your CI process then and either way you aren’t going to publish the artifacts until the tests pass.

Your deployment pipeline either way would be some type of deployment pipeline with some combination of manual and automated approvals with the same artifacts.

The whole discussion about which is easier is moot.

Edit: I just realized why this conversation is going sideways. Your initial assumptions were incorrect.

you may want to test only A: with monolithic architecture you'll have to produce another build of the application, that contains mock of B (or you need something like OSGi for runtime module discovery).

That’s not how modern testing is done.

https://www.developerhandbook.com/unit-testing/writing-unit-...

Post reply on HN