10 ms·

Go Micro – A Go microservices development framework

143 points by chuhnk 7y ago

tyingq 7y ago
Seems like a sort of light service mesh, but delivered from within the app, and very straightforward. I'll have to look at mDNS, had heard of it, but never read into it.
- bradhe 7y ago
  I agree with your sentiment—seems like a kinda light weight fully integrated service mesh.
- arcticbull 7y ago
  mDNS has been around forever (2002/macOS 10.2) but probably best known in the Apple ecosystem as Bonjour [1,2]. Much of Apple's big software and hardware products integrate it in some way. [1] https://developer.apple.com/bonjour/ https://developer.apple.com/bonjour/ [2] https://en.wikipedia.org/wiki/Bonjour_(software) https://en.wikipedia.org/wiki/Bonjour_(software)
  - tyingq 7y ago
    Sure. The last Apple product I owned was an Apple II, so Bonjour is similarly something I've heard in passing, but never looked closer at.
ainar-g 7y ago
Probably mostly off-topic, but every time I see the words “Go” and “framework” together in a sentence, I can't help but chuckle. Go is, idiomatically, a very anti-framework and pro-library language. And I think that that's a good thing. The closest thing idiomatic Go has to frameworks are the stdlib's “interface packages” like package image or package database/sql/driver, which are amazing because they make it easier to create an actual ecosystem instead of a network of incompatible frameworks. Anyone who wants to create a “framework” for go should instead learn from those packages and try to define a set of interfaces which work together to achieve a goal.
- diehunde 7y ago
  I've seen some frameworks for other languages that are actually a collection of libraries and you select the ones that you need. Isn't the same with these Go frameworks?
  - ainar-g 7y ago
    I've seen that happening, but there is always a risk of the old “gorilla holding the banana”[1] problem. That is, the library that you use depends on a library you don't really need, which in turn depends on another one, etc. Once you had reached gopkg.in/yaml.v2, you've already lost. [1] https://www.johndcook.com/blog/2011/07/19/you-wanted-banana/ https://www.johndcook.com/blog/2011/07/19/you-wanted-banana/
    - weberc2 7y ago
      This isn’t meaningfully true. The monkey holding the banana is an example of standard practice OO design. The standard practice for developing a suite of libraries in Go (or indeed in any non-OO language) is to decouple them. They can still work together as a suite of tools, but they can also be used independently. Not sure if this is the best example, but I would routinely use gorilla/mux on its own.
  - loopz 7y ago
    Starting by choosing a framework is very anti-"Go Way". Instead, you could start with a minimal prototype, learn what features you're gonna need, implement themselves or find a library that can complement your code. The last resolution, would be to fetch a fully-fledged framework. You would at that point have learned from experience how to use it as a decoupled amplifier. It's not that you can't do it, it's just that the entire ecosystem and excellent stdlib encourages you to develop your own code, and makes it very easy to refactor, catching most non-logical bugs at compile time if there are any.
    - diehunde 7y ago
      Yeah but a lot of prototypes will have similar requirements. Let's say I need to build an app I already know will need to route requests, authentication, versioning, some sort of sql layer to not write SQL code, etc. I don't see a problem with starting with a framework for that. I'm new to Go so maybe all of that it's extremely easy to do without any library, in which case I would be wrong.
runlevel1 7y ago
mDNS is an interesting choice for service discovery. Neat idea for local development, but probably not great in production. I believe most cloud providers don't support multicast, meaning mDNS would not work there. It's also quite slow and/or very chatty in large networks. Looks there is support for other service discovery mechanisms via plugins, though.
- tyingq 7y ago
  Oh, yeah...that is probably limiting. A quick scan seems to show Digital Ocean specifically drops multicast, and AWS/GCP/Azure have varying levels of "unsupported". Would it work with Flannel/Calico, etc? Inefficient, but probably okay since it would be just service resolution. Edit: Looks like no for Calico, Yes for recent Flannel, but Weave Works is probably a better choice, designed to support it from the start.
  - alphakilo 7y ago
    mDNS is only for local development. You can use a variety of tools such as Consul. Check out micro.mu for more info :)
    - tyingq 7y ago
      Ahh. Might be a good update for the linked page.
- e12e 7y ago
  Ah, multicast such a great idea, and so hard to use at scale. For wiw multicast/mDNS works fine on top of ZeroTier. Although, if the underlying network doesn't, I assume you get a lot of overhead (ie: it probably wouldn't be very beneficial to try and share a video stream via multicast on top of ZeroTier on top of a network without multicast support).
- bketelsen 7y ago
  mDNS is intented for local development, not production usage. It simply enables one to develop without installing a more production-worthy solution like Consul.
bradhe 7y ago
This looks pretty new and under developed. In a world of service mesh proliferation not sure where this fits as there is some feature overlap. > PubSub is built in as a first class citizen for asynchronous communication and event driven architectures. Would be interested to see how this is implemented and what it’s consistency and reliability dynamics are.
- alphakilo 7y ago
  I think the largest issue is a lack of documentation. Go-Micro is ~5 years old, so definitely not new. Pub Sub works pretty well; check out the PubSub example in micro/examples.
  - gdm85 7y ago
    > Event notifications are a core pattern in micro service development. I might agree, but it's not the only core pattern. What if one needs (distributed) transactions? The fact that pub/sub is advertised as a prominent feature makes me think that asynchronous models are preferred, at least in design and philosophy of the framework.
