BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Google Service Weaver Enables Coding as a Monolith and Deploying as Microservices

Google Service Weaver Enables Coding as a Monolith and Deploying as Microservices

Bookmarks

Google has released Service Weaver, an open-source framework for building and deploying distributed applications. The Go-based framework includes a set of programming libraries that enable writing applications as a single modular binary. The other component is a set of deployers that allow for configuring the runtime topology and running the application locally or in the cloud.

As described by Srdjan Petrovic, principal engineer at Google, and Garv Sawhney, product manager at Google, "Service Weaver allows you to write your application as a modular monolith and deploy it as a set of microservices". This modular monolith has all code residing within a singular binary. The binary is organized as a set of modules, known as components, created using only native types in the programming language. This example consists of a main() function and a single component called Adder:

type Adder interface { 
    Add(context.Context, int, int) (int, error)
} 
type adder struct{ 
    weaver.Implements[Adder]
}
func (adder) Add(_ context.Context, x, y int) (int, error) {
  return x + y, nil
}

func main() {
  ctx := context.Background()
  root := weaver.Init(ctx)
  adder, err := weaver.Get[Adder](root)
  sum, err := adder.Add(ctx, 1, 2)
}

Components interact with each other via standard method calls. Once deployed, Service Weaver will split up the application by components enabling components to run independently of each other and on distinct machines. Service Weaver will either execute the call as a local method call or translate it into a cross-machine RPC as needed.

Service Weaver high-level architecture

Service Weaver high-level architecture (credit: Google)

 

Service Weaver was created to simplify the process of developing and operating microservice-based applications. Petrovic and Sawhney described the challenges in building a microservice architecture:

We found that the overhead of maintaining multiple different microservice binaries - with their own configuration files, network endpoints, and serializable data formats - significantly slowed our development velocity.

Response to the release was mixed with many concerned that this approach is too similar to past frameworks that claimed to be able to remove the differences between RPC and local method calls. Martin Kleppmann wrote on Twitter:

Google's Service Weaver claims that it can hide the difference between RPC and local method calls. Just like CORBA claimed in 1991. Is it different this time? The docs say barely a word about handing failures, such as RPCs timing out.

Scott McKay agreed with this in tweeting that "the problems of distributed systems (failure handling, widely varying latency, etc) don't just magically go away." However, Russ Freeman wrote that this approach doesn't seem to be problematic: "as long as you assume the calls may be remote and cater accordingly. The other mistake would be to go too granular on the participants."

In a response to Daniel Bryant's comment on Twitter that this approach looks similar to Java's OSGi, Miles Groocock-Wilson wrote:

I think the bit that’s critically different are the design assumptions going in. Service [W]eaver you program like it’s remote, and sometimes get surprised when it’s local and super fast. vs previous similar things that did the opposite

Service Weaver is open-source and available under the Apache 2.0 license. The current 0.1 release includes deployers for running the application locally and on Google Cloud. Petrovic and Sawhney indicate that users are to expect breaking changes until the 1.0 release is reached.

About the Author

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Seamless RPC

    by Sundarraj Kaushik,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Spring Remoting attempted the same a few years ago. While all will work and will appear to provide a feeling of improving productivity and simplifying distributed applications the problem is that it encourages developers to use remote procedure execution without realising they are doing it and this leads to a big performance issue.

  • Re: Seamless RPC

    by Matthew Campbell,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    That was the consensus we found in researching this piece. When using a framework like this, you must assume you are writing for the remote case. I guess the challenge is that if the framework obfuscates too much, it may lead to not understanding that your calls may end up being RPCs versus assuming everything will be local.

  • Seamless RPC

    by irekm irekm,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    It doesn't make too much sense to me:
    1) as Mr Kleppmann noted - you still have to be aware of services unavailability, etc
    2) remote APIs should be designed designed different way than local APIs: to reduce amount of network traffic, and to reduce amount of the (very expensive) inter-team communication
    3) standard microservices provide also high cohesion / low coupling, and independence from programming language. Here they disappear (one big codebase, only Golang)

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT