[darkwater]

> - you don't want developers to worry about details such as DNS and networking and topologies.

Did they need to know this before Kubernetes? I've been in the trade for over 20 years and the typical product developer never cared a bit about it anyway.

> - you don't want to be tied to a specific app framework.

Yes and no. K8s (and docker images) indeed helps you in deploying more consistently different languages/frameworks but the biggest factor against this is in the end still organizational rather than purely technical. (This in an average product company with average developers, not super-duper SV startup with world-class top-notch talent where each dev is fluent in at least 4 different languages and stacks).

[motorest]

> Did they need to know this before Kubernetes?

Yes? How do you plan to configure an instance of an internal service to call another service?

> I've been in the trade for over 20 years and the typical product developer never cared a bit about it anyway.

Do you work with web services? How do you plan to get a service to send requests to, say, a database?

This is a very basic and recurrent usecase. I mean, one of the primary selling points of tools such as Docker compose is how they handle networking. Things like Microsoft's Aspire were developed specifically to mitigate the pain points of this usecase. How come you believe that this is not an issue?

[darkwater]

You just call some DNS that is provided by sysadmins/ops. The devs don't know anything about it.

[haiku2077]

I used to be that sysadmin, writing config to set that all up. It was far more labor intensive than today where as a dev I can write a single manifest and have the cluster take care of everything for me, including stuff like configuring a load balancer with probes and managing TLS certificates.

[darkwater]

Nobody is denying that. But GP was saying that now with k8s developers don't need to know about the network. My rebuttal is that devs never had to do that. Now maybe even Ops people can ignore some of that part because many more things are automated or work out of the box. But the inner complexity of SDNs inside k8s in my opinion is higher than managing your typical star topology + L4 routing + L7 proxies you had to manage yourself back in the days.

[motorest]

> But GP was saying that now with k8s developers don't need to know about the network. My rebuttal is that devs never had to do that.

The only developers who never had to know about the network are those who do not work with networks.

[otterley]

I think a phone call analogy is apt here. Callers don’t have to understand the network. But they do have to understand that there is a network; they need to know to whom to address a call (i.e., what number to dial); and they need to know what to do when the call doesn’t go through.

[dilyevsky]

Devs never had to do that because Moore's Law was still working, the internet was relatively small, and so most never had to run their software on more than one machine outside of some scientific use-cases. Different story now.

[p_l]

Which is why you often had to wait weeks for any change.

Hell, in some places, Ops are pushing k8s partially because it makes DNS and TLS something that can be easily and reliably provided in minimal amount of time, so you (as a dev) don't have a request for DNS update wait 5 weeks while Ops are fighting fire all the time.

[motorest]

> You just call some DNS that is provided by sysadmins/ops.

You are the ops. There are no sysadmdins. Do you still live in the 90s? I mean, even Docker compose supports specifying multiple networks where to launch your local services. Do you ever worked with web services at all?