
Developments around Microservices, API Gateways, Kubernetes and Service Mesh - sickeythecat
https://glasnostic.com/blog/2018-review-predictions-microservices-api-gateways-kubernetes-service-mesh
======
ivan_ah
In case you're wondering what a service mesh is, this seems to be one
explainer: [https://istio.io/docs/concepts/what-is-
istio/](https://istio.io/docs/concepts/what-is-istio/)

Things that this seems to do are application level end-to-end authorization /
authentication, load balancing, monitoring, etc.

Not sure if it does service discovery or you'll still need something else for
that.

~~~
labrabbit
Full disclosure: I work for Glasnostic.

Service mesh encapsulates the complexities of distributed service-to-service
communication so you don't have to deal with them. There are a few options
(not just Istio) and all approach the problem in a different way.

I have written about this here: [https://glasnostic.com/blog/what-is-a-
service-mesh-istio-lin...](https://glasnostic.com/blog/what-is-a-service-mesh-
istio-linkerd-envoy-consul) and here: [https://glasnostic.com/blog/should-i-
use-a-service-mesh](https://glasnostic.com/blog/should-i-use-a-service-mesh)

~~~
wereHamster
What advantages does Istio give you over orchestrating the services using k8s
"Service" resources? To me it seems that k8s already provides mechanisms to
proxy requests to the correct backends (pods). Why would I use Istio?

~~~
wora
The short answer is layering. For example, to support mutual TLS, you need a
system that distributes and rotates TLS certs to different nodes. If we don't
want to add to many features to Kubernetes, then we need another layer. That
becomes Istio or something like Istio. That is roughly how Istio came to exist
in the first place, as it models after several Google internal systems that
are on top of Borg instead of being part of Borg.

------
potrei
Apart from the specific technology used, it's important to change the way
applications are designed and implemented. I saw many projects in trouble
because they merely split a monolithic application into small pieces, without
applying a new model of design and thinking. If you approach micro-services
development without changing your mind first, you will fail.

~~~
rasteau
Amen!

My last three companies were moving from a monolith to microservices. In every
case, the rationale for the move was little more than "monolith development is
slow, therefore microservices".

Unfortunately for all of them, the true reasons for the slow development was
poor separation of concerns, insufficient and brittle tests, and years of
accumulated hacky shortcuts to ship new features "faster".

The folks pushing the microservice panacea were "proven right" in that
development was much faster... initially. Without years of cruft in their way,
devs were able to churn out new stuff (after a significant time spent ramping
up on infrastructure code).

Eventually, and in every case, the fundamental flaws resurfaced, this time
increasing in severity now that changing the system often required multiple
service changes. As well, a host of new kinds of problems emerged: distributed
transactions, network failures, client/server versioning, debugging across
services, etc.

I'm now a microservice skeptic. Whatever your solution, it should be at the
same "level" as the problem. A massive change in technical architecture will
not solve the accumulated cost of your poor engineering quality choices.

~~~
potrei
Yes, I agree. That's why I said that it's necessary to change the way
application are designed. And, of course, there's no silver bullet. Sometimes
micro-services architecture is not the way to go.

------
germainelong
Sadly Kubernetes is still vendor locked in - although you have a selection of
them. Average Joe cannot install Kubernetes on their pool of commodity
dedicated servers or VPS servers because there is no ingress that works with
already assigned IP addresses. If you buy a dedicated server you get a block
if IPs and there is no way to assign them to ingress. If such thing was
developed, people could ditch expensive cloud providers in favour of order of
magnitude cheaper dedicated servers.

~~~
ccmcarey
What? This makes no sense.

You absolutely can bootstrap your own cluster of servers running K8s.

------
snupples
I feel that service mesh integration in k8s is still very immature. Be aware
that running any sidecar model service mesh requires setting elevated
permissions on the entire pod. Your pod security policy will need to allow
NET_ADMIN at the very least, since service meshes mostly operate by
manipulating iptables rules in the pod. Often there are other elevated
permissions required. Usually this means people are setting elevated
permissions globally on the default svc account, which is scary.

------
pritambarhate
It will be amazing if someone knowledgeable here can share their experience
with Linked 2.0, Istio and Envoy.

~~~
boudin
Envoy, if I'm not mistaken, is a sidecar proxy that is used by Istio.

The equivalent for Linkerd 2 is Conduit (that was its own app before and now
is entirely part of Linkerd 2).

From what I've seen, Linkerd 2 doesn't feature as much features as Istio or
Linkerd 1 for now (no circuit breaker for example). From the few issues I've
seen on Github, it seems a bit immature to be used in a production
environment.

Between the fact that I've just started looking into that last month and that
it changes at a rate that is really hard to follow, I'm might be wrong...

------
hmexx
I’ve never read an article with as many words (brands / technologies) that I
have not heard of..

I must be losing touch with tech!

~~~
jbigelow76
Javascript Community: "Angular, React, Vue, TS, webpack, PWAs, yarn, NPM...
nobody can keep up with all this change!"

DevOps Community: "Hold my beer."

~~~
barbecue_sauce
DevOps, SecOps, DevSecOps, DataOps, GitOps...

