We used go micro in a production system for a while at a previous company. The nicest thing I found is that it abstracts a few common pubsub systems. But besides that I found it overly abstract. It's not really that hard to write glue for messaging systems as needed and that's the only part of go micro we were using.
Show HN: Go Micro – A distributed systems development framework
41–50 of 58 posts
Re: Show HN: Go Micro – A distributed systems development framework
#42We used go micro in a production system for a while at a previous company. The nicest thing I found is that it abstracts a few common pubsub systems. But besides that I found it overly abstract. It's not really that hard to write glue for messaging systems as needed and that's the only part of go micro we were using.
You're right. It's not very useful if you're just using it for pubsub. Go Micro was always intended as a full fledged framework for distributed systems development and you'll find if you build systems at scale you end up developing a similar framework in house. For those just using messaging or a database my advise would be to go directly to that system. Abstractions are only useful when they work together collectively for the foundation of something more. In our case when everyone is building Micro services we can actually run these absolutely anywhere regardless infrastructure and share them with anyone as a reusable building block.
Re: Show HN: Go Micro – A distributed systems development framework
#43We used go micro in a production system for a while at a previous company. The nicest thing I found is that it abstracts a few common pubsub systems. But besides that I found it overly abstract. It's not really that hard to write glue for messaging systems as needed and that's the only part of go micro we were using.
You're right. It's not very useful if you're just using it for pubsub. Go Micro was always intended as a full fledged framework for distributed systems development and you'll find if you build systems at scale you end up developing a similar framework in house. For those just using messaging or a database my advise would be to go directly to that system. Abstractions are only useful when they work together collective…
Are these things necessarily opposed? It doesn't seem impossible to me that a "full-fledged framework" also addresses the most common uses cases in ways that don't leave people befuddled.
Re: Show HN: Go Micro – A distributed systems development framework
#44Earlier quoted context omitted.
You're right. It's not very useful if you're just using it for pubsub. Go Micro was always intended as a full fledged framework for distributed systems development and you'll find if you build systems at scale you end up developing a similar framework in house. For those just using messaging or a database my advise would be to go directly to that system. Abstractions are only useful when they work together collective…
Are these things necessarily opposed? It doesn't seem impossible to me that a "full-fledged framework" also addresses the most common uses cases in ways that don't leave people befuddled.
I think its really a matter of opinion and choice of development. Some people want to build it themselves, others would prefer to use a standard. Its the difference between using Spring or writing tools around Java. Using small libraries or Ruby on Rails.
Re: Show HN: Go Micro – A distributed systems development framework
#45Previous discussion: https://news.ycombinator.com/item?id=21878659
Re: Show HN: Go Micro – A distributed systems development framework
#46> Service Discovery - Automatic service registration and name resolution. Service discovery is at the core of micro service development. When service A needs to speak to service B it needs the location of that service. The default discovery mechanism is multicast DNS (mdns), a zeroconf system.
> Load Balancing - Client side load balancing built on service discovery. Once we have the addresses of any number of instances of a service we now need a way to decide which node to route to. We use random hashed load balancing to provide even distribution across the services and retry a different node if there’s a problem.
Trying to understand this a bit here. Is micro a replacement for k8s? Because I don't see any deployment capabilities here. So I'm assuming it's complementary to that. If that's the case, then I'm not sure how service discovery and load balancing would co-exist with the CNI in k8s.
Re: Show HN: Go Micro – A distributed systems development framework
#47I do a little hobby work in Go. I looked at micro several times. For some reason I felt it is bit too heavy or unnecessary complexity. It does not feel fit in go ecosystem. But may be a lot of people are liking it. I could be wrong because I have not done much real work in Go. Does anyone use it for production apps?
I think the Go community in its early years advocated for libraries over frameworks. 1. Because of the very powerful standard library which dictated the development model and culture of the community. 2. Because Go was still such a young project. I think its only natural over time that frameworks and tools emerge to simplify the development experience in every language. We realistically cannot ask people to piece tog…
Go is already an intentionally simple language with an excellent standard library, and dictates how to do things in the right way. Do we really need something on top of it? Not to mention, it's quite common that engineers like to reinvent the wheel, at least a little bit. It's just part of the fun, no one can blame them for that)
Re: Show HN: Go Micro – A distributed systems development framework
#48> Service Discovery - Automatic service registration and name resolution. Service discovery is at the core of micro service development. When service A needs to speak to service B it needs the location of that service. The default discovery mechanism is multicast DNS (mdns), a zeroconf system. > Load Balancing - Client side load balancing built on service discovery. Once we have the addresses of any number of instanc…
Not everything is k8s centric but also k8s also has very rudimentary models for discovery and load balancing, this is why things like service mesh have emerged to handle those challenges. As a framework Go Micro builds in client side discovery and load balancing which are completely separate to any third party system. You can imagine the next distributed database to be written with Go Micro which can operating independent of k8s.
In the case of k8s a lot of people swap out the load balancing for something like dns or integrate it with an envoy or linkerd considering our protocol usage is gRPC. But otherwise our service discovery acts as a central registry for all services. In a development centric environment this allows us to share feature rich metadata along with endpoints, description, and anything like team info, pager details, etc. All purely written in code rather than through yaml.
Re: Show HN: Go Micro – A distributed systems development framework
#49Earlier quoted context omitted.
I think the Go community in its early years advocated for libraries over frameworks. 1. Because of the very powerful standard library which dictated the development model and culture of the community. 2. Because Go was still such a young project. I think its only natural over time that frameworks and tools emerge to simplify the development experience in every language. We realistically cannot ask people to piece tog…
The “powerful standard library” to my experience is a myth that holds no water. Even trivial projects use external packages to handle trivial things like an HTTP server or logging. No project I saw, however small, uses just the standard library.
It's always a good idea to end up with fewer dependencies
Re: Show HN: Go Micro – A distributed systems development framework
#50Reminds me of https://github.com/atomix/atomix