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

711–720 of 782 posts

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

#711

Post by weberc2 »

staticassertion wrote: post #557
weberc2 wrote: post #550

Earlier quoted context omitted.

> no, it is still not an easy choice Yeah it is, choose 3. Python 2 is reaching EOL. > Mypy coverage, even in the stdlib, is awful. When it comes to thirdparty, mostly nonexistent. Mypy feels so young - I love the team, love their work, but I still run into cases where inference fails when it shouldn't, where error messages are extremely helpful, etc. Yeah, the typing stuff is a pretty big disappointment. The ergonom…

> Yeah it is, choose 3. Python 2 is reaching EOL. Easy to say. Tell that to Google and Dropbox - Guido has worked for both and they're on 2. Tell that to the companies that can't afford the creator of the language. 3 is not the easy choice. Anyways, maybe try nim? I've heard good things.

If you're building something new as the original phrasing implies, choosing 3 is easy. If you need to integrate with 2, then you're in a tougher spot.

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

#712

Post by weberc2 »

scrollaway wrote: post #560
weberc2 wrote: post #550

Earlier quoted context omitted.

> no, it is still not an easy choice Yeah it is, choose 3. Python 2 is reaching EOL. > Mypy coverage, even in the stdlib, is awful. When it comes to thirdparty, mostly nonexistent. Mypy feels so young - I love the team, love their work, but I still run into cases where inference fails when it shouldn't, where error messages are extremely helpful, etc. Yeah, the typing stuff is a pretty big disappointment. The ergonom…

Re your last paragraph, you're describing Lua. I don't know the state of its coroutines though as I've never used them.

I should have mentioned that "async coroutines" (i.e., goroutines) are also a requirement. Also, I understand that Lua doesn't have much of a standard library and isn't really used as a general purpose programming language (compared to Python, for example)?

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

#713

Post by piaste »

inetknght wrote: post #691
hinkley wrote: post #319

Earlier quoted context omitted.

I work on that project. Every time some idiot starts talking about 'code coverage' my face turns red. Our code coverage is 1e-10%. Don't talk to me about this 70% bullshit.

Said with less vitriol: It's not just code coverage that matters. It's the code path selection that matters. If you have a ton of branches and you've evaluated all of them once then yeah you sure might have 100% "coverage". But you have 0% path selection coverage since a single invokation of your API might choose true branch on one statement, false branch on another statement, and a second invokation might choose fal…

> There's a term for this but I forgot what it is and don't care to go spelunking to find it.

Happy path?

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

#714

Post by debt »

notyourday wrote: post #657
stickfigure wrote: post #581

Earlier quoted context omitted.

it seems like they made some mistakes, microed their services in a knee-jerk attempt to alleviate the symptoms of the mistakes, realized microservices didn't fix their mistakes, finally addressed the mistakes, then wrote a blog post about microservices. That seems... appropriate? This is the general problem with the microservices bandwagon: Most of the people touting it have no idea when or why it's appropriate. I on…

The problem is not micro services. The problem is that company's engineering leadership could not lead their way out of a paper bag. Micro services is an extremely powerful pattern which solves a bazillion critical issues most important ones being: * separation of concerns * ability of different teams maintain, develop and reiterate on different subsystems independently from each other * loose coupling of the subsyst…

“Should the engineering be lead by a blind squirrel that once managed to find a nut, in a winter, three years ago”

This made me lol

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

#715

Post by stakecounter »

HolyHaddock wrote: post #644
lolive wrote: post #614

Earlier quoted context omitted.

As a microservice agnostic, i wonder how you can deal elegantly with transactions across services, concurrent access & locks, etc. [Disclaimer: i have not read the article yet]

You may also want to look into the Saga pattern - I found https://www.youtube.com/watch?v=xDuwrtwYHu8 to be a handy high level overview for applying it to microservices. Although personally, I've never felt the need to try and apply it specifically, but the idea is interesting.

Nice, thanks for sharing! I had not heard of this pattern before.

The only nit I have on that video is that after a great motivation and summary, their example application at the end (processing game statistics in Halo) didn’t seem to need Sagas at all. Their transactions (both at the game level and at the player level) were fully idempotent and could be implemented in a vanilla queue/log processor without defining any compensating transactions, unless there were additional complexities not mentioned in the talk.

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

#717

Post by jj12345 »

HolyHaddock wrote: post #644
lolive wrote: post #614

Earlier quoted context omitted.

As a microservice agnostic, i wonder how you can deal elegantly with transactions across services, concurrent access & locks, etc. [Disclaimer: i have not read the article yet]

You may also want to look into the Saga pattern - I found https://www.youtube.com/watch?v=xDuwrtwYHu8 to be a handy high level overview for applying it to microservices. Although personally, I've never felt the need to try and apply it specifically, but the idea is interesting.

Thanks for sharing this video.

When she's discussing Compensations she mentions that the Transaction (T_i) can't have an input dependency on T_i-1. What are some things I should be thinking about when I have hard, ordered dependencies between microservice tasks? For example, microservice 2 (M2) requires output from M1, so the final ordering would be something like: M1 -> M2 -> M1.

Currently, I'm using a high-level, coordinating service to accomplish these long-running async tasks, with each M just sending messages to the top-level coordinator. I'd like to switch to a better pattern though, as I scale out services.

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

#718

Post by inetknght »

piaste wrote: post #713
inetknght wrote: post #691

Earlier quoted context omitted.

Said with less vitriol: It's not just code coverage that matters. It's the code path selection that matters. If you have a ton of branches and you've evaluated all of them once then yeah you sure might have 100% "coverage". But you have 0% path selection coverage since a single invokation of your API might choose true branch on one statement, false branch on another statement, and a second invokation might choose fal…

> There's a term for this but I forgot what it is and don't care to go spelunking to find it. Happy path?

Not quite what I meant, but that's another good description

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

#720

Post by martin_drapeau »

Lots of people judging/bashing the author (and team) that they made bad choices jumpinng on the microservice bandwagon when it clearly wasn't the correct thing to do.

Sure, but at the same time the team learned some valuable lessons, gained experience and hopefully matured. I applaud Alexandra for opening up and sharing that with us.

Post reply on HN