5 ms·

> They just didn't know what a gateway, NAT, or subnet is. If you ask me, they shouldn't have to, in the same way that you probably don't know how to diagnose

> They just didn't know what a gateway, NAT, or subnet is. If you ask me, they shouldn't have to, in the same way that you probably don't know how to diagnose a coax cable problem. The major public clouds all have completely software-defined networks (SDNs), and concepts like subnets are basically emulated for the sake of legacy systems. Why would we want subnets, like... at all? Why can't all systems just have an IP address and use point-to-point communications? That's literally what the underlying SDN does with the packets anyway! The subnets and routes you see don't map 1:1 to the underlying network. The packets are stuffed inside a VXLAN packet and routed between random hypervisors scattered randomly across multiple buildings. Just give up the pretence, give everything an system-assigned public-routable IPv6 address and be done with it. Better yet, auto-register everything in a private DNS zone and auto-generate internal use SSL certs too. The amount of wiring we do manually is just insane, just so that Azure and Amazon can help greybeards pretend that they're operating a Cisco router and need to stand in line to file the paperwork required to get an SSL certificate.

bandrami 3y ago
> you probably don't know how to diagnose a coax cable problem No, that was definitely part of the sysadmin job description ~25 years ago, both line discipline and physical medium problems (I had a TDR and a fiberglass fish at my desk for my first sysadmin job and was kind of bummed to find out that isn't remotely normal anymore)
groestl 3y ago
> and concepts like subnets are basically emulated for the sake of legacy systems. Until you scale up a Kubernetes Cluster so far that the abstractions begin to leak.
api 3y ago
Problem is that all those systems are proprietary to individual clouds. Congratulations folks! We undid several decades of progress and went back to the 1960s and 1970s when software can only run on the specific mainframe for which it was written.
- ThunderSizzle 3y ago
  Which is why I don't write for the cloud. My personal stuff goes into a dedicated linux server setup with docker compose, and my work stuff is all hosted on windows servers. I'd prefer switching those windows servers to Linux, but we're too integrated with Microsoft at this point.
  - api 3y ago
    It’d be easier to swap those Windows servers out for Linux than it is to migrate the typical cloud native application from one cloud to another. The cloud is the most closed, most locked in, most rent extraction oriented computing paradigm since the pre-minicomputer mainframe era. It’s really a return to that era. Computing tends to cyclically reinvent wheels. I suppose next we will reinvent minis, micros, LANs, etc.
- threecheese 3y ago
  I think you’ve stumbled on the solution there - *something* happened between the 70s and today to address that thing from the 1960s, and it was motivated by capital-seeking. There’s a high probability that it will happen again, and if it does not then it’s likely the market didn’t demand it. Or, the world is just one big corporation and we’re all screwed. One of those.
immibis 3y ago
The problem with that idea is that it requires every router to know about every system on the network. Unless they abandon Ethernet and replace it with MPLS source routing, which maybe they should. You'd still have a maximum subnet size, because the hardware firewall that would still have to be in front of every server would have a limited capacity.

bandrami 3y ago

> you probably don't know how to diagnose a coax cable problem No, that was definitely part of the sysadmin job description ~25 years ago, both line discipline and physical medium problems (I had a TDR and a fiberglass fish at my desk for my first sysadmin job and was kind of bummed to find out that isn't remotely normal anymore)

groestl 3y ago

> and concepts like subnets are basically emulated for the sake of legacy systems. Until you scale up a Kubernetes Cluster so far that the abstractions begin to leak.

api 3y ago

Problem is that all those systems are proprietary to individual clouds. Congratulations folks! We undid several decades of progress and went back to the 1960s and 1970s when software can only run on the specific mainframe for which it was written.

ThunderSizzle 3y ago
Which is why I don't write for the cloud. My personal stuff goes into a dedicated linux server setup with docker compose, and my work stuff is all hosted on windows servers. I'd prefer switching those windows servers to Linux, but we're too integrated with Microsoft at this point.
- api 3y ago
  It’d be easier to swap those Windows servers out for Linux than it is to migrate the typical cloud native application from one cloud to another. The cloud is the most closed, most locked in, most rent extraction oriented computing paradigm since the pre-minicomputer mainframe era. It’s really a return to that era. Computing tends to cyclically reinvent wheels. I suppose next we will reinvent minis, micros, LANs, etc.
threecheese 3y ago
I think you’ve stumbled on the solution there - *something* happened between the 70s and today to address that thing from the 1960s, and it was motivated by capital-seeking. There’s a high probability that it will happen again, and if it does not then it’s likely the market didn’t demand it. Or, the world is just one big corporation and we’re all screwed. One of those.

immibis 3y ago

The problem with that idea is that it requires every router to know about every system on the network. Unless they abandon Ethernet and replace it with MPLS source routing, which maybe they should. You'd still have a maximum subnet size, because the hardware firewall that would still have to be in front of every server would have a limited capacity.