
Containers, microservices, and service meshes - aberoham
http://jpetazzo.github.io/2019/05/17/containers-microservices-service-meshes/
======
stevenacreman
I keep a Google sheet updated with feature differences between LinkerD,
LinkerD2, Consul Connect and Istio.

[https://docs.google.com/spreadsheets/d/1OBaKrwR030G39i0n_47i...](https://docs.google.com/spreadsheets/d/1OBaKrwR030G39i0n_47i-hzcFJ966bJjGArXVKX39_k/edit#gid=0)

From my own experience I've had some great success with LinkerD in the past on
Mesos DC/OS.

Since moving companies, and switching to Kubernetes, we've yet to deploy any
service mesh into production.

The blog from Jerome highlights many of the benefits already.

From my perspective the bigs ones in the past were:

    
    
        - Tracing (with Zipkin)
        - Retries which removed or fixed dodgy app reconnect logic
        - Time series metrics in LinkerDViz showing realtime rates and latency and errors between services
    

The reason we haven't used any service mesh at my current company is mostly
based on stability concerns.

Istio gets all of the cool press attention and blogs written about it. Yet,
you also read a lot of warnings about it always being 6 months away from being
really robust. Even at version 1 we read some horror stories about obscure
bugs showing up in fairly standard use cases.

Connectivity between services is too scary to gamble on. It's a similar deal
with CNI (we're still on Calico despite arguably cooler stuff being out there)
and Ingresses (still on ingress-nginx).

AWS have a service mesh that is probably going to be the one we trial next at
work.

Improved observability and retries would definitely be of benefit on our
current platform. Another driving factor is also our security team wanting
mutual TLS between services.

~~~
coredog64
Does anyone else think mTLS on the public cloud is a waste of CPU cycles (and
therefore money)?

~~~
rroeserr
Yes - esp if you have a sidecar which speaks in-securely to your application.
Data theft happens from application issues, or employees with access stealing
things - not because of unencrypted traffic in a secure network.

------
discreteevent
Has anyone got an opinion on what makes a service mesh better than using a
message broker for most distributed systems? Is it performance? Is it that
http has become the lowest common denominator and people just don't want to
use any other communication protocol?

~~~
scraegg
If you see an airplane that flies you might conclude airplanes are a good
transportation pattern. But if you see there's a boat, that promises to fly,
and you see that people taped a lot of helicopters onto it to make it fly,
then probably you would conclude that boats are bad at flying.

Message Brokers are the airplanes. Even if you can't understand how they work
you will see that many companies use them who really rely on distributed
systems working, eg telephone companies, banks, trading companies.

Service Meshes try to solve a problem that K8s was meant to solve in the first
place. So K8s is the boat and Service Mesh is the attached helicopter. By
itself it might be a good idea to use it, but the way things are taped
together right now it's just an anti-pattern.

If you don't have a pointy-haired boss forcing you to use it, then it's
probably better to avoid the whole thing.

I'd rather see how far the development around k8s-less pods with podman will
go and take care of the distributed architecture of my systems myself.

~~~
pm90
Kubernetes is a platform, it lets you do whatever the f you want to. Service
meshes are one thing to build on top of the platform.

~~~
scraegg
You can do what you want even without k8s.

The reason to use a tool is to make a task simpler or take a task out of your
hands in most cases but the rare edge case. For instance grep makes it easier
to go to a file to find a certain line.

If you need to know networking, storage, microservice architecture yourself
you don't need any tools.

In k8s you need to know all this, and on top you need to know k8s to achieve
the same thing. And then you either need to write k8s plugins or also
additionally know all the k8s plugins and wether any of them will actually
solve the problem you have.

------
nickstinemates
Jerome, I am always amazed at the quality and depth of your knowledge. Thanks
for the lesson.

~~~
WestCoastJustin
+1 for Jerome. Love reading these.

Nick, long time no see. Hope thing are well. Amazing who you find browsing
these threads :)

~~~
nickstinemates
<3

------
kissgyorgy
Honestly I'm learning every single day for 6 years, but there are a bunch of
words I simply don't know and a bunch of abstractions I don't understand the
need described in this article. The future (maybe even the present) looks
unnecessary complex to me.

~~~
folkrav
The "old" way still works, and won't stop doing so. If your deployment needs
are not too fancy, these are still easier to reason with and maintain, too.
e.g. a one-man operation who manages a handful of mom-and-pop businesses'
websites, it makes no sense to go too fancy. A simple git clone on a simple
LAMP setup, or hell, a shared host through FTP, works just fine.

Introducing these things prematurely are just asking for trouble. They come
with their share of complexity and overhead. However they do solve some
problems. In a lot of cases, if you don't know about these things yet, you
probably don't need to.

------
peterwwillis
I think where service mesh goes wrong is when the design is monolithic or
proprietary, where your whole cluster usually needs to use one particular set
of compatible products.

At its core, a service mesh is just a complicated, multi-tier, higher-level
router and VPN. For TCP/IP routing there's lots of protocols, from the local
level to LAN to WAN and beyond. Many of them are designed for specific use
cases. But even so, traditional routers aren't centralized, they don't care
what other routers they connect to, and they all speak common languages,
transfer information, make independent decisions, and act in isolation. This
is a really good design that I think service mesh should utilize.

I think what we really want from a service mesh is a router for applications
with a standard protocol that doesn't share state (or at least, state is
asynchronous and non-consistent, and only verified at the end of an operation,
similar to IP routing). Additional features are needed, and those can be
codified into the protocol. That would make the system more resilient to
change and compatible with different products, rather than now where each
service mesh software is basically a unique incompatible router and protocol.

------
thewarrior
For someone who has no idea what most of this means is there some place to get
started understanding this stuff ?

~~~
pm90
No, it is not.

------
jacques_chester
> _Istio was designed to work with Kubernetes; and if you want to use it
> outside of Kubernetes, you will need to run an instance of the Kubernetes
> API server (and a supporting etcd service)._

Istio is used in Cloud Foundry without needing a Kubernetes master.

------
mrbonner
I tried to read a few articles on service mesh but then still don’t understand
what it tries to solve. Is it just another niche technology (I.e nodejs
ecosystem)?

~~~
Bombthecat
It solves the team / management problem,that for example.you have five teams
and five to eight micro services. Maybe even more by pulling data from outside
sources.

Those five teams iterate over there service and product. And maybe even the
outside service iterates there product.

How do you make sure that everyone is on the same page and is using the right
version and that the right service talks to the rights service in the right
way? Especially the outside service for example?

