12 ms·

Service Weaver: A Framework for Writing Distributed Applications

117 points by davidgomes 4y ago

arcamox 4y ago
unfortunately the Service Weaver Google Group seems highly moderated (my message didn’t go through). Does anyone who’s tried SW over the weekend want to join #serviceweaver on Gophers Slack? I have questions. :)
cubelet 4y ago
How does this complement/differ from Istio?
EGreg 4y ago
Is this only for Go?
- rdgrandl 4y ago
  We provide only Go support for now. We're still early and do plan to support other languages in the future.
  - waynesonfire 4y ago
    Until then, "A Go Framework..." would be a more appropriate title?
    - tbern02 4y ago
      For sure, the GitHub page should label this as a framework for Go until there's anything substantial to allow running this for non-Go apps.
allanrbo 4y ago
Is it correctly understood that this is useful for scaling the compute of a single logical application, probably maintained by a single team, and less for communicating across applications, where a traditional RPC or REST API might still make the most sense?
- qfg77 4y ago
  Yes, that's pretty spot on. Though we do have plans to add cross-application support as well, at the minimum stub generation and likely service discovery. But some of the nicer properties like versioning and language-native types will likely be lost on the cross-application communication path.
  - gedw99 4y ago
    I was wondering about Service discovery Is there any suppptt for Publishing an event to all subscribes from a Module so all other modules that are interested could get that event payload ?
aleksiy123 4y ago
I always dreamed of something like this where functions could be called as normal but they could be an RPC behind the scenes. The compiler would take care of serialization/deserialization and routing. But how is it possible to not worry about network. Every function is now able to fail. Why don't you need to handle this explicitly? Or is there just a default behaviour that can be overriden? Edit: after reading the docs I think I understand a bit more. You'll have have to deal with network errors on anything crossing module boundaries.
- whalesalad 4y ago
  Erlang/Elixir does this!
- qfg77 4y ago
  I think it's safe to say that this doesn't go as far as the dream. In addition to functions failing, you can't share memory between functions etc. With Service Weaver, you have to be aware that you're writing a distributed application, but you get to write it as a single binary. So it's not as magical as it can be, but it improves on the status quo.
- eliben 4y ago
  You do have to worry about the network when you call between components. The documentation talks about this explicitly in "Semantics": "Method calls are executed with at-most-once semantics. This means that Service Weaver does not automatically retry method calls that fail. However, you can detect and retry failed method calls explicitly using weaver.ErrRetriable. If a method call fails because of a transient system error (e.g., a component replica crashed, the network is partitioned), it returns an error with an embedded weaver.ErrRetriable." With the following example: // Retry the cache.Get method call up to five times. var val string var err error for i := 0; i < 5; i++ { val, err = cache.Get(ctx, "key") if errors.Is(err, weaver.ErrRetriable) { // Retriable system error! Retry. continue } break } [The docs at https://serviceweaver.dev/docs.html https://serviceweaver.dev/docs.html are fairly comprehensive, kudos to the team!]
  - 4y ago
ipsum2 4y ago
Is this currently used at Google?
revskill 4y ago
Developers are too lazy to write specs for API, so there's this framework ? Now the function call will have this kind of signature: func Add(apiKey, apiSecret,...) {} ?
im_down_w_otp 4y ago
This reminds me of "Distributed Applications" in Erlang (https://www.erlang.org/doc/design_principles/distributed_applications.html https://www.erlang.org/doc/design_principles/distributed_app...).
Bjartr 4y ago
> microservices severely impacted our ability to make cross-binary changes. It made us do things like flag-gate new features in each binary, evolve our data formats carefully, and maintain intimate knowledge of our rollout processes. Finally, having a predetermined number of specific microservices effectively froze our APIs; they became so difficult to change that it was easier to squeeze all of our changes into the existing APIs rather than evolve them. I'm amused by how the rise of microservices was in part due to the promise of solving some of these problems as they arose in the classic monolith. Independent teams, decoupled deploys, etc. Putting a network request between components doesn't decouple them, it just trades one kind of coupling for another. Even worse, some previously explicit coupling becomes hidden, but remains present.
mpweiher 4y ago
OK. We've been here before, the "transparent RPCs" path. SunRPC, Mach Messages and MiG, various even more transparent distributed object systems etc. etc. etc. So it would be awesome to have some reference to these earlier systems and how this project overcomes the problems they encountered. I checked the FAQ ( https://serviceweaver.dev/docs.html#faq https://serviceweaver.dev/docs.html#faq ) and didn't find anything. Or a brief explanation why this is so incredibly different that those issues don't apply. Or a brief explanation that those issues weren't problems and everything is just dandy. Or even we didn't consider those systems at all. Just something. Cheers!
datavirtue 4y ago
Helps you make spaghetti systems
deleted 4y ago
[deleted]
vimota 4y ago
Unison lang has a lot of overlap with model: https://www.unison-lang.org/learn/the-big-idea/ https://www.unison-lang.org/learn/the-big-idea/
brianm 4y ago
This is... EJBs. It is probably less painful to use, but the model is pretty much the same. Fascinating.
- latchkey 4y ago
  EJB3 wasn't that painful, it was actually quite nice. Ran one of the largest porn sites out there on JBoss4 tech and it worked really really well.
  - brianm 4y ago
    Hah, wave. That is a name (latchkey, not jboss) I have not heard in a very long time :-) I was thinking of the EJB 1 & 2 era xml wiring of all the things.
    - latchkey 4y ago
      hi brian! long time as well. i hope you're well. =)
  - sbmthakur 4y ago
    Any links that described how they scaled their services?
    - latchkey 4y ago
      3 medium sized dell frontend servers running jboss4 and one beefy backend mysql server. we ran our own bare metal because this was before 'cloud' services would allow porn sites to operate. the ejb3 caching was so efficient that we really only needed one server, we just had the other two as backup so that we could do CI driven rolling deploys integrated with the load balancer. we used jgroups mcast to expire entities in the cache. jvms were carefully monitored and all the settings were heavily tuned for our environment. the hardest thing about all of it was simply packaging it all up into a war file correctly. it is all knowledge that i've long since forgotten how to do.
