Starting out the week by reflecting on what my role as an engineer within a team is. The nature of a team is that each person will have a part of the puzzle. And to be an engineer is to work within the mysteries of the system. Invisible forces – hard to feel and even harder to describe – become your currency, your responsibility. We’re trained to get a grip on those forces, and the closer we get to them, the further we move away from others.
Operation is a form of science, of flow, of magic. To be part of a team – of peers, across disciplines, with clients – is to constantly decide which of this soup you should translate versus what you should be trusted on. Openness versus opacity. Too much information can be just as frustrating or risky as too little – and what’s appropriate will depend on the context at any given moment.
Understanding the context quickly is a big part of my role. Picking questions that may be tricky, but that people see the reasoning behind and ultimately acknowledge as useful – this is how change happens (in theory). Asking these questions is a form of group humility – an approach that accepts that not all things are easy or instantly solvable by a single person.
Yet this eternal dance between the team and the system – the continuous investigation and revelation of the system – is not something we get taught in school or in management courses. Why not?
Thinking a lot about the tech-space that SMEs will find themselves in over the next few years, and the best way to support them. Is the hosting and IT operations landscape actually changing as much as it feels like it is? Or am I just reading more into things based on my own bias and risk-centric perspective?
In particular, has the nature of “script kiddies” and drive-by intrusions against tech systems fundamentally altered as LLMs come into play more? I want to say yes, it has – that where before there was a strangely-accepted threshold of “patch the obvious and things will be okay” was enough to defend against low-level, opportunistic threats, now we’re seeing a much more complex space. In an era when LLMs can be integrated into worms, and in which scraper infrastructure can be set up in a click or two, it feels like the baseline for being secure – or even just functional – has increased dramatically.
More evidence this week, for example, that security-by-obscurity is just dead in the water – not that it was ever a sensible defence, but it could often be leaned on if you were lucky. Similarly, supply-chain attacks and basic token leakage mean that it takes fewer bytes to be exfiltrated in order to be able to do more damage.
What does this mean for people without the time or knowledge to understand these shifts? Some – perhaps most – will increasingly rely on just outsourcing whatever they can to services, and this makes a lot of sense. But it’s also only the tip of an iceberg of possibility. Authentication will always be required at some level. Managaing authentication will always instantly be more complex once more than one person – or device – is involved. And from there the iceberg desceneds ever deeper. Backups, data protection, token rotation, devops costs, political battles and so on – nothing inherently software, but all to do with process, efficiency, and risk-management.
So an understanding of this complexity is still hugely vital – it’s not necessarily something you can just hand over to ChatGPT. Overly secure processes can be just as disruptive and frustrating as lackadaisical ones. Strong authentication is always an inconvenience. Finding the right balance for the business is an essential and ongoing review loop.
And then the other question nagging me – someone who’s helping look after, maintain, and defend many dozens of websites and servers – is how many people does it really need? Can it be done with the amount of attention I have now, or should I be looking at changing the current model? Can more be automated, or do I need to bring others in to lend a hand?
Certainly taking your eye off the server ball is a dangerous thing these days. Spotting signals in the noise of logs, reminders and warnings could be a full-time job in itself – but not one that anyone ever pays for.
Phew, the last couple of weeks have been learning-heavy – like, more than normal. It’s been a lot of fun, but I do forget that a big part of learning is processing memory, which is a bunch of cognitive load, and which requires more sleep than I’m probably getting these days (thanks cat).
Recently I’ve been delving into some interesting things though:
- Using Grafana’s k6 to try out some load testing. Nicely easy to get set up on my local machine, and really helpful to report metrics around scaling up requests, and how the different parts of the server respond in turn.
- Related, I’ve been using Plesk’s migration tool for the first time to downsize a Digital Ocean Droplet. Matters aren’t helped when Digital Ocean develop a bug in the feature I’m using just as I start using it – nor by their amusing AI assistant giving me three different answers to my question, and totally ignoring the “known issue” that had been posted.
- A site for International Repair Day that I’ve been working on went live. The design used a lot of tilted components to give everything a bit of a “hand-made” feel (I assume), but modern CSS has been amazing for dealing with it all. I’ve tried to keep the site light – most flat-colour images are SVGs, and there’s some Javascript but in a minimal way. Most things are configurable by web admins in the back-end too. I’m not a specialist web developer, but it’s good to keep my hand in and keep half-an-eye on what latest developments are. Loving CSS these days.
- Finally discovered git worktree, a way to run several directories on different branches off the same git repository checkout. It’s slightly confusing sometimes but it’s also a really handy way of working, in between stashing changes, and creating a whole new checkout or copy of the repository. Slightly dangerous but definitely a useful one for the toolbox.