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

Write for InfoQ

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 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.

Related Topics:

• DevOps
• Modular Monolith
• Deployment
• Go Language
• Microservice Frameworks
• Google Cloud
• Google

We protect your privacy.