[haggy]

Using this framework on top of kubernetes (which is itself another framework used to managed microservices) sounds like an operational nightmare. Kubernetes is already filled with operational pitfalls so adding more layers on top only increases complexity.

I think Go-Micro looks cool but I wouldn't suggest layering this much more than you already are. Complexity is death for distributed systems so minimizing complexity means maximizing reliability for the systems.

[chuhnk]

I'm sorry you've misunderstood what this is. This is a Go Framework for microservices development. It's what you use to write services. It's like Rails or Spring. Kubernetes is for running applications not writing them. Kubernetes no opinions about how you write software. We encapsulate the underlying infrastructure and provide a framework for the developer to literally write business logic.

[andy9775]

As mentioned by the other commenter one of the big features is service discovery and load balancing - it seems like micro is stepping on k8s feet here and is a bit more than just a framework.

I could see using micro on bare metal (with all features) but trying to get the grasp of mixing with k8s (with all of micro's features). I'm assuming no one is using micro's load balancing and service discovery over k8s? I guess the broader question is, is micro highly coupled to all of its features/functions or is picking and pulling parts of it workable?

[PhilippGille]

The first two features listed on the README are "service discovery" and "load balancing", which is probably where the question is coming from.

[andy9775]

yup.

Micro seems like a framework + platform for running micro services (ideally on bare metal). (Not saying there's anything wrong with that though)