Infrastructure People – Learn to code or GTFO

Although it’s not always apparent to those I’m mentoring (Asking me for answers should not be your first step.), I like teaching. I like helping people work through problems and figure out how different components fit together holistically.

Lately, there’s been a particular point I’ve been trying to hammer home in almost every conversation I have – with junior sysadmins, college kids entering the field, and anyone else who will listen.

Regardless of your infrastructure specialty – networking, servers, storage, whatever – you need to learn to code.

Or you need to consider another line of work.

Batch script wizard

Part of gaining expertise is learning the scope of what you don’t know. I remember feeling like a fancy wizard when I started my career in tech – that I knew sooooo much. I could build computers from junk parts and troubleshoot through any problem set in front of me.

Then I met systems and network admins who knew how to script. They could craft batch and bash magic to effect change across the network. The scale of the world they worked within was so much larger than mine.

Suddenly, I felt like a caveman (Not even a smart caveman. More like Flurp, the slow, butterfly-chasing caveman.), clumsily bashing rocks against every problem.

Even simple batch scripts to map printers and install software were game-changing. All of those manual configurations I had been so proud of started to feel silly. I still feel a little of that when I browse through projects on GitHub.

Knowledge of scripting rapidly became a dividing line between tech jobs that paid minimum wage and those with upward potential. Batch (more Powershell now) and bash (more Ruby/Python now) became the foundation to launch a career from.

Code literacy

There are cases where a simple Python script can obviate hundreds of hours of work. Hiring managers know this and this skill set is now expected rather than being a “nice-to-have”.

“Take this server. Now make 1,000 friends for it.”

New expectations are forming around the interaction between infrastructure & applications and general automation. Within a few years there will be very little room in the industry for infrastructure-focused people who are not, at the very least, code literate.

This doesn’t mean you need to be able to build a consumer-ready application from scratch (although that helps), but it does require an intermediate-to-advanced understanding of scripting languages and/or a basic understanding of compiled languages depending on your company’s dev stack.

DevOps is here

What use is a sys admin who just points at the apps team and says “your code sucks” without even being able to read the code? Or a sys admin who is charged with designing infrastructure for an app he or she has no understanding of?

That’s why DevOps (the merging of infrastructure operations and development) has become such a big deal. Companies need their sys admins and programmers to be able to work together and at least have an idea of what the other person is talking about.

“Line 38 appears to reference an individual database server we took offline last week instead of the load balanced DNS name and knowing that this loop is working through this array, I probably gave the app servers too little memory.”

And in situations where an app is being scaled horizontally, the infrastructure has to be there to meet it – automatically. Clicking buttons in the Windows Server GUI is probably not going to get you there. Knowing how to script against the server command line or the platform services an app is running on will carry you a long way.

Additionally, why would a company hire 10 network admins to maintain equipment configurations when they could hire 2 who knew how to script against an equipment API? Be in the second group. Automate your configs and show your value.

It’s up to you

If you have no plans to build your skills past manual configuration, you are destined to work in small, boring environments if you’ll be able to find a job at all.

If someone can hack together a few lines of code to replace you, that’s your fault, not the merciless-robot-who-is-taking-your-job’s fault.

If you think “I can’t code. My brain isn’t built that way.” Spend 30 minutes working through exercises on CodeAcademy or any of the countless other coding tutorials online and you will find out that you are wrong.

This isn’t the requirement for five years from now. DevOps is here today. If you want to stay in the infra niche and be happy and successful, it’s time to fire up your text editor and learn a programming language.

Image Credit: Michael Himbeault

People Tech

Cisco Live: A river of dudes

It’s been a few weeks since Cisco Live, and I’ve had time to digest a lot of what I heard and saw there. There were some pleasant surprises: The DevNet area was awesome and highlighted some interesting things that Cisco is doing with Infrastructure as Code.

There were also disappointments: Intercloud remains a confused mess, some vendors went super-cheesy with their presentations, and the follow-up sales calls are relentless (Seriously, Puppet Labs, I didn’t need another 25 voicemails.).

But weeks later, the thing that stands out in my mind is the homogony of the attendees. Easily 99% of those present were male, and that stinks.

This happens everywhere

Diversity isn’t a tech industry problem – tech just happens to highlight the most egregious examples because of the current underrepresentation of women and minorities in math and science-heavy fields.

Across all industries, we make it hard for women to get their foot in the door – I’ve seen women turned down for jobs over concern for how others in the business would “cope” with them and a myriad of other silly reasons. I’ve seen women forced to prove themselves far past what’s required of male applicants with similar experience and credentials.

