[HN Gopher] Service Weaver: A Framework for Writing Distributed ... ___________________________________________________________________ Service Weaver: A Framework for Writing Distributed Applications Author : munchor Score : 58 points Date : 2023-03-01 18:25 UTC (4 hours ago) (HTM) web link (opensource.googleblog.com) (TXT) w3m dump (opensource.googleblog.com) | EGreg wrote: | Is this only for Go? | rdgrandl wrote: | We provide only Go support for now. We're still early and do | plan to support other languages in the future. | waynesonfire wrote: | Until then, "A Go Framework..." would be a more appropriate | title? | tbern02 wrote: | 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. | im_down_w_otp wrote: | This reminds me of "Distributed Applications" in Erlang (https:// | www.erlang.org/doc/design_principles/distributed_app...). | aleksiy123 wrote: | 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. | eliben wrote: | 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 are fairly | comprehensive, kudos to the team!] | qfg77 wrote: | 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. | ipsum2 wrote: | Is this currently used at Google? | allanrbo wrote: | 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 wrote: | 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. | Bjartr wrote: | > 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. | revskill wrote: | 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,...) {} | | ? | cubelet wrote: | How does this complement/differ from Istio? ___________________________________________________________________ (page generated 2023-03-01 23:00 UTC)