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

Simplify Service Dependencies with Nodes

blog.twitter.com

Post reply on HN
Print view View original

51–60 of 60 posts

Re: Simplify Service Dependencies with Nodes

#51

Post by simono »

virtualwhys wrote: post #50
simono wrote: post #48

Earlier quoted context omitted.

Kotlin is a joke, but Scala's mismanagement and treatment of its contributors might be its undoing. Source: #1/#2 top active community contributor (depends on whether you count commits or locs in scala/scala) leaving Scala, because I'm tired of their shit.

Yeah, Scala's a bit of a mess right now, definitely not thrilled that the flagship web framework (Play) won't be supporting Scala 2.12 until the 2.6 release (i.e. 4-6 months from now), which is absurd given that pretty much the entire ecosystem has a 2.12 release at this point :\ As for typed alternatives, there's no substitute for Scala. Maybe Haskell or OCaml if you leave the JVM, but otherwise it's pretty much a l…

> As an observer none of the powers that be took a liking to you calling them out

The best way to avoid being called out for saying completely different things in public and private is not saying different things in public and private.

If me politely asking for clarification about this sudden change of opinion is "underhanded behavior", or "renouncing from future interactions" means "let's find some flimsy pretext to contact your place of work to tell them what an evil person you are" then Scala might have some issues attracting and retaining contributors in the future.

Re: Simplify Service Dependencies with Nodes

#52

Post by virtualwhys »

simono wrote: post #51
virtualwhys wrote: post #50

Earlier quoted context omitted.

Yeah, Scala's a bit of a mess right now, definitely not thrilled that the flagship web framework (Play) won't be supporting Scala 2.12 until the 2.6 release (i.e. 4-6 months from now), which is absurd given that pretty much the entire ecosystem has a 2.12 release at this point :\ As for typed alternatives, there's no substitute for Scala. Maybe Haskell or OCaml if you leave the JVM, but otherwise it's pretty much a l…

> As an observer none of the powers that be took a liking to you calling them out The best way to avoid being called out for saying completely different things in public and private is not saying different things in public and private. If me politely asking for clarification about this sudden change of opinion is "underhanded behavior", or "renouncing from future interactions" means "let's find some flimsy pretext to…

There's always Typelevel, sure you'd be welcome there as that's kind of the anti-establishment wing of the Scala community ;-)

It's also thriving/taking off, tons of contributions from myriad brilliant minds; for this reason I'm not too worried about Scala, it will continue on with or without Lightbend steering the ship.

Re: Simplify Service Dependencies with Nodes

#53

Post by simono »

virtualwhys wrote: post #52
simono wrote: post #51

Earlier quoted context omitted.

> As an observer none of the powers that be took a liking to you calling them out The best way to avoid being called out for saying completely different things in public and private is not saying different things in public and private. If me politely asking for clarification about this sudden change of opinion is "underhanded behavior", or "renouncing from future interactions" means "let's find some flimsy pretext to…

There's always Typelevel, sure you'd be welcome there as that's kind of the anti-establishment wing of the Scala community ;-) It's also thriving/taking off, tons of contributions from myriad brilliant minds; for this reason I'm not too worried about Scala, it will continue on with or without Lightbend steering the ship.

Don't think so.

They won't be able to prevent the language from being run into the ground by SIP/SLIP/SPP committees.

Anyway, getting told that I'm not qualified to tell people that their new language extension ideas tick all the boxes of "bad ideas that we are regretting and deprecating since years" after I have more or less managed deprecations and removals for four major versions of Scala ... I guess they need to find someone else to do my job now.

But given past experience, the people who are eager to add more and more features are seldomly the people who clean up after themselves.

Most upcoming language proposals have extremely poor quality, ignore years of lessons learned, repeat many mistakes of the past, reinvent things that have been tried without success elsewhere and have no respect for design principles that made Scala great.

So glad that my name won't be associated with this.

Re: Simplify Service Dependencies with Nodes

#54

Post by virtualwhys »

simono wrote: post #53
virtualwhys wrote: post #52

Earlier quoted context omitted.

There's always Typelevel, sure you'd be welcome there as that's kind of the anti-establishment wing of the Scala community ;-) It's also thriving/taking off, tons of contributions from myriad brilliant minds; for this reason I'm not too worried about Scala, it will continue on with or without Lightbend steering the ship.

Don't think so. They won't be able to prevent the language from being run into the ground by SIP/SLIP/SPP committees. Anyway, getting told that I'm not qualified to tell people that their new language extension ideas tick all the boxes of "bad ideas that we are regretting and deprecating since years" after I have more or less managed deprecations and removals for four major versions of Scala ... I guess they need to…

Well, will be interesting to see how Dotty plays out.

DOT may have been proven sound, but compilers are complex beasts; implementing DOT while preserving an upgrade path for Scala will likely be both difficult and limiting (since Dotty will inevitably be shackled by Scala's past).

For now we've got Scala though, in a couple of years maybe Dotty.

Re: Simplify Service Dependencies with Nodes

#55

Post by simono »

virtualwhys wrote: post #54
simono wrote: post #53

Earlier quoted context omitted.

Don't think so. They won't be able to prevent the language from being run into the ground by SIP/SLIP/SPP committees. Anyway, getting told that I'm not qualified to tell people that their new language extension ideas tick all the boxes of "bad ideas that we are regretting and deprecating since years" after I have more or less managed deprecations and removals for four major versions of Scala ... I guess they need to…

Well, will be interesting to see how Dotty plays out. DOT may have been proven sound, but compilers are complex beasts; implementing DOT while preserving an upgrade path for Scala will likely be both difficult and limiting (since Dotty will inevitably be shackled by Scala's past). For now we've got Scala though, in a couple of years maybe Dotty.

Dotty will inevitably implement the same features with the same fundamental issues. This is not about some old stuff we all regret having in Scala, this is about new low-quality proposals. When they get rubberstamped, they will end up in both Scala and Dotty.

Re: Simplify Service Dependencies with Nodes

#56

Post by thorgaardian »

sandGorgon wrote: post #39
thorgaardian wrote: post #37

Earlier quoted context omitted.

Looks just like that. As dstaten said, "just Promise.all but for microservices". I've been contributing to an open-source project called snappi.io - a microservice blueprint that includes very comparable dynamic RPC functionality. Combining RPC with standardized service contracts allows us to create and inject stubs for distributed systems as they get shipped out to solve the problems described in the article. Happy…

that's very interesting. Have you looked at linkerd.io (used in production at large kubernetes deployments)

I have and personally I'm quite fond of it, but it doesn't quite go far enough imo. Linkerd is very lean and requires virtually zero knowledge of how the underlying service it manages works, but the knowledge of interface contracts for services is an important one.

Snappi introduces some mild requirements for how a service exposes it's functions, but once that is done the rest can be automated at deploy time. Not only can service-based load balancers be created dynamically, but RPC stubs can be created for each service and injected into peer services that are dependent on them. For example, if ServiceA needs to access ServiceB, it can do so by referencing this RPC stub knowing that the location of ServiceB will be injected at deploy time to ensure requests are fulfilled for the environment.

There are a number of benefits to this approach for a single application, but one of the larger benefits of consistent specs for contract creation is that individual services will be far easier to share. We're trying to create a structure that will not only empower us to re-use our own services, but also to consume services published by others by simply specifying them as a dependency.

Re: Simplify Service Dependencies with Nodes

#57

Post by WhitneyLand »

suls wrote: post #43
WhitneyLand wrote: post #21

Maybe I'm missing something, how is this better than simple promises in JS? This seem easy to reason about: serviceA { Promise.All(b,c).then(...) } serviceB { (d).then(...) } serviceC { Promise.All(d,e).then(...) }

Yes you are missing something. The purpose of this library is to decouple the "description" from the "computation" itself. I usually call "separating the _what_ from the _how_". Essentially they construct an AST for whatever services that need to be called. Most of the time they then simply "interpret" the AST with the lower-level Finagle constructs. But, and that's actually the big point, they can use _the same code…

It feels like over engineering for most projects, and yet another thing for new hires to learn.

I can't judge Twitter's design without seeing it, but I don't like the sound of this:

"the simplest web page on twitter.com requires collaboration of dozens of network services speaking many different protocols"

Simplest page? Dozens of collaborating services? Many different protocols?

I'm skeptical this is the most elegant architecture possible that meets the requirements of their simplest web page.

Re: Simplify Service Dependencies with Nodes

#58

Post by sandGorgon »

thorgaardian wrote: post #56
sandGorgon wrote: post #39

Earlier quoted context omitted.

that's very interesting. Have you looked at linkerd.io (used in production at large kubernetes deployments)

I have and personally I'm quite fond of it, but it doesn't quite go far enough imo. Linkerd is very lean and requires virtually zero knowledge of how the underlying service it manages works, but the knowledge of interface contracts for services is an important one. Snappi introduces some mild requirements for how a service exposes it's functions, but once that is done the rest can be automated at deploy time. Not onl…

you should get in touch with @beeps of Kubernetes. There has been quite a few discussions on replacing the iptables based Service architecture of k8s with something like Ingress (ingress-all-the-way).

Your work could be perfectly integrated into k8s

Re: Simplify Service Dependencies with Nodes

#59

Post by jondot »

sandGorgon wrote: post #46
jondot wrote: post #40

Earlier quoted context omitted.

I agree. This is exactly the move I've made when I was CTO of a company needing a move to the JVM from .NET. Given the options of Java, Scala - I moved to picking Kotlin. In many ways, Kotlin for me is Scala without the different ways to hang yourself. I wish it was given more credit that it gets right now outside of the Android circles.

that is very interesting! could you talk about the framework that you used? im particularly concerned about ORM and database connectivity.

If by framework you mean web framework, I've used Dropwizard. It's a lean and mean modern-java option, and it's not a Kotlin native thing (you do have these). You can use any Kotlin or traditional Java framework out there transparently (that's a good value of Kotlin).

For ORM, Dropwizard and its ecosystem got you covered.

Also dropping out to Java when ever you want can be done in the same project (which I encouraged) seamlessly both in terms of how Java and Kotlin interoperate, and in terms of Intellij, which is first-class in both languages because Kotlin is Jetbrains' baby, and, because Java has been best supported by Intellij for ages (can't really find that kind of thing anywhere else).

Re: Simplify Service Dependencies with Nodes

#60

Post by thorgaardian »

sandGorgon wrote: post #58
thorgaardian wrote: post #56

Earlier quoted context omitted.

I have and personally I'm quite fond of it, but it doesn't quite go far enough imo. Linkerd is very lean and requires virtually zero knowledge of how the underlying service it manages works, but the knowledge of interface contracts for services is an important one. Snappi introduces some mild requirements for how a service exposes it's functions, but once that is done the rest can be automated at deploy time. Not onl…

you should get in touch with @beeps of Kubernetes. There has been quite a few discussions on replacing the iptables based Service architecture of k8s with something like Ingress (ingress-all-the-way). Your work could be perfectly integrated into k8s

Thanks for the suggestion! We're actually using a lot of k8s inspired processes to power the tool, and may end up building on top of k8s as we learn more about how other developers use snappi. Definitely a lot of synergies, and I'll be sure to reach out to @beeps to talk about them.
Post reply on HN