I’ve seen those that have gotten hired treated horribly – spoken down to, insulted, alienated.

Yeah, so…I’m gonna need you to answer the phone now

A few years ago my wife and I worked at the same company. When management fired the receptionist, they decided to split the phone duties among “the other women” in the office. Male peers, at the same employment level, were excluded – they had important work to do. My wife was managing HRIS, but because of her gender she was seen as “less than” the males working in entry-level roles a few offices away.

I know plenty of smart, competent women who have strong interest in fields in which they are not working – tech, science, manufacturing, field ops. When I ask them why they didn’t follow their interests, the answer is almost universally “because I didn’t feel welcome”. They didn’t feel welcome in computer club, in biology class, in their MBA program – so they defaulted to something they didn’t love in order to survive.

That makes me furious

My wife and I have been talking about starting a family, and during those discussions my imagination runs wild. I imagine future children, teaching them things, showing them the world.

I imagine having a little girl who gets told by others that it’s more important to be pretty than smart. I imagine her applying for a job and getting turned down because of her gender. I imagine her getting treated poorly by a chauvinistic manager. I imagine her standing up for herself and being called a bitch and it makes my blood boil.

Changing culture

The status quo hurts everyone. A meeting room filled entirely with men lends itself to the pack-mentality groupthink that results in bad decisions and stagnation. It creates a toxic, locker-room culture in which it is OK to talk down to others and management is accomplished through intimidation. It leads to stale ideas pushed forward by literal yes-men.

My ideal hiring scenario, because I don’t trust my own subconscious biases, would be completely blind – if I was managing a team, I wouldn’t know if a new hire was male or female, I wouldn’t know their race or age, I wouldn’t know any of the unimportant things about them until they walked in the door the first day.

(This sounds impractical, but Google is actually pulling something off that is very similar.)

That’s really hard though, especially for companies that don’t have the resources to setup selection committees or do away with the concept of “hiring” managers. It’s not that hard to blind resumes for the first round of review though, so we can start there.

It’s also not that hard to treat your current coworkers like human beings.

Diversity is a hard problem to solve. There are no easy fixes – there never are when a problem is based in the way people behave, but we have to start making changes, if only to build momentum.

Down with the patriarchy. Long live basic human decency.


Give up control and stop managing devices

Managing end-user devices, simply put, sucks. It requires a significant amount of infrastructure and staff. It leeches time from your IT department and end users. And the more you try to wrap your arms around all the devices in your company, the more problems you have.

Trying to fully control and manage every device connected to the network results in unhappy users and broken IT staff, huddling in data closets, weeping – while the executives upstairs are piped a false sense of security.

So stop managing devices. Don’t join them to a domain, don’t lock them down. Give up control.

I promise you, it’s not as crazy as it sounds.

All the devices!

IT departments have been struggling for years to juggle trusted and non-trusted (BYOD) devices. We layered on tool after tool to try to stay in control, but it hasn’t really worked. It’s just made management more complex.

We built a taller wall around trusted devices and the network, and tried to extend control to all the new things that employees were bringing to work. We began to manage triple the devices with the same number of staff.

Users hated the new restrictions on their computers as we locked them down, and IT hated all the new infrastructure we had to install and maintain to keep any semblance of control. We kept piling on sandbags long after the levee broke.

It’s time to start over

Instead of trying to exert control, what if we went the opposite direction? What would happen if IT treated all end-user devices as non-trusted, employee andcompany owned?

  1. Security is simplified.  If we assume that all endpoints are insecure, we can drastically shrink the surface area we need to protect and focus on data and apps. Devices are separate from the data center and one another.
  2. App management is centralized. With a small number of exceptions, we can deliver apps via browsers, virtual desktops, or streaming – from the datacenter or the cloud.
  3. Data is tied to identity. Unstructured data moves to the cloud, with rights management or containerization in place depending on your compliance needs.
  4. Devices don’t matter. Remember, we’re relying on remote delivery of apps and data (Think of everything as a thin client.). A user is having a computer problem that takes more than 5 minutes to fix? Swap the device out with another from the pool.
  5. Overall management is simplified. But maybe we require a health check to keep things from getting too crazy. Don’t add machines to the domain, use an MDM. Passcode, A/V, and security updates seem like reasonable requirements to enforce, but stop there.

This isn’t a thought experiment. This model is being pulled off successfully (sometimes in pieces), not just in Silicon Valley, but in growing pockets around the country – within organizations that are aggressively embracing the future.

Vendors are building and have already built products and services to support this model. VMWare, Microsoft, Google, Amazon – almost every player who matters is on-board.

