3 ms·
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
by asim 6y ago
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.
- aloknnikhil 6y agoAgreed. I'm not saying that this needs to be integrated w/ k8s. I'm merely comparing it to k8s which promises the same abstraction albeit declaratively. The biggest plus point, IMO, for k8s is it makes managing deployments across physical hosts easy. So, I was asking if there was anything equivalent in micro that would help manage my deployments. And your comment on client side discovery and Load balancing partly addresses my original question. My main point here being, I don't see anything in the linked doc on why I'd choose micro over existing frameworks. EDIT: https://github.com/micro/micro/blob/master/README.md https://github.com/micro/micro/blob/master/README.md This page is more informative on why Micro over anything else. So I think this answers my second question.