Network protocol overview?

[Derek Perez]

I can’t find anything in the documentation about what the serialization and network protocol choices this project is making, given it’s novel I’d like to learn more about it. Will this be documented at some point?

[mwhittaker]

Hi Derek,

Thanks for checking out the project, and great question! I think we will add more documentation on the serialization and network protocol. I'm not sure when exactly we'll get to it, but in the meantime, here are the parts of the code that implement these various things. 

• encoder.go: The code that serializes data.
• decoder.go: The code that deserializes data.
• generator.go: The code generator that generates serialization and deserialization code (using encoder.go and decoder.go) for user's data types.
• call.go: The RPC implementation.

If you have any specific questions about anything before we add the documentation, we're more than happy to answer!

Best,

Michael

[Derek Perez]

Thanks for the pointers! I was wondering, is this new encoding format going to be cross language? I've read elsewhere your team is interested in cross-lang implementations. Also, is this new serialization format versioned in any way? What's the plan there.

- D

[mwhittaker]

We may support multiple languages in the future, but we haven't done enough design yet to know how it will affect the encoding. 

The serialization format is intentionally not versioned. Service Weaver ensures that two versions of an application never communicate with one another. All communication is guaranteed to be between different pieces of code running at the same version. Because of this, we don't need to include any kind of versioning in the serialization format itself.  

[Derek Perez]

> All communication is guaranteed to be between different pieces of code running at the same version

Can you expand more on this? Is this because GKE-based deployments are blue/green in nature or something? How does one do a gradual rollout of a set of services in a way that this guarantee can be held?

[mwhittaker]

Yes, happy to explain more! With Service Weaver, you write an application once and can then deploy this application to a number of different environments. For example, we have a deployer that runs components in different subprocesses on a single machine. We have a deployer that runs components via SSH on a group of machines. We have a deployer that runs components as pods in GKE. We are also encouraging people to write their own deployers. So, there is no single deployer, but for a deployer to be a valid Service Weaver deployer, we require it to implement rollouts in a way such that all communication is guaranteed to be between different pieces of code running at the same version. 

There are many different ways to implement this, and the implementation is up to the deployer. For the GKE deployer though, yes, we do blue/green deployments. You can read this section and this section of our documentation to learn more about how we do this. If you have questions about anything that we don't cover in the docs---there's a lot; the docs are still young :)---please feel free to ask!

[Derek Perez]

Thanks for the details, this seems like a really important aspect of a deployer to get right, will there be some sort of conformance/acceptance testing to ensure this is guaranteed?

Also, that first link doesn't work, what is that referring to?

- D

--
You received this message because you are subscribed to a topic in the Google Groups "Service Weaver" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/serviceweaver/C9hbscximEQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to serviceweave...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/serviceweaver/5768d609-d5f5-43f9-b030-2d8d40fd1d46n%40googlegroups.com.

[mwhittaker]

> Thanks for the details, this seems like a really important aspect of a deployer to get right, will there be some sort of conformance/acceptance testing to ensure this is guaranteed?

Yup, this is definitely an important and core part of Service Weaver. We hadn't considered any conformance or acceptance testing, but it sounds like a good idea to me. We'll keep this mind. If you have any ideas for what this kind of testing would look like or know of any other projects that do this well, that would be super helpful!

> Also, that first link doesn't work, what is that referring to?

D'oh, meant to link this again: https://serviceweaver.dev/docs.html#versioning.

[Derek Perez]

I'm imagining you'll need to have something that can actually verify distributed consistency...actively work out a way to break the expectations of the versioning system. This kinda reminds me of what Jepsen does (but for databases). In fact, Kyle might be a good person to reach out to for suggestions, he's basically the best at this kind of thing.

- D

To view this discussion on the web visit https://groups.google.com/d/msgid/serviceweaver/a243d6fa-51c8-465e-b14e-175e78d13229n%40googlegroups.com.

[Peter Aba]

Hi Michael,

Can you please also elaborate on why you decided to design and implement a new protocol instead of relying on the obviously battle-tested and even in-house gRPC? Or is the solution based on gRPC?

Thanks,

Peter

[Srdjan Petrovic]

Hi Peter,

Our first protocol implementation was actually gRPC based. However, we found that it doesn't integrate well with Kubernetes Services. This is because gRPC uses HTTP2, so it establishes sticky connections to the Pods. As a result, we noticed that the traffic wasn't getting equally distributed across server replicas.

We tried a number of workarounds but none of them were great. The "real" solution would have been to use gRPC's built-in xDS support, but that support wasn't as well developed at the time and so we decided to implement our own TCP-based protocol with client-side load-balancing. It worked out great and gave us a performance boost to boot. (Mostly because it's a really light protocol tailored to our use-case).

-Srdjan

[Peter Aba]

Very interesting, thank you, Srdjan! Looking forward to learning more.

--
You received this message because you are subscribed to a topic in the Google Groups "Service Weaver" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/serviceweaver/C9hbscximEQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to serviceweave...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/serviceweaver/682c8fc4-1276-422e-a0c1-bdd7910670afn%40googlegroups.com.

[Huabin Zheng]

I believe keeping all components running at the same version will works well for go and any other single language. But I wonder how cross language components talks to each other, have you some plan for this?

[Srdjan Petrovic]

Thanks Huabin, see the other thread.

We believe the cross-language can be done, as long as you run the Go and (say) Python binaries at the same version. It's something we're thinking about but have no immediate plans to support.

For now, you could possibly just use Service Weaver for your Go microservices, and setup the communication with non-Go microservices manually, i.e., as you do today?