Learn Istio: A Service Mesh and Istio Resource List | Hacker News Reader

Learn Istio: A Service Mesh and Istio Resource List

github.com

114 pointssignaltonoise17 comments

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.

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/), and Istio is going to sit on top of those. You'll see this in "experimental" in the upcoming Istio 1.6.

"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?

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.

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.

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.

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.

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.

VCs and developer marketing have created a cottage industry around maximizing operational complexity.

I think it's the case where traditional methods are faster because any issue already has a stack overflow answer. Whereas the new tech stacks are still in the discovery phase. Containers are useful and they do simplify application deployment in terms of dependency management.

If you've never used the full k8-native stack it's easy to dismiss it. K8 recently with operators has made running distributed software as easy as configuring yaml. It's the same struggle you have with traditional stacks while you discover which config values and ansible scripts get you what you want.

Why are you defining Ansible as some script engine? "Bash on steroids" is definitely Ansible anti-pattern.

It's also the only model Ansible is reliable at.

At least I always found it hilariously problematic to replicate check state -> fix approach from other options.

> It's also the only model Ansible is reliable at.

Please elaborate more on your statement. I have folks within my team whose paycheck consists of their ability to write fully idempotent roles and playbooks. Well, even I can do this without any pain, but my expertise has shifted into Kubernetes in past years.

It's certainly possible. I used Chef for this. And spent a few years maintaining a pretty nice cookbook for a small startup.

Then tried to use Ansible to setup and maintain an OpenStack cluster. Biggest hell no so far I found in "orchestration and config management". It was a big ball of yikes and anti-patterns, plus it was extremely slow, brittle and hard to debug.

Is this Ansible's fault? No, of course not. But it's no wonder k8s seems the way forward. Having an active system that checks and maintains state and appropriate abstractions to describe apps, services, containers, volumes, network, etc. is easier than to write really idempotent playbooks.

In a way it is ansible's fault, at least from my point of view.

The reason is that the whole execution model of Ansible is essentially "a shell script in YAML form". Which makes it really, really easy to pick up for many system administrators. But it makes for (IMHO) harder time writing idempotent code, especially with some of the heavy ansible promoters being responsible for some of the worst code around (Red Hat).

A lot of organizations have legacy code floating around, and using something like a service mesh to get monitoring and tracing for that app is easier than rewriting the app to provide those features itself. I used to work on a legacy PHP app and the way it was structured pretty much precluded those things; there was no way to keep metrics in memory for Prometheus to scrape (without hacks anyway), and there was no way to get it to emit a UDP packet with tracing information after writing a body to the browser (the framework just kills the script at that point). I just put Envoy in front of it and suddenly we could see "what fraction of requests are timing out" or "what endpoints are returning 500 errors". The idea of Istio is that it just does that stuff automatically; it can use the k8s configuration that you already wrote to add things like observability hooks, smarter routing (avoid cascading failure modes without writing your own "suicide pact" controller), etc.

I know everyone on HN has an app that they deploy by rsyncing some scripts to a server, and if they're on vacation they don't do releases, and if there's an error the script sends them an SMS saying "I'm broken", but that really stops scaling past a certain number of employees and traffic level, and some of these things that people write articles about are for those cases. Maintaining 10 servers is a lot closer to maintaining a million servers than it is to maintaining 1 server; people have written tools with that use case in mind. If you have one employee that maintains an app that runs on on server, you can probably ignore all of this stuff. If you are bigger than that, you might want to say "maybe this can help" rather than dismissing it as being too complicated. The complexity comes from "we're big enough to need 100 developers, and it would be nice if they could all deploy and monitor their own product", not from "let's find some unnecessary complexity".

(If you look at how people are making money in the software industry right now, you'll see that having organizations run their own apps is apparently challenging. People will pay thousands a month for their cloud provider or a third party to run open source software for them on a server that costs them less than a hundred dollars a month. Things like Kubernetes are designed to make running that stuff on your own a possibility. Someday I'd like to do a little contest where I pay you $100 if you can run some sort of computer program for 6 months continuously. I doubt that many people on HN would be successful; they just never built any infrastructure for running computer programs. They have their one app running kind of okay, and that's the best they can do. It's actually scary that nobody sees this as a problem. )

> A lot of organizations have legacy code floating around, and using something like a service mesh to get monitoring and tracing for that app is easier than rewriting the app to provide those features itself. I used to work on a legacy PHP app and the way it was structured pretty much precluded those things; there was no way to keep metrics in memory for Prometheus to scrape (without hacks anyway), and there was no way to get it to emit a UDP packet with tracing information after writing a body to the browser (the framework just kills the script at that point). I just put Envoy in front of it and suddenly we could see "what fraction of requests are timing out" or "what endpoints are returning 500 errors". The idea of Istio is that it just does that stuff automatically; it can use the k8s configuration that you already wrote to add things like observability hooks, smarter routing (avoid cascading failure modes without writing your own "suicide pact" controller), etc.

Indeed, but specifically to PHP services such as newrelic require a two line config for a provided PHP extension, and within minutes you get a nice dashboard with traces down to the offending line, sql statements with parameters, performance bottlenecks and service maps. indeed the price is privacy but the time to implement is little and the benefits are great.

I am not sure about the contest for running 6 months continuously would be difficult to win - had loads of apps running on servers with an impressive uptime of more than one year, with hot releases that caused no downtime, and the traffic was pretty high.

Just to reiterate, the tech is great, but for _some_ team sizes it will add a lot more work load. My fortune 100 client is suddenly discovering that they need to hire a lot more devops to accomodate such infrastructure, yet we could easily have set up a scalable robust infrastructure using a classic set-up.

Does this mean there are no benefits to kubernetes? Not at all. I love the idea of containers and the natural follow up of service mesh. But they require more staff. My observation is purely related to the sweetspot on the staff and benefit graph.

Reply on news.ycombinator.com