Ok, this is a bit long, I apologize in advance I’ve been researching and experimenting with various challenges around managing microservices at-scale. I’ve been working extensively with Docker, CoreOS and recently Mesos.
First, I think that we need to clearly distinguish that service discovery, and request routing / load balancing are related but separate concerns. In my mind, at least, discovery is about finding a way to communicate with a service (much like a DNS query), whereas routing and load balancing concerns effectively and efficiently directing (handling) network traffic. There are multiple solutions and approaches out there, but I don’t know if any single technology could address all ‘microservices at-scale’ needs on its own effectively and efficiently. In other words - mixing multiple approaches, tools and technologies is probably the right way to go. I’m saying this because many of the existing tools come with a single technology in mind. Tools that come form the Mesos camp obviously have Mesos in mind, tools that come from Kube have Kube in mind, tools coming from CoreOS have CoreOS in mind, etc. I think It’s time to start mixing things together to really benefit from all the goodness in all the various camps. I’ll give an example: First, with respect to network traffic routing / balancing, I’ve created an HAProxy based microservice, which supports multiple data sources as inputs for auto-configuration. (BTW, I’m also experimenting with Velocity scripts for the configuration template, and i’m finding it’s a big improvement over Go scripting. Appreciate your feedback!) https://registry.hub.docker.com/u/yaronr/discovery For now just etcd and Marathon data sources are implemented. Some services will rely of CoreOS/etcd for publishing their availability, and others on Marathon. In my case, I run my Kernel cluster - Mesos-master, Marathon and a a clustered REST DHCP like service on CoreOS, and allow my customers to schedule their own microservices on Mesos/Marathon. All require discovery / routing / load balancing, the only difference is where the data comes from. Regarding DNS: again I don’t think it makes sense to have a ‘mesos-dns’ and ‘weave-dns’ and ‘kubernets-dns’ - it makes much more sense to have a single DNS that easily integrates with multiple data sources. Network is a common, low level resource, that’s used by the upper level abstractions / frameworks such as Kube, Mesos, and possibly Fleet. Therefore, if a single technology ’takes ownership’ of (parts of) this resource, that could create a technology lock down the line. I personally use Weave to abstract Netowrk altogether, and Weave DNS to provide service discovery (not network routing). (Y)
smime.p7s
Description: S/MIME cryptographic signature