If you’re in an architecture or strategic role, this is the future you need to be planning for. The current model is untenable – within a few years, if your IT departments is still trying to manage devices the same way you do today, with half the budget, a quarter of the staff, twice the tools, and exponentially more devices – you will fail.

Photo: ep_jhu


It’s OK that the cloud doesn’t do everything

One thing you won’t hear when a vendor is pitching their cloud solutions to you is that the biggest success factor for your move to the cloud is a willingness to embrace constraints – being OK with the box you’re putting yourself in.

Constraints aren’t inherently bad – I use them all the time in photography. Knowing what my camera can and cannot do pushes me to approach shots differently, often resulting in a photo that is far better than what I would have achieved if I had attacked the problem head-on with all the camera equipment I wanted available to me.

When it comes to the cloud, constraints force you to re-examine what you’re doing. That helps on the technical front, but it is especially powerful when it comes to business processes. The last 60 years of on-premise open-sandbox tech has enabled people to build a lot of really dumb processes.

“So, I type in all the info from these paper tickets into this spreadsheet, then I print it out and fax it to Dorothy. Then she combines my report with the other sites’ reports, prints that out, scans it, then e-mails it to Richard so he can plug it into an Access database.”

If you’re moving off-prem, consider it an opportunity to reset and if you can manage it, forklift as little as possible when you make the transition.

Azure and AWS don’t support all the custom infrastructure hacks you’ve put in place over the last 30 years? Do yourself a favor and leave those hacks behind. Learn the platform and focus on what it can do.

The new SaaS vendor doesn’t support the process you built in your old, on-prem ERP?   Instead of trying to hack something together to get the new system to support your process exactly as-is, call the vendor, describe the problem you’re trying to solve (start with the problem, not your years’  old solution) and work with them to design something new.

Turns out, software companies like Google and Salesforce employ a lot of really smart people, and the best ones understand that as beautiful as their code is, it has to be used in the real world.

These are things I want to shout whenever I’m at an industry event. It never fails that at least one neck-bearded engineer in the room pops up with “I’ll never move to the cloud, it doesn’t do this, this, or this.”

Occasionally, they have one or two valid points out of the handful they toss out.

When pushed though, their reasoning is usually “because we have it now’, which is the perfect rationale to help the business drive itself off a cliff.

Photo credit: Perspecsys


Thoughts on the eve of Cisco Live

In less than 24 hours I will be boarding a plane headed to San Diego. It’s my first year to attend Cisco Live and I’m hopeful I’ll see something different than what I’ve seen from Cisco over the past few years.

That companies are migrating so quickly to op-ex, cloud services models seems to have surprised Cisco – they have been fumbling for a good while now, trying to find their way in the new world.

The Meraki acquisition was smart – it gave Cisco a robust-but-easy-to-deploy, low-overhead infrastructure solution that customers have been clamoring for, but from the outside it appears the legacy product teams are at odds with the Meraki team. The promise of a converged feature-set appears to have stalled out, with internal politics and concerns of sales cannibalization serving as roadblocks.

Last year, Cisco Intercloud was pitched to me as the solution to all my cloud integration problems. Intercloud was going to enable me to easily migrate VMs between cloud providers and extend the LAN across the multi-cloud WAN. Problem is, as a brand new product Intercloud is designed around a paradigm that’s rapidly fading.

Modern IT is not being built around individual VMs or extensible network segments, it’s all about workload. Being able to move VMs around is handy for the near-term in dealing with legacy applications, but workload containerization negates one of the biggest selling points of Intercloud. I don’t want to move VMs from AWS to Azure or On-Prem to Cloud, I want to kick off a Docker push of my app image and let the platform take care of the rest.

Intercloud seems to be targeted at where the puck was, and the game has shifted considerably. It will be very useful for many big businesses, but not for very long.

Even in the datacenter, startup SDN solution providers like Cumulus Networks seem to be getting better at the Cisco stuff faster than Cisco is getting better at rapid innovation.

I say all these things not to beat up on Cisco, but to nudge them towards where I think they should go, where I think they can remain relevant. Right now, Cisco seems to be focused on providing solutions for today, when other IT vendors are pulling their customers into the future.

The Cisco I hope to see at Cisco Live is one that is aware of where it is falling behind and is rapidly moving to correct. I want to hear more about DMVPN than OSPF & BGP. I want to hear more about APIs than integration licenses.

I don’t think Cisco is at any risk of going away (Existing enterprises and telecoms are going to continue rolling out Cisco equipment because that’s what they do by default.), but like any big tech company they are at continual risk of becoming irrelevant and technologically boring – and right now their ship seems to be changing course very slowly.

Photo credit: Andrew Hart