Calm down about Service Weaver

It isn't a silver bullet, and it's not claiming to be

In 1991, the standards consortium OMG published the first version of something called CORBA, a standard that promised to bring distributed programming to the masses. No more weird homegrown RPC implementations that didn’t interoperate! Developers wouldn’t need to know the hardware, operating system, or even the languages used by remote machines. Through the power of its fancy new interface definition language, CORBA was going to be the beginning and the end of all middleware. OMG, indeed!

How CORBA worked at a high level. (It only worked at a high level.)

CORBA never took over the world for a variety of reasons—not all of them technical—but the funniest excuse appears on its Wikipedia page:

Much of the criticism of CORBA stems from poor implementations of the standard and not deficiencies of the standard itself.

See, the spec was great, it was just those silly programmers who couldn’t figure out how to apply it. The pesky fallacies of distributed computing kept getting in the way.

But software keeps needing to talk to other software over the network, and so people keep trying to design protocols and component models and service-oriented architectures to make it easier.

Microsoft tried it with DCOM (and, more recently, with Orleans¹). Enterprise JavaBeans apps have been doing RPC stuff forever. The worst person you know won’t shut up about the Erlang actor model.

These solutions have made their way into lots of production systems over the years, so it would be wrong to say they “don’t work”, but nobody who’s had to support them seems very happy about it. A big reason is that distributed programming models often make a seductive promise that is impossible to fulfill: they gloss over the realities of time and space by pretending that a bunch of remote machines are the same thing as one local machine, or vice versa. (See this glorious rant about what that meant for unsuspecting DCOM developers).

In a nutshell: Distributed systems are irreducibly tricky, we’ve known this for decades, and it’s probably best that everyone stays mentally prepared for it—particularly in the cloud.

Pretty much this

So you can see why when this week Google open-sourced a “framework for writing distributed applications” called Service Weaver, the overwhelming reaction was deja vu.

Martin Kleppmann, the patron saint of your distributed systems book club, is skeptical:

Martin Kleppmann @martin@nondeterministic.computer @martinkl

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

serviceweaver.devService Weaver

And skeptical also are hundreds of others in Kelsey Hightower’s mentions. Kelsey and the core maintainers of the project have been working overtime to listen and respond to all the feedback; here’s a Twitter Space they did yesterday that addresses a lot of common questions.

It does sound like the announcement blog and the docs could use some tweaking. In particular, I think the “write a monolith, deploy microservices” framing has gotten some people a bit off track. It seems to me that Service Weaver isn’t really a tool for creating self-contained microservices as they’re classically understood; it’s more about spreading a single service over multiple pieces of compute.

If you’re trying to figure out “why does Service Weaver need to exist”, here’s my understanding:

1. It’s Golang-first right now, and the Go ecosystem didn’t previously have a tool like this;

2. It does seem to provide better tools for dealing with some real problems people are experiencing with big Kubernetes deployments, such as upgrade versioning and testing, by consolidating code maintenance into one place while allowing atomic deployments;

3. It provides some measurable performance gains for network calls via a custom serialization mechanism;

4. It gives you some observability hooks with OpenTelemetry out of the box so you can get more insight into the distributed calls you might be making.

So I think for people who are deep into the services-on-Kubernetes world, Service Weaver has potential as a deployment tool—as long as we don’t attempt to paint it as a magic development framework that makes remote function calls behave just like local ones. That didn’t work for CORBA and it won’t work for you and me.²

On the other hand, if you are building the kind of architectures that some of us like to call “service-full” (that is, gluing cloud services together and representing the application control flow in the infrastructure diagram), then I’m more interested in something like Wing, a new programming language that interacts with cloud infrastructure the way .NET wraps Windows syscalls.

Either way, I’m cautiously encouraged that Service Weaver is a step up the abstraction ladder from “caring a lot about containers” by decoupling deployment topology from app code. And I think the widespread community interest very clearly marks it as a project to watch going forward.

In the meantime, well…

1. There are a lot of tools out there that ship their org chart, but I can’t remember seeing anything quite so Conway’s-Law as Orleans calling their control primitive a “silo”.

2. Kelsey and others have suggested that the safest way to use Service Weaver is to write code as if any function you invoke could be a remote call. I admit being a little skeptical of this approach, as assuming “worst-case” complexity for every call is one of the very antipatterns that sunk CORBA.