
Learn Istio: A Service Mesh and Istio Resource List - signaltonoise
https://github.com/askmeegs/learn-istio
======
andarleen
I often find teams are legit spending more time configuring containers and the
ecosystems around them. Far more than using classic servers and more than
using server-less. Although the tech is great it seems to bloat quite a lot as
of recently. Just an observation. As a consultant i love it tho - projects
take far longer to complete.

~~~
joekrill
It's not like the underlying problems and learning curves didn't exist before
this, though. You had to learn to use and configure
Ansible/Terraform/Puppet/whatever to get your "classic" servers up and
running. You have to deal with secrets and configuration management somehow.
You have to manually deal with your dependencies and inter-dependencies, and
any possible conflicts that came along with that. Logging, service discovery,
metrics collection, etc.

And for some folks it's better to continue using that "classic server"
strategy and deal with those problems. Maybe they've already invested the time
to learn to deal with those problems, or they already have systems and
practices in place to deal with that stuff in an elegant way.

But a lot of folks are seeing the enormous benefits of containers and the
ecosystems that come with them. For them it's worth the trade-offs and the
time to take to learn how this stuff works.

Anyway, it's pretty clear at this point that this stuff isn't going away any
time soon, and in fact only becoming more and more popular and useful. Clearly
there's a reason for that.

~~~
TomMarius
When I think of before, I remember how 13 year old me "deployed" a PHP
scripted (gaming) website over FTP to be used by 10k concurrent users on a
shared hosting server that I later found out to be run by a single 16 year old
guy (that company is the country's largest hosting provider today). Everything
worked flawlessly and was fast; the hosting guy wasn't a wizard as well.

~~~
yencabulator
A lot of the complexity comes from wanting to avoid single points of failure
and building for scalability. Your shared hosting server was an orange, modern
cloud is apples.

Sometimes you want an orange.

~~~
freedomben
My thoughts as well. If you don't need high availability or any horizontal
scaling, you can still do it as simply as the GP did. These days customers
expect your site to never go down however, and that forces complexity.

------
tyingq
Is there any indication that K8S will incorporate this type of functionality
in the future? Istio seems well thought out, but it feels like it might
eventually get pushed out.

~~~
crb
There is indication that it will not, in that the teams that designed both
projects sit next to each other.

One thing that is happening: Kubernetes is designing a new set of ways to
define how traffic should be routed in a cluster, to replace Ingress
([https://kubernetes-sigs.github.io/service-apis/](https://kubernetes-
sigs.github.io/service-apis/)), and Istio is going to sit on top of those.
You'll see this in "experimental" in the upcoming Istio 1.6.

~~~
tyingq
_" the teams that designed both projects sit next to each other"_

Interesting...that's not obvious from their website or docs. Is there
somewhere I can read about the relationship between the two teams?