- rowls66 4y ago
spullara 4y ago
There has never been any issues with hiding distributed RPC calls. https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...
sa46 4y ago
Super cool. If I understand correctly: - There's no IDL file, like a .proto file. Instead, weaver looks for marker interfaces by embedding weaver.Implements[T]. - Weaver interfaces must be serializable, which explicitly support protobufs. Was the intent to be able to port gRPC services to weaver? - Weaver maintains a list of deployments, and each deployment has components. Components may only communicate with components belonging to the same deployment. Sounds like a way to implement atomic deploys. - Named listeners are mapping over a net.Listener? Sidenote: I'm going to steal the metrics implementation. I haven't found a lightweight metrics implementation for GCP.
- rdgrandl 4y ago
  This is a great summary. Some comments: - Service Weaver implements its own serialization mechanism which is very efficient/achieves high performance. - You write an application as components (where each component is defined by an interface). You can deploy the same application using different deployers: (1) on the local machine as single/multi process; (2) on GKE and we also have an experimental (3) SSH deployer that allows you to deploy across a cluster of machines reachable over SSH. - However, the abstractions around deployment are agnostic to the deployment environment (local, cluster, cloud), hence someone can improve/write new deployers without deep knowledge of Service Weaver internals.
mola 4y ago
Using the term microservices here is confusing. The main point of microservices as an architectural pattern is decoupling release cadence between teams in very large organizations. The scaling/redundancy part is not unique to microservices. What this framework seem to be doing is allowing a team to deploy a system developed as a single binary monolith as a distributed system. The organizational use case is orthogonal to what microservices were all about. Granted, microservices have been cargoculted like crazy, so this distinction is probably lost on a lot of engs. But for those of us that remember the original meaning, mentioning microservices in the description of this framework, is odd.
edandersen 4y ago
Microsoft Orleans is a really mature version of the actor model for the .NET stack that operates just like this. And the key difference is that it's used by Microsoft themselves in huge systems like Xbox Live.
gedw99 4y ago
One of the reasons I break code down into smaller pieces ( microservice ) is to have fast edit and compile times. The versioning hell is why so many went to mono repos. There is only one git version and that’s it. Also what about runtime version difference and schema evolution? So many thing come into play. I would rather just buy the bullet and use protobufs with NATS from day one . No load balances and heavy expensive gke / k8 stuff Then deploy of fly where I have regions with auto scaling based on metric feedback loops. Then use nats client on all client to get geo physical load balancing out to the nearest region. Then use their postresql multi Region. Cockroach multi Region replication costs big money. I did like their tooling in Weaver though. Even the converged logging was pretty nice. https://github.com/ServiceWeaver/weaver/blob/main/runtime/logging/files.go https://github.com/ServiceWeaver/weaver/blob/main/runtime/lo...
halturin 4y ago
"Transparent Networking" achieved. To reach the next level you should unlock an "Actor Model" :) PS for me, it's more like reinventing Erlang ideas in Golang. If you want to cut the corner here is the ready-to-use Framework in Golang https://github.com/ergo-services/ergo https://github.com/ergo-services/ergo - implements all Erlang' neats.

