From silos to all-rounders: the evolution of “infrastructure” skills

Picture the scene. There’s been an outage. A client’s application has gone down under a spike of heavy load and a critical business process is impacted. 

The client notices first (or worse their customers do) and the service-provider rapidly plays catch-up to find the root-cause. One or more incident tickets are passed back and forth until the inevitable happens; everybody jumps on an incident call. 10 or more people join from different functional teams. It’s not a network issue, the database is fine and the web site is up, the middleware seems to be OK, the firewall’s OK etc. Eventually the service is back up and nobody could find anything wrong. It all looks fine now.

After everyone takes a breath the root cause is found and it’s traced to a change someone introduced that wasn’t supposed to have any impact, but introduced an unexpected side effect, some increased load and a lower failure threshold.

In good cultured companies, staff are encouraged to learn from the issue and recurrence is minimised. In bad, poor senior managers berate their staff creating a culture of fear, making the problem worse in the long run. Now nobody wants to change anything and the organisation suffers even further.

Now picture a different scene. The same client’s application has had a spike of heavy load. This time the service isn’t impacted.

The service detects the condition and adds additional resources, scaling to meet the demand. The capacity increase is reported and alerts sent to a set of multi-skilled Platform Ops staff who confirm the service is operating as designed but can now proactively investigate the reasons why.

The first scenario is often how it used to be in the on-prem/hosting world where siloed teams with deep technical expertise in one field would have to come together to work on a resolution. Public cloud solutions (architected properly) change all that, both in terms of the technical solutions available and the skills required to design and support them.

To head off the inevitable “yeah, but...” observations in the above; yes of course you can have well managed and monitored on-prem/hosting environments and yes, you can still have siloed teams supporting public cloud solutions. It’s just that, typically, the above are the norms; on-prem skills = very deep and siloed, public cloud skills = broad and multi-skilled individuals.

For many techies, working in public cloud necessitates a different mindset. No longer are you designing the infrastructure from the ground up; the public cloud provider has done most of the heavy-lifting already and built you a selection a products you can call upon. If your background is in Storage, designing SAN/NAS solutions, managing hotspots, designing for the right level of IOPS etc, these tasks largely disappear when picking from the catalogue. Sure, you still need to know what the app requirements are (and no, the apps team probably still can’t tell you up-front) but the task is different; it’s higher up the stack, as it were. You can still be a storage specialist at heart (nobody wants to take away your love of those spinning disks) but spend any significant time working in public cloud and you’ll naturally start to broaden your horizons.

Instead of spending days/weeks in back/forth conversations about app and requirements, waterfall style, before committing to a big investment, the modus operandi becomes “try it and see.”

For many organisations looking to make the leap, this can be a culture change in itself, but for the individuals on the ground, there’s a degree of courage required. The need to free yourself from the usual process, the usual corporate governance and not only suggest, but actually drive a more agile way of working. As Brian Solis wrote in WTF?: What's the Future of Business?, at times, it can feel a lot like you’re on your very own Hero’s Journey.

So what’s the answer? Shelve your storage skills, cancel those Cisco exams and ditch the DBA work? Of course not. There’s still a need for these skills today and in acquiring them over the years you will have picked up all sorts of battle-scars that will give you a unique perspective and value in public cloud. It's just that what you do tomorrow may be very different to what you do today and with a New Year coming, you might also need to find the new “you” in skills terms.

Picture the scene. It could’ve broken. The way you designed it meant it didn’t. Now you can spend more time improving it further. Doesn’t that feel a better way to work?

Next time we’ll take a look at what some of these cloudy roles are, how they mesh together and then what on earth a Cloud Centre of Excellence could look like.

If you’d like to know more about how I can help your organisation get the right mix of skills in place, feel free to get in touch.