Go-kit vs Service Meshes

[joao.o...@real-digital.de]

Hi,

I've started a team project where we've been implementing a couple of micro-services using Go.
We are in a phase of many discoveries, building a proof of concept.
Yet, looking to pave the way for production, we are already setting microservices in k8s, looking at CI/CD and studying in advance solutions to the many micro-service headaches that are to be faced once we scale out of proof of concept.

In this scenario, I've been doing some studies the past couple of days about go-kit, go-micro and service meshes. 

In special, I really like the code structure that go-kit advocates and I already have examples in our code that justify the adoption of the portrayed separation of concerns (it all started when we wanted to enable users to call the same microservice method from both Http and gRPC handlers).

Yet, I came across this service mesh concept, and I couldn't find a good piece of opinion that compares go-kit and service mesh. Something that could help me form my understanding of the subject.
I read that go-kit aimed at being a sort of Finacle for Go microservices, but with service meshes coming in, how can go-kit and a service mesh co-exist?

My initial understanding is that, with go-kit, we would have - within the borders of a microservice - layers responsible for circuit breaking, retrying, load balancing, service registration... all around the main core business logic. However, service meshes such as Conduit or Istio seem to strip this responsibility away from within the borders of a microservice to give it to a sidecar. And, in principle, I love it, seems that a service mesh abstracts away from the microservice development a bunch of boilerplate code that likely a developer shouldn't have to copy paste between services. Things that are not really on the scope of the application, don't belong to the app developer (business logic)... but are more a responsibility of some sort of platform developer (ops).

In our project, however, I have examples of functionality that could still benefit from the go-kit separation of concerns approach, even while using a service mesh. Features such as caching and goroutine load balancing for a given function, and application instrumentation (e.g: cache hits/misses). What I still consider as application-level features.

Finally, I would like to read other opinions about this topic: the space that service meshes take away from go-kit, what space they clearly don't (a.k.a where go-kit shines comparatively) and what is a gray area.

Thanks for your attention,

John :)