117 points by davidgomes 4y ago

unfortunately the Service Weaver Google Group seems highly moderated (my message didn’t go through). Does anyone who’s tried SW over the weekend want to join #serviceweaver on Gophers Slack? I have questions. :)

cubelet 4y ago

How does this complement/differ from Istio?

EGreg 4y ago

Is this only for Go?

rdgrandl 4y ago
We provide only Go support for now. We're still early and do plan to support other languages in the future.
- waynesonfire 4y ago
  Until then, "A Go Framework..." would be a more appropriate title?
  - tbern02 4y ago
    For sure, the GitHub page should label this as a framework for Go until there's anything substantial to allow running this for non-Go apps.

allanrbo 4y ago

Is it correctly understood that this is useful for scaling the compute of a single logical application, probably maintained by a single team, and less for communicating across applications, where a traditional RPC or REST API might still make the most sense?

qfg77 4y ago
Yes, that's pretty spot on. Though we do have plans to add cross-application support as well, at the minimum stub generation and likely service discovery. But some of the nicer properties like versioning and language-native types will likely be lost on the cross-application communication path.
- gedw99 4y ago
  I was wondering about Service discovery Is there any suppptt for Publishing an event to all subscribes from a Module so all other modules that are interested could get that event payload ?

aleksiy123 4y ago

I always dreamed of something like this where functions could be called as normal but they could be an RPC behind the scenes. The compiler would take care of serialization/deserialization and routing. But how is it possible to not worry about network. Every function is now able to fail. Why don't you need to handle this explicitly? Or is there just a default behaviour that can be overriden? Edit: after reading the docs I think I understand a bit more. You'll have have to deal with network errors on anything crossing module boundaries.

whalesalad 4y ago
Erlang/Elixir does this!
qfg77 4y ago
I think it's safe to say that this doesn't go as far as the dream. In addition to functions failing, you can't share memory between functions etc. With Service Weaver, you have to be aware that you're writing a distributed application, but you get to write it as a single binary. So it's not as magical as it can be, but it improves on the status quo.
eliben 4y ago
You do have to worry about the network when you call between components. The documentation talks about this explicitly in "Semantics": "Method calls are executed with at-most-once semantics. This means that Service Weaver does not automatically retry method calls that fail. However, you can detect and retry failed method calls explicitly using weaver.ErrRetriable. If a method call fails because of a transient system error (e.g., a component replica crashed, the network is partitioned), it returns an error with an embedded weaver.ErrRetriable." With the following example: // Retry the cache.Get method call up to five times. var val string var err error for i := 0; i < 5; i++ { val, err = cache.Get(ctx, "key") if errors.Is(err, weaver.ErrRetriable) { // Retriable system error! Retry. continue } break } [The docs at https://serviceweaver.dev/docs.html https://serviceweaver.dev/docs.html are fairly comprehensive, kudos to the team!]
- 4y ago

ipsum2 4y ago

Is this currently used at Google?

revskill 4y ago

Developers are too lazy to write specs for API, so there's this framework ? Now the function call will have this kind of signature: func Add(apiKey, apiSecret,...) {} ?

im_down_w_otp 4y ago

This reminds me of "Distributed Applications" in Erlang (https://www.erlang.org/doc/design_principles/distributed_applications.html https://www.erlang.org/doc/design_principles/distributed_app...).

Bjartr 4y ago

> microservices severely impacted our ability to make cross-binary changes. It made us do things like flag-gate new features in each binary, evolve our data formats carefully, and maintain intimate knowledge of our rollout processes. Finally, having a predetermined number of specific microservices effectively froze our APIs; they became so difficult to change that it was easier to squeeze all of our changes into the existing APIs rather than evolve them. I'm amused by how the rise of microservices was in part due to the promise of solving some of these problems as they arose in the classic monolith. Independent teams, decoupled deploys, etc. Putting a network request between components doesn't decouple them, it just trades one kind of coupling for another. Even worse, some previously explicit coupling becomes hidden, but remains present.

mpweiher 4y ago

OK. We've been here before, the "transparent RPCs" path. SunRPC, Mach Messages and MiG, various even more transparent distributed object systems etc. etc. etc. So it would be awesome to have some reference to these earlier systems and how this project overcomes the problems they encountered. I checked the FAQ ( https://serviceweaver.dev/docs.html#faq https://serviceweaver.dev/docs.html#faq ) and didn't find anything. Or a brief explanation why this is so incredibly different that those issues don't apply. Or a brief explanation that those issues weren't problems and everything is just dandy. Or even we didn't consider those systems at all. Just something. Cheers!

datavirtue 4y ago

Helps you make spaghetti systems

deleted 4y ago

[deleted]

vimota 4y ago

Unison lang has a lot of overlap with model: https://www.unison-lang.org/learn/the-big-idea/ https://www.unison-lang.org/learn/the-big-idea/

brianm 4y ago

This is... EJBs. It is probably less painful to use, but the model is pretty much the same. Fascinating.

latchkey 4y ago
EJB3 wasn't that painful, it was actually quite nice. Ran one of the largest porn sites out there on JBoss4 tech and it worked really really well.
- brianm 4y ago
  Hah, wave. That is a name (latchkey, not jboss) I have not heard in a very long time :-) I was thinking of the EJB 1 & 2 era xml wiring of all the things.
  - latchkey 4y ago
    hi brian! long time as well. i hope you're well. =)
