Hi, While Cap'n Proto is certainly capable of replacing gRPC here, obviously Google has a lot more people working on the gRPC ecosystem, and so more infrastructure has been built out there. With Cap'n Proto you will have to do more things yourself. If your needs fit well into the model supported by common gRPC infrastructure, this may not be worth it to you. On the other hand, if you have a more unusual use case, then you might find you have to build custom solutions either way, in which case Cap'n Proto's more fundamental benefits (serialization performance and object capabilities) may make it a better choice.
Cap'n Proto is especially powerful for: * State*ful* services, where nodes across a cluster need to control and hold on to the state of other nodes. For example, Sandstorm.io (startup I founded) built a cluster-scaleable version of Sandstorm called "Blackrock" which is itself a container orchestrater designed to run many heterogeneous container instances on behalf of individual end users. This is a fundamentally stateful thing, since each container is serving a specific user with specific state and can't simply be interchanged with others. Using Cap'n Proto as the underlying communications protocol made this a lot easier to manage. * IPC use cases, where services are running on the same machine and can communicate via unix sockets or even shared memory. Cap'n Proto's CPU performance shines here (while its somewhat higher bandwidth usage becomes irrelevant). Running multiple services on the same machine isn't really in style right now, but my current employer, Cloudflare, does a lot of it -- every one of the machines in our edge network runs an identical set of services so that any one machine can handle any kind of request on its own. But if you're doing a standard kubernetes microservices thing... probably going with gRPC is going to be a lot easier right now. -Kenton On Wed, Sep 5, 2018 at 7:18 AM, shinzui <[email protected]> wrote: > Hi, > > I just started evaluating Cap'n Proto as an alternative to gRPC in a > microservice architecture, and I am having a hard time finding material on > deploying services that are using Cap'n Proto RPC. Is anyone using Cap'n > Proto RPC with kubernetes and a service mesh? How do you load balance your > services? How do you capture metrics? Is the protocol suitable for > cloud-native apps? > My naive first look makes me think that it's not suitable for a > microservice architecture with a lot of stateless services. I would > appreciate any pointers to prove me wrong. > > Thank you. > > -- > You received this message because you are subscribed to the Google Groups > "Cap'n Proto" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > Visit this group at https://groups.google.com/group/capnproto. > -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/capnproto.
