From a technical perspective, I believe a senior IT engineer is primarily differentiated from a junior in one word–experience. The senior engineer has installed more systems, planned more changes, fixed more problems, and survived more outages than a junior engineer in the same organization. Ideally, that experience has led to wisdom about how technology can best serve the business needs of an organization. This wisdom will tend to eschew needlessly complex designs, nerd knobs, and “science experiments” conducted in production. But this post is more about the non-technical skills…
Most of the search engine hits for “upgrade PHP on WordPress” told me to go into CPanel or a similar tool my hosting provider might offer to abstract what’s going on with the server itself. That’s not what I was looking for, because I manage my own hosts. I needed to know how to reconfigure the host itself. The OS packages to install. The conf files to tweak. The processes to restart. This was not obvious, as the magical CLI incantations required to complete the task varied depending on which Linux distro and HTTP server I was running on a given box.
Let’s think about what happens when a business does not stick with their incumbent networking vendor. Is changing networking vendors adopting new technology, and therefore fraught with risk? If I change from Cisco to Arista for data center switching, or to Aruba for my wireless, or to Juniper for my edge routing, or whoever and go all-in on their ecosystem, is that change really as risky as Cisco’s continuing dominance implies? My experience is that no…it isn’t.
Architects and engineers tend to be introverts who are at times unsure of themselves. We don’t want to be learning in public. We want to be left alone to figure it out. When we’ve figured it out, maybe then will we share, once we’re supremely confident that we’ve got it 110% right. We just don’t need the headache of criticism, controversy, and the “but actually” pedants.
Backups are crucially necessary and incredibly boring all at the same time. We almost never need backups, and so they tend to fall down the task list next to “update interface descriptions to the new standard” and “write the new standard for interface descriptions”. Yet, when disaster strikes, the most important thing in the world might be recovering from that backup data.
Zero trust assumes that every endpoint has been compromised and represents a threat. Therefore, even though an endpoint is connected to the network legitimately and allowed secure access to resources, the access requests themselves are suspect.
I am hopeful when it comes to new tech. I really am. In part, technologists are employed because of tech’s ever-changing landscape. But I am also dubious during any technology’s formative years. I take a wait-and-see approach, and I’ve never been sorry for doing so. I believe that being a late, not early, adopter of technology pays off for most organizations.
The big idea is to support the same IP address in multiple locations, but to NOT have fate-sharing, where a problem like a bridging loop and resulting broadcast storm at one site would take down the other site. That means we can’t just throw up a tagged VLAN link (trunk) between the DCs. Instead, we have to divide the L2 broadcast domain (the VLAN) into different L2 domains separated by a routed segment. This way we’ve created two failure domains that will not share fate.