- sbmthakur 4y ago
  Any links that described how they scaled their services?
  - latchkey 4y ago
    3 medium sized dell frontend servers running jboss4 and one beefy backend mysql server. we ran our own bare metal because this was before 'cloud' services would allow porn sites to operate. the ejb3 caching was so efficient that we really only needed one server, we just had the other two as backup so that we could do CI driven rolling deploys integrated with the load balancer. we used jgroups mcast to expire entities in the cache. jvms were carefully monitored and all the settings were heavily tuned for our environment. the hardest thing about all of it was simply packaging it all up into a war file correctly. it is all knowledge that i've long since forgotten how to do.
rowls66 4y ago

spullara 4y ago

There has never been any issues with hiding distributed RPC calls. https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...

sa46 4y ago

Super cool. If I understand correctly: - There's no IDL file, like a .proto file. Instead, weaver looks for marker interfaces by embedding weaver.Implements[T]. - Weaver interfaces must be serializable, which explicitly support protobufs. Was the intent to be able to port gRPC services to weaver? - Weaver maintains a list of deployments, and each deployment has components. Components may only communicate with components belonging to the same deployment. Sounds like a way to implement atomic deploys. - Named listeners are mapping over a net.Listener? Sidenote: I'm going to steal the metrics implementation. I haven't found a lightweight metrics implementation for GCP.

rdgrandl 4y ago
This is a great summary. Some comments: - Service Weaver implements its own serialization mechanism which is very efficient/achieves high performance. - You write an application as components (where each component is defined by an interface). You can deploy the same application using different deployers: (1) on the local machine as single/multi process; (2) on GKE and we also have an experimental (3) SSH deployer that allows you to deploy across a cluster of machines reachable over SSH. - However, the abstractions around deployment are agnostic to the deployment environment (local, cluster, cloud), hence someone can improve/write new deployers without deep knowledge of Service Weaver internals.

mola 4y ago

Using the term microservices here is confusing. The main point of microservices as an architectural pattern is decoupling release cadence between teams in very large organizations. The scaling/redundancy part is not unique to microservices. What this framework seem to be doing is allowing a team to deploy a system developed as a single binary monolith as a distributed system. The organizational use case is orthogonal to what microservices were all about. Granted, microservices have been cargoculted like crazy, so this distinction is probably lost on a lot of engs. But for those of us that remember the original meaning, mentioning microservices in the description of this framework, is odd.

edandersen 4y ago

Microsoft Orleans is a really mature version of the actor model for the .NET stack that operates just like this. And the key difference is that it's used by Microsoft themselves in huge systems like Xbox Live.

gedw99 4y ago

One of the reasons I break code down into smaller pieces ( microservice ) is to have fast edit and compile times. The versioning hell is why so many went to mono repos. There is only one git version and that’s it. Also what about runtime version difference and schema evolution? So many thing come into play. I would rather just buy the bullet and use protobufs with NATS from day one . No load balances and heavy expensive gke / k8 stuff Then deploy of fly where I have regions with auto scaling based on metric feedback loops. Then use nats client on all client to get geo physical load balancing out to the nearest region. Then use their postresql multi Region. Cockroach multi Region replication costs big money. I did like their tooling in Weaver though. Even the converged logging was pretty nice. https://github.com/ServiceWeaver/weaver/blob/main/runtime/logging/files.go https://github.com/ServiceWeaver/weaver/blob/main/runtime/lo...

halturin 4y ago

"Transparent Networking" achieved. To reach the next level you should unlock an "Actor Model" :) PS for me, it's more like reinventing Erlang ideas in Golang. If you want to cut the corner here is the ready-to-use Framework in Golang https://github.com/ergo-services/ergo https://github.com/ergo-services/ergo - implements all Erlang' neats.