[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)