Well, that's just it, the foundations really haven't changed. We still use TCP and UDP, we still use Ethernet, we still use Linux (and Windows and macOS), we still have the pattern of an application needing a configuration stored somewhere where it can read them to exhibit the desired behaviour. We still have the concept of 'services' where it's the job of a (semi-)automatic management or orchestration system to ensure that they are operating within parameters. Nothing about that has changed, regardless of your daily tasks.
If you write in Go, Rust, Java, C#.NET, Python or TypeScript, all of those foundations stand and are practically unchanged. Some layers might have been added, i.e. when you describe how your service is supposed to run in a Docker manifest, or in a Nomad configuration, or just a systemd unit file. But those are just formatting issues with plenty of manuals to go around. Yet still, when something goes wrong (i.e. application exits with some status integer), an engineer used to be able to understand that:
- Your application or its management system detected a problem
- The OS provided an indication that your application has an issue
- If you don't know all codes, you know that they are perhaps called "exit code" or "return code", and you at least know how to look those up
Say it turns out that your application is throwing a SEGFAULT, as an engineer, aren't you supposed to know that a segmentation fault happened, and you can suspect some shared library to be the first thing to check before going deep with some debugger? Maybe run a command to find out what libraries are needed, check if they are accessible and contained within the context of your application (i.e. if not in a complete OS, but a container or jail or chroot).
While in theory only a part of an entire team might need to know this, having mostly teams where 0% of the team members know this might be a problem, don't you agree?
Same goes for "I am calling this HTTP API but it doesn't work", that's just a lack of information to begin with. This question is asked plenty of times, and usually the first thing we need to know is "what is the error" because for some reason the developer doesn't understand that it could be a myriad of things and asking for help because "the thing had a booboo" doesn't mean much. Then onwards to:
- Is the URL valid
- Is the FQDN valid
- Are you even using an FQDN or did you think everything in the world runs on your DHCP-supplied search domain (common in windows land)
- Can you resolve the name via DNS
- Can you connect to the IP on the port (commence lesson about netcat and similar tools, every single time, again and again)
- Did you ensure the security groups or legacy firewalls are actually configured for your desired traffic
- Is the service on the other end actually up and does it even exist
None of this is deep systems understanding for greybeards, it's just basic client-server model programming. But still, there are more team members that don't know how to verify connectivity than teams that have at least 1 who does.
Every time someone needs to reach out to that special someone they think magically knows everything in the world, that's a waste of time for two people, and a break from concentration. Advanced issues like "my packet payload get truncated and I don't know why, they are just TLS and below the MTU size", sure, can't expect everyone to understand how to check that stuff out. But we're talking about the basics here.
We're running low on greybeards and we're not getting new ones because "they don't need to know" (developers, ops), and this is going to be a problem that gets bigger, not smaller.