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

151–160 of 782 posts

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

#151

Post by ivan_gammel »

scarface74 wrote: post #142
ivan_gammel wrote: post #137

Earlier quoted context omitted.

Mocking modules for unit testing - yes. Testing the specific build artifact with a module replaced by a mock - no, it is not.

A dependency injection framework where you use flags at the composition root to determine whether the “real” implementation class or the mock class is used based on the environment. IOrderService -> OrderService in production. IOrderService ->FakeOrderService when testing.

Do you realize that this is actually an anti-pattern, that adds unnecessary complexity and potential security problems to your app? Test code must be separated from production code - something, that should know every developer.

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

#152

Post by adrianmsmith »

aniketpant wrote: post #54

I probably don't understand their architecture well enough since they don't try and explain it in detail. The blame is also put on microservices whereas it's the architecture that can be fixed to improve performance and the cost of deployment. A shared library works up until a certain point. If every service uses a shared library then you are already getting to a world of a monorepo. A monorepo for different services…

Surely this is "no true scotsman"? They've tried microservices and it didn't work for them, you're saying that if only they'd "fixed" their micro-services architecture it would have worked?

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

#153

Post by hosh »

stickfigure wrote: post #40
davidkellis wrote: post #5

Earlier quoted context omitted.

> You push data consistency concerns out of the database and between service boundaries. Sing that from the rooftops. That is exactly my observation as well. All the vanilla "track some resource"-style webapps I've worked on were never designed to cope with a consistency boundary that spans across service boundaries. Turning a monolith into distributed services is hard for that reason - you have to redesign your data…

It's worse than that; it's my observation that most microservice architectures just ignore consistency altogether ("we don't need no stinking transactions!") and blindly follow the happy path. I've never quite understood why people think that taking software modules and separating them by a slow, unreliable network connection with tedious hand-wired REST processing should somehow make an architecture better. I think…

Sometimes, I've seen a lack of regard for data consistency within a monolith.

That is not completely on the developer, either. Pre 4.0 Mongodb, for example, does not do transactions. On the other hand, I've seen some pretty flagrant disregard for it just because there are not atomicity guarantees.

Microservices makes reasoning on that harder.

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

#154

Post by trhway »

>The first item on the list was to consolidate the now over 140 services into a single service.

software engineering walks in circles. NoSQL people seem to be growing up and learning about consistency and transactionality. I'm waiting for somebody to discover threads and shared variables back as a revolutionary way to improve performance and greatly simplify the implementation of a system of "actors".

Joking aside, i think greatest reason for Segment's microservices failure was that they didn't use Kubernetes.

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

#155

Post by paxys »

blablabla123 wrote: post #106
NickBusey wrote: post #72

Earlier quoted context omitted.

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…

But there is a big difference. These small targeted programs are invoked in user land, usually by the user. Microservices get invoked directly by the user when debugging is going on. Otherwise they are expected to automagically talk to each other and depending on the abstraction even discovery each other automatically. Also I can pipe these tools together from the same terminal session, like tail -f foo | grep someth…

Look at the package dependency tree of an average linux program. They are absolutely examples of "microservices" talking to each other.

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

#156

Post by cloverich »

nickthemagicman wrote: post #127
hinkley wrote: post #42

Earlier quoted context omitted.

People look at microservices as a solution to the Big Ball of Mud, and then confuse "a solution" with "the solution". You really do have to modularize. In some languages, you can even use separate compilation units for separate modules to enforce the separation. You can do all of that but get simultaneous deployment, which cuts out whole classes of integration nightmares.

It seems like a Big Ball of mud is much more difficult to deal with than a bunch of small balls of mud just in general?

It depends but in general I'd disagree. If the small balls of mud have all kinds of implicit dependencies, but you have to find them by searching across codebases (and languages) -- does that sound easier than finding them all in the same codebase and language? Overall, its comparing bad design to bad design. I think the main argument I'd make here is, micro-services doesn't actually solve the big ball of mud problem, it solves a completely different problem.

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

#157

Post by ljm »

acroback wrote: post #123

This is a classic case of not understanding micro services and trying to fit a problem around a tool. At work, we have close to ~50 services(no one calls them microservices), but they do not suffer from this brittleness. We segregate our services based on languages. So, all C services go under coco/ , all Java services go under jumanji/ , all go services go under goat/ , all JS services go under js/. This means, ever…

I'd wager that microservices, a lot of the time, are basically used as a management structure rather than for their benefits as pure tech, so less mature teams can silo themselves off and avoid communication (e.g. "I can work just on my backend image processing bit without dealing with the React guys now", "now the CTO won't be on my back so much," or whatever).

The irony being that anything approaching SOA (or microservices) requires exactly the same amount of communication. More likely they require more since it's almost certain that such a decision introduced chaos.

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

#158

Post by scarface74 »

ivan_gammel wrote: post #151
scarface74 wrote: post #142

Earlier quoted context omitted.

A dependency injection framework where you use flags at the composition root to determine whether the “real” implementation class or the mock class is used based on the environment. IOrderService -> OrderService in production. IOrderService ->FakeOrderService when testing.

Do you realize that this is actually an anti-pattern, that adds unnecessary complexity and potential security problems to your app? Test code must be separated from production code - something, that should know every developer.

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.

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

#159

Post by thelastidiot »

acroback wrote: post #123

This is a classic case of not understanding micro services and trying to fit a problem around a tool. At work, we have close to ~50 services(no one calls them microservices), but they do not suffer from this brittleness. We segregate our services based on languages. So, all C services go under coco/ , all Java services go under jumanji/ , all go services go under goat/ , all JS services go under js/. This means, ever…

Amen to that. Just by curiosity, what is the barrier of entry for adding a new language in your ecosystem?

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

#160

Post by teilo »

One of the things that I like about the Erlang/OTP ecosystem is that it encourages you to design systems that are very modular, but does not force you to run every service as an independent entity. By designing around supervision trees of dependent services, one gains the advantages of a monolithic environment without losing the ability to split services out onto discrete nodes.

But that's an "all in" environment. You are Elixir/Erlang/OTP, or you are out. That is, understandably, not an option for many use cases.

Post reply on HN