4 ms·

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 rewri

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. )

andarleen 7y ago
> 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.

andarleen 7y ago

> 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.