4 ms·

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

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(...) }

crispywalrus 10y ago
The "simple promises" from JS are (somewhat crippled) copies of Futures from other languages. In Scala the results of those futures can be produced at the same time, even if they are purely computational as Scala and most other languages are both asynchronous AND concurrent.
- WhitneyLand 10y ago
  JS is async and concurrent. I resent it's limitations as much as any self respecting developer, but workers are finally in.
- deleted 10y ago
  [deleted]
avita1 10y ago
The library they referenced (Finagle) does pretty much just that. A few things that leapt out at me: - It's hard to figure out what the dependency graph looks like just from promises - That pattern is verbose and results in gross types when you do it in Java - With this library, you can easily profile parts of the algorithm to see what's going slow, what's taking a bunch of memory, etc.
Coding_Cat 10y ago
I think Fnangle is an abstraction over futures. The selling point I found when looking at Tokio (rust equivalent, references Fnangle) was that you write a driver for each backend and then have generic services to implement things such as timeouts. So you can reuse the timeout code for your network queries and your db queries.
dstaten 10y ago
Thank you! This is just Promise.all but for microservices. Every time a large company discovers that its messy infrastructure can be cleaned up a bit by reimplementing a simple programming concept, it's suddenly not just newsworthy but framework worthy
thorgaardian 10y ago
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 to see companies like Twitter following a similar path, and we're hoping to bring those patterns to more applications powered by a wide variety of tech-stacks.
- sandGorgon 10y ago
  that's very interesting. Have you looked at linkerd.io (used in production at large kubernetes deployments)
  - thorgaardian 10y ago
    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.
    - sandGorgon 10y ago
      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
suls 10y ago
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_ with a different interpreter to generate a GraphViz representation for visual inspection. This super helpful once your call graph becomes more complex .. Another possibility is to write an optimizing interpreter etc. Anyhow, what I find a bit sad is that they didn't leverage the Scala part if Finagle more .. this would be a prime example for a Free Monad () based DSL. That way they could have avoided writing 10s of classes with less than fortunate names. () might need a Free Applicative part as well since they inherently want to have parallelism expressed in the language
- wereHamster 10y ago
  Monad implies Applicative, so the "might need a free applicative part as well" is already a given.
  - suls 10y ago
    Yes and no. With Free Applicatives you can express side-effects such as parallelism .. not so with Free Monads afaik
- WhitneyLand 10y ago
  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.

crispywalrus 10y ago

The "simple promises" from JS are (somewhat crippled) copies of Futures from other languages. In Scala the results of those futures can be produced at the same time, even if they are purely computational as Scala and most other languages are both asynchronous AND concurrent.

WhitneyLand 10y ago
JS is async and concurrent. I resent it's limitations as much as any self respecting developer, but workers are finally in.
deleted 10y ago
[deleted]

avita1 10y ago

The library they referenced (Finagle) does pretty much just that. A few things that leapt out at me: - It's hard to figure out what the dependency graph looks like just from promises - That pattern is verbose and results in gross types when you do it in Java - With this library, you can easily profile parts of the algorithm to see what's going slow, what's taking a bunch of memory, etc.

Coding_Cat 10y ago

I think Fnangle is an abstraction over futures. The selling point I found when looking at Tokio (rust equivalent, references Fnangle) was that you write a driver for each backend and then have generic services to implement things such as timeouts. So you can reuse the timeout code for your network queries and your db queries.

dstaten 10y ago

Thank you! This is just Promise.all but for microservices. Every time a large company discovers that its messy infrastructure can be cleaned up a bit by reimplementing a simple programming concept, it's suddenly not just newsworthy but framework worthy

thorgaardian 10y ago

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 to see companies like Twitter following a similar path, and we're hoping to bring those patterns to more applications powered by a wide variety of tech-stacks.

sandGorgon 10y ago
that's very interesting. Have you looked at linkerd.io (used in production at large kubernetes deployments)
- thorgaardian 10y ago
  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.
  - sandGorgon 10y ago
    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

suls 10y ago

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_ with a different interpreter to generate a GraphViz representation for visual inspection. This super helpful once your call graph becomes more complex .. Another possibility is to write an optimizing interpreter etc. Anyhow, what I find a bit sad is that they didn't leverage the Scala part if Finagle more .. this would be a prime example for a Free Monad () based DSL. That way they could have avoided writing 10s of classes with less than fortunate names. () might need a Free Applicative part as well since they inherently want to have parallelism expressed in the language

wereHamster 10y ago
Monad implies Applicative, so the "might need a free applicative part as well" is already a given.
- suls 10y ago
  Yes and no. With Free Applicatives you can express side-effects such as parallelism .. not so with Free Monads afaik
WhitneyLand 10y ago
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.