lhopki01 7y ago
Have care with using this. We were using it and repos were renamed and moved causing all sorts of issues.

143 points by chuhnk 7y ago

Seems like a sort of light service mesh, but delivered from within the app, and very straightforward. I'll have to look at mDNS, had heard of it, but never read into it.

bradhe 7y ago
I agree with your sentiment—seems like a kinda light weight fully integrated service mesh.
arcticbull 7y ago
mDNS has been around forever (2002/macOS 10.2) but probably best known in the Apple ecosystem as Bonjour [1,2]. Much of Apple's big software and hardware products integrate it in some way. [1] https://developer.apple.com/bonjour/ https://developer.apple.com/bonjour/ [2] https://en.wikipedia.org/wiki/Bonjour_(software) https://en.wikipedia.org/wiki/Bonjour_(software)
- tyingq 7y ago
  Sure. The last Apple product I owned was an Apple II, so Bonjour is similarly something I've heard in passing, but never looked closer at.

ainar-g 7y ago

Probably mostly off-topic, but every time I see the words “Go” and “framework” together in a sentence, I can't help but chuckle. Go is, idiomatically, a very anti-framework and pro-library language. And I think that that's a good thing. The closest thing idiomatic Go has to frameworks are the stdlib's “interface packages” like package image or package database/sql/driver, which are amazing because they make it easier to create an actual ecosystem instead of a network of incompatible frameworks. Anyone who wants to create a “framework” for go should instead learn from those packages and try to define a set of interfaces which work together to achieve a goal.

diehunde 7y ago
I've seen some frameworks for other languages that are actually a collection of libraries and you select the ones that you need. Isn't the same with these Go frameworks?
- ainar-g 7y ago
  I've seen that happening, but there is always a risk of the old “gorilla holding the banana”[1] problem. That is, the library that you use depends on a library you don't really need, which in turn depends on another one, etc. Once you had reached gopkg.in/yaml.v2, you've already lost. [1] https://www.johndcook.com/blog/2011/07/19/you-wanted-banana/ https://www.johndcook.com/blog/2011/07/19/you-wanted-banana/
  - weberc2 7y ago
    This isn’t meaningfully true. The monkey holding the banana is an example of standard practice OO design. The standard practice for developing a suite of libraries in Go (or indeed in any non-OO language) is to decouple them. They can still work together as a suite of tools, but they can also be used independently. Not sure if this is the best example, but I would routinely use gorilla/mux on its own.
- loopz 7y ago
  Starting by choosing a framework is very anti-"Go Way". Instead, you could start with a minimal prototype, learn what features you're gonna need, implement themselves or find a library that can complement your code. The last resolution, would be to fetch a fully-fledged framework. You would at that point have learned from experience how to use it as a decoupled amplifier. It's not that you can't do it, it's just that the entire ecosystem and excellent stdlib encourages you to develop your own code, and makes it very easy to refactor, catching most non-logical bugs at compile time if there are any.
  - diehunde 7y ago
    Yeah but a lot of prototypes will have similar requirements. Let's say I need to build an app I already know will need to route requests, authentication, versioning, some sort of sql layer to not write SQL code, etc. I don't see a problem with starting with a framework for that. I'm new to Go so maybe all of that it's extremely easy to do without any library, in which case I would be wrong.

runlevel1 7y ago

mDNS is an interesting choice for service discovery. Neat idea for local development, but probably not great in production. I believe most cloud providers don't support multicast, meaning mDNS would not work there. It's also quite slow and/or very chatty in large networks. Looks there is support for other service discovery mechanisms via plugins, though.

tyingq 7y ago
Oh, yeah...that is probably limiting. A quick scan seems to show Digital Ocean specifically drops multicast, and AWS/GCP/Azure have varying levels of "unsupported". Would it work with Flannel/Calico, etc? Inefficient, but probably okay since it would be just service resolution. Edit: Looks like no for Calico, Yes for recent Flannel, but Weave Works is probably a better choice, designed to support it from the start.
- alphakilo 7y ago
  mDNS is only for local development. You can use a variety of tools such as Consul. Check out micro.mu for more info :)
  - tyingq 7y ago
    Ahh. Might be a good update for the linked page.
e12e 7y ago
Ah, multicast such a great idea, and so hard to use at scale. For wiw multicast/mDNS works fine on top of ZeroTier. Although, if the underlying network doesn't, I assume you get a lot of overhead (ie: it probably wouldn't be very beneficial to try and share a video stream via multicast on top of ZeroTier on top of a network without multicast support).
bketelsen 7y ago
mDNS is intented for local development, not production usage. It simply enables one to develop without installing a more production-worthy solution like Consul.

bradhe 7y ago

This looks pretty new and under developed. In a world of service mesh proliferation not sure where this fits as there is some feature overlap. > PubSub is built in as a first class citizen for asynchronous communication and event driven architectures. Would be interested to see how this is implemented and what it’s consistency and reliability dynamics are.

alphakilo 7y ago
I think the largest issue is a lack of documentation. Go-Micro is ~5 years old, so definitely not new. Pub Sub works pretty well; check out the PubSub example in micro/examples.
- gdm85 7y ago
  > Event notifications are a core pattern in micro service development. I might agree, but it's not the only core pattern. What if one needs (distributed) transactions? The fact that pub/sub is advertised as a prominent feature makes me think that asynchronous models are preferred, at least in design and philosophy of the framework.

lhopki01 7y ago

Have care with using this. We were using it and repos were renamed and moved causing all sorts of issues.