This is a post to try and draw some of my thoughts together – so criticism welcomed and encouraged. I could be completely off base with what I’m about to write…y’all keep me honest! 🙂
In my new position at Inktank, I’ve started digging into learner analysis. For the non-edu peeps reading this, the way to make good training is to look at what the learners will do, what they already know, and where they will do the work BEFORE writing the training.
And I think I’m noticing something different here…maybe not (this is where I’d love input!). Inktank is a services and support organization that has the purpose of supporting Ceph, which is an open source storage project. Those of us who are in the data storage industry know that storage isn’t really about the disks, its about the software. And if it’s about software, why isn’t that software open source? Actually that’s what Ceph is, so there is open source storage software now!
This is where I’m starting to to see differences in the learners who may need to get up to speed on Ceph. Traditionally, software and storage training fell into pretty neat buckets: storage engineers, storage architects, storage developers. We would also have some systems admin courses for the people who maintained the systems connected to and dependent on the storage system. But we never really considered developers as a primary audience, and this killed us as APIs started opening up and programmers were required to take advantage of the new software capabilities.
Let’s review the IT silos. On the ops side we have storage people (we freak out about data being available), network people (they care about security and finding ways to get the packets there), and sysadmins (who have to pull it all together and get beat up on by the end users). Then we have the dev side – or the folks who write the code.
How did we get so silo’d? This O’Reilly article has some nice historical perspective. It talks about the old mainframe days, where if you coded (were in dev), you operated. Then our industry evolved to the client-server era, and we also separated the workers into developers, sysadmins for the servers and network admins for the networking. As things progressed we saw other specializations, such as storage professionals and database professionals.
And these silos came with all the trappings of organizational silos. Different methods and vocabulary for the doing the same thing. Misunderstandings of why certain procedures needed to be in place, even if it made things take a little longer. And oh yeah it was always the network’s fault. 😉
But now, things are coming back together. We are quickly coming to a place where we will be able to program the entire data center. We need the agility of the development side of the house in coordination with the discipline of the operations side. I think we’re at a time where everyone needs to stretch outside of the silos we’ve lived in for 25 years and learn to do some of the stuff that the guys on the other side do.
I think the challenge is going to be getting the folks in these silos to network together, and to teach each other what they know. I don’t think we need to start from scratch, we’re working with folks who have highly specialized skills. We need to figure out how to get them to share, how to get them to let go of that old silo’d way of thinking that “those dev guys don’t understand storage”, or “those storage guys can’t code”. These statements have never been true.
Harold Jarche had a great post recently on how trust is the emergent property of effective networks. This quote from that post is very applicable to what needs to happen to bring dev and ops together:
… trust is not a market transaction, it’s a human transaction. People don’t work by supply and demand, they work by karmic reciprocity. In markets, if I trust you, I’m a sucker and you take advantage of me. In relationships, if I trust you, you trust me, and we get along. We live up or down to others expectations of us.
We’ve been taught not to trust the network guys, let alone the dev guys. And they’ve been taught the same thing about us. Do we need to help people unlearn that before we can teach them what they need to know to do their jobs?
What do y’all think?
Nice article Gina. What you write about isn’t DevOps specific, but rather a challenge that anyone involved with the new Data Center / Cloud technologies is dealing with (eg. how to change/evolve the people skills and process).
I joke that the “clouderati” should be embarrassed that they still only highlight NetFlix and Zynga as examples of companies that have adopted this “right way of doing cloud”, but it does underscore a few issues:
– The DevOps conferences (and most “Cloud”) conferences are only focused on the new technologies, not on how to move from old stuff to new stuff.
– The assumption that someone that has never been trained to code can suddenly code is a big leap of faith.
I believe it may be much easier (“easy” being a relative term) to create your training to focus on what a proper DevOps team would look like, in semi-greenfield (or 100% greenfield) environments, and focus on the skills and success that can be achieved with that. Don’t assume that large numbers of people are going to re-learn things across those silos in a short period of time, since it takes 3-5yrs to become expert in a given skill (see: Gladwell, “Outliers”, 10,000 hours of practice).
Take “trust” out of the equation, and focus more on actionable steps for people that have a business need to learn a new model. And then evangelize (“market”, “talk about”) groups that have been successful…so maybe in 2013 we can hear about more than just NetFlix and Zynga 🙂
Thanks for the comment Brian. I think where I’m struggling is I need to design training for a pretty diverse audience…as that audience is converging. It’s almost like doing something to converge the audience would be the easiest thing to do…
It’s possible that you’re overthinking the breadth of your audience. In every “DevOps” event I’ve ever been to, the people in attendance only identify themselves as “Developers” or “SysAdmins”. Nobody says they are a network admin or storage admin, especially since the topic is almost entire about open-source technology. So maybe the training needs to include some basic storage knowledge, but mostly focuses on those two groups and their typical operational mindsets.
You could be right. But then – how do I teach people who understand storage and networking to be more….. “dev-y”? Do you think since the audiences come at this from areas of expertise it makes it harder to just create some blanket course? (I do)
“so there is open source storage software now!” – Ummm, how long has Lustre been around?
IDK. how long?
I think the real problem isn’t that DevOps is limited in scope, which it is. It’s also the entrenched hegemony of IT that refuses to adapt or change. The IT department that still thinks Exchange is a great email system, that Blackberries are the only supported mobile devices, and that 801.11g is plenty fast enough for all those laptops.
The same problem persists in storage and how applications address it. We limp along with protocols designed 20 years ago and bolt-on technologies to try and make them scale, but it doesn’t work well if at all.
I’d suggest that your training will need to address these people, and show them how to get out of the morass of fibre channel and CIFS and into storage that scales.
Hey Roger! Thanks for the comment. I think you are absolutely correct. But how much of the resistance to change is people thinking things are “good enough” vs budgets and politics that force orgs to stay bound to the older tech?
I think it’s a lot of both, actually. It’s a vicious cycle: one turns into the other. So even if you want to change, you’re prohibited from doing so by your IT organization that is resistant to anything new. Those organizations over time tend to attract people who think the same way, because who wants to work for an organization that rejects everything you want to do?
Here’s a good example:
http://www.networkcomputing.com/data-center/the-software-defined-data-center-dissect
Here’s an idea, the software-defined data center, that exists for just one reason: so that we can drag awful legacy software systems into modern datacenter design.
No one is willing to just up and redo things so they work with new technologies and infrastructure, so we’re stuck with this hack that lets you keep your Oracle database forever and ever and never consider there might be a better way to do things.
Pingback: G's view of the world - Building an environment that activates entrepreneurial learners