Replies: 2 comments
-
I think the choice of how many services in a binary is independent of following the go-kit design patterns. You should make that decision based on other factors about how you are deploying your services and what makes sense in your system architecture. In many cases it is reasonable to start with everything in one binary until you have compelling reasons to do otherwise. Shipping and operating a single binary is usually easier than N binaries. If you follow the go-kit patterns it should be easier to split a multi-service binary into separate pieces later when you need to. Just my opinion, though. |
Beta Was this translation helpful? Give feedback.
-
I agree with Chris. One (very small) example that demonstrates these options is peterbourgon/gattaca — two microservices which are packaged as individual binaries and a single "monolith" service. |
Beta Was this translation helpful? Give feedback.
-
Hi,
I've been struggling trying to structure my services with go-kit for a while. I think the simplest question I could come up with to get on track is this: Would you typically have one or many services per binary (per main)?
Looking at the examples, the "shipping" example contains multiple services but "addsvc" only contains one service per main. Which one is the most common way to do it? Bonus question... wouldn't it be difficult to implement a grpc transport for the "shipping" example?
Thanks for your help!
Beta Was this translation helpful? Give feedback.
All reactions