3 ms·
"I don't think this should be a thing anymore either." I routinely set my primary web services on one port, and the access to debugging and profiling informati
by jerf 7y ago
"I don't think this should be a thing anymore either."
I routinely set my primary web services on one port, and the access to debugging and profiling information is available on a web server running on an entirely different port.
In principle, this is not necessary, because everybody and everything should be able to route by URLs, and of course, everybody is using these tools and is intimately familiar with them. In practice, if I depend on that, those things tend to "fail open" and mean that if I don't explicitly block my debug routes from being exposed, it will tend to end up set up so just anybody will be able to reach them. By having by debug & monitoring on a separate port entirely, it makes it so that functionality tends to fail closed; if I don't open that port to people explicitly, it just stays entirely inaccessible, which is the failure state I'd rather have.
Also, there's a whole world of people who aren't working in an environment where there's a dozen people dedicated to maintaining a kubernetes setup for them, and are still building services that aren't built in that paradigm. Plus it seems to me like having really amazingly separable services, even ones not initially thought of as being separate, is a plus for Kubernetes rather a problem.
- hinkley 7y agoI'm talking about having to configure separate fully qualified URLs for every service in your company, with server name and port, versus talking to a proxy which knows all these mappings. When your apps are >1 the cost of maintaining these lists everywhere becomes painful. I brought up Kubernetes because Kubernetes makes you solve this out of the gate.