Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
Writing distributed applications like microservices can be challenging. I know, surprise, surprise. Performance, versioning, testing, and the list goes on are all aspects that make it difficult. So there’s got to be an answer in the form of tooling that can make this easier. Maybe there is with Google Service Weaver?
YouTube
Check out my YouTube channel, where I post all kinds of content accompanying my posts, including this video showing everything in this post.
Google Sevice Weaver
Write your application as a modular binary. Deploy it as a set of microservices.
https://serviceweaver.dev/
That’s the claim from Google Service Weaver. You split up your application into components. You can then call the components from each other using regular Go method calls. Then you deploy your components locally or in the cloud, Service Weaver figures out if the method call you made in code needs to be a local in-process call or an RPC call at runtime, depending on how it was deployed. This means you’re not thinking about if your call is local or RPC when you’re writing code.
Sounds great, right? How does it actually work? What problems does it solve? A better question that I’d like to challenge you on is whether you have these problems in the first place.
Towards Modern Development of Cloud Applications
There’s a paper called Towards Modern Development of Cloud Applications authored by many of the names I found who contributed to Service Weaver.
I highlighted a portion that I was cheering for joy when I first read at the very beginning of the abstract. If you’ve read any of my blogs (or watched videos) you’ll know I’m constantly yelling to those in the back that logical boundaries aren’t physical boundaries. So to my delight, more people would hear that from this paper.
For more on this, this best explained in the “4+1” View Model of Software Architecture paper by Philippe Kruchten
This conflating of different views has been happening in the software industry. The Service Weaver-authored paper acknowledges this in that we often define a logical boundary that turns into a physical boundary.
A logical boundary is defining what the functional capabilities are; then, we often end up creating a source repository (development view) for all the code we write to implement those capabilities. Then we take that source repository and turn that into a unit of deployment (think executable, container, etc).
Meaning we have a 1:1:1 between all three.
Even if we had a mono-repo, it’s still very similar where it’s a one-to-one from logical to physical.
Now how do all these services communicate with each other? Typically this ends up being RPC because they are all deployed independently.
Service Weaver is saying that they don’t all have to be deployed independently. If you decide to deploy Service A and B together, then that will just be an in-process local call and won’t have to be RPC.
So we can just write our code like a monolith because, as mentioned earlier, with Service Weaver, we just write what seems like local method calls, and Service Weaver at runtime knows how our system was deployed and knows that under the hood, it might be a local call or RPC/remote call depending on how we deployed.
Service Weaver still forces you to handle various errors because it’s possible that it might be a RPC/network call. This means that the developer experience is that you have to treat it as a remote call even though it looks like a local method call.
That sounds great, right? But should you have the problems that Service Weaver tries to solve.
Coupling
The paper cites the problem that having all individually physically deployed units hurts performance because of all the network calls, including serialization. It also hurts correctness because trying to reason about different versions that are deployed is difficult because each is deployed independently. It’s harder to manage because of this as well, and testing can be difficult.
But should you have these problems?
The issue caused by all these problems is coupling, which is not mentioned once in this paper.
The issue with performance and serialization is because of RPC, but that’s because of temporal coupling.
You could choose to use asynchronous messaging and remove the temporal coupling where applicable. Sure, you’re still (de)serializing messages, but you’re not doing it as a synchronous remote call, which will affect the overall performance of the initial request.
As for correctness, the same holds true for messaging of events/commands. You need to either make backward-compatible changes or have a versioning strategy. Not having to think about versioning won’t magically go away in your system. It could be messages, HTTP API definitions, etc. You’re going to have to deal with versioning. For example, if you need to make some database changes that your service uses, how will that work? It’s not going to be something that Google Service Service Weaver handles magically. You’re always going to be thinking about versioning. Yes, Service Weaver can help with service-to-service synchronous communication, but that’s it.
And what’s the root cause of service-to-service versioning problems? Coupling.
I do think Google Service Service Weaver and this paper do address the real-world issues and pain that developers are having developing systems. What it’s not addressing is the root cause of coupling.
You’re going to have coupling within your system, but making it “easier” to not have to think about the compiling and all the problems it causes is not the answer. You need to address coupling when designing your service boundaries—how you’re coupling, when you’re coupling, and the degree of coupling. You need to acknowledge this. Using a framework to gloss over that won’t lead to a better-designed system.
Join CodeOpinon!
Developer-level members of my Patreon or YouTube channel get access to a private Discord server to chat with other developers about Software Architecture and Design and access to source code for any working demo application I post on my blog or YouTube. Check out my Patreon or YouTube Membership for more info.