04 Apr 2015

Gathering my Thoughts: Devs Rool, IT Droolz

Yesterday I found myself in the middle of a debate on Twitter surrounding DevOps and the future of infrastructure admins. The whole thing was really triggered by a tweet sent by John Troyer where he stated; "Both O'Grady (New Kingmakers) & Chen (Developer-Driven Infrastructure) say "Devs Rool, IT Droolz". How do IT pros adapt?"

 

At first I didn't really think it was going to lead to a discussion that I was going to get involved in, but then I saw the following reply to John’s tweet: "By keeping Devs away from anything remotely important or critical":

This is where it all started as I decided to counter @gmitch64's reply to John's tweet, by tweeting: "@gmitch64 @jtroyer without Devs, there won't be anything remotely important or critical. Software doesn't write itself."

Although, by the time I started joining in, the discussion was already in full swing. For a full list of tweets sent on the discussion set to by John Troyer, have a look at this page:

https://storify.com/jtroyer/devs-mammals-as-it-dinosaurs

When I first saw John Troyer’s initial tweet, which mentioned "Devs Rool, IT Droolz", I did somewhat agree, although not wholeheartedly. What really got me going was when I saw a tweet from Jonathan Frappier, where he stated: "I can't code, they can't do infrastructure”. While I do understand that for the vast majority of Infrastructure admins and developers, that statement would be true, in my case as in many other cases, it would also be false. At this point I was simply unable to resist the urge to respond with a retweet:

I should also mention that the debate did end in a healthy way, with all of us finding “common ground” and “mutual respect”. I hope that’s the case at least J

Another thing that the conversation made me wonder about is, why it is that the word DevOps seems to almost favour developers over operations? Maybe it’s only my perception and that it doesn’t favour developers at all. I don’t know. But if it does, is it because it's DevOps and not OpsDev? ;) Or, is it that we’re being conditioned by the powers that be to believe that the future is code and code alone by hammering home the tag line “it’s all about the app”? Remember this “app”; which *everything* is all about; needs someone to develop it and also some infrastructure to run on.

Explaining my current messed up thought process

I really started my life in IT as a programmer. I’ve got a real special place in my heart for coding. Delphi, C/C++ with Oracle PL/SQL is what I studied before I started working in IT and still have a keen interest in coding. I think of a night spent in Visual Studio coding in C# as a relaxing and exciting hobby. I don't consider myself a developer, but if my skillset was to be represented in a tag cloud, I’m pretty certain the words "coder" or "code" will be in there somewhere. Sure, it might not be as large and bold in this tag cloud as say "Infrastructure, vSphere, Linux, Consultant, Architect", but it will definitely be in there. I quite like a bit of coding. In fact, there are few places on this planet where I feel freer to do what I want than in front of a blank C, C++ or more recently C# source code file. However, those who know me, would also know that I have a strong background in infrastructure, with more than 10 years in dealing in depth with VMware enterprise class virtualization products and infrastructures built on those technologies. So I consider myself blessed that I am able to do both fairly confidently.

So the question is this. Are the claims that if you can't code that your job will disappear really accurate? Are the claims that Devs are cooler than IT accurate? I remember having those silly arguments in college, where the programming students and IT engineering students were always in a “we’re better than you” fight. Then one day, I found myself on the other side of the fence, and guess what, I’m still on that side of the fence. The IT Infrastructure side. Before the discussion on twitter, I would have told you "probably yes, there is a good chance that your job will become obsolete". Now however, having thought about this more, I'd say "probably not". You see, I came to the following conclusion:

Just as much as developers have had to do the time to master their craft in coding, just so did infrastructure designers and admins have to do their time to master their craft. Although I can both code and do infrastructure, I can't honestly say that it has been possible for me to spend an equal amount of time on both infrastructure and code. I just don't believe there is enough time in the day to keep up with both areas to be an ace at both. You see, if I was a developer who for the past 10 years did nothing other than write code, but who at the same time has a good understanding of infrastructure to a degree, would I honestly be able to spin up an infrastructure as efficiently and securely within the same timeframe as an admin who's worked years at mastering the craft in what is, let’s face it, a very complex world of infrastructure? In the same way, can I, as someone who regard myself as an infrastructure veteran and expert(I use the word expert with caution, as I still have a lot to learn and always will have a lot to learn) in this field, develop an application to interact with my infrastructure in order to deploy more resources on demand, in a secure and efficient manner, following today's programming frameworks and architectural patterns such as MVVM? I don't think I could, and I'm not shy at typing some code.

You see, being a developer is much more than simply being able to write some clever code. It’s being able to write code using standard frameworks, methodologies and architectural patterns. These frameworks, methodologies and architectural patterns are not easily “learnt”, but rather a skillset that takes a considerable amount of time for a developer to grow into and build upon. Take for example the MVVM (Model View View-Model) architectural pattern I mentioned earlier. It’s used by many C# .Net developers and it decouples the user interface (view) from the model (logic) and enables coders or “developers” to work independently on code without having to be overly concerned with the work that the user interface designers are doing on the user interface. So simply within this one architectural pattern, you may end up with a developer working on code whilst a UI designer, probably with a completely different skillset to the developer (probably unable to write hard-core C# code themselves) will be working on the user interface. Now, I’ve looked into MVVM and started working with this myself, and if I’m honest, I’ve probably got a few years to go in my journey to be 100% comfortable with MVVM.

Now, spin this around and look at infrastructure operations. Gone are the days where a single server is spun up with an OS installed and we are ready to roll. We now have complex server hardware, complex networks and complex storage solutions. Not to mention the complexity introduced by infrastructure software stacks such as vSphere, Hyper-V, vRealize Automation and Orchestration, and the list goes on and on. Servers used to be beefed up X86 machines, that almost represented the same technologies as found in desktops. Today, even in servers such as HP’s ProLiant DL380 Gen 9, the hardware configuration options pose an incredible array of different options. I’ve recently had to spec some new HP ProLiant DL380 servers, and I can tell you, it’s a world away in complexity from what it was 10 years ago. Similarly, network technologies have become a lot more complex as well as storage. I don’t even dare bring network virtualisation with products such as NSX into this conversation (I’m trying to write a blog post here, not publish another book). On any given turnkey project that we would run as an organisation on behalf of a customer, we would end up with an small army of very clever, highly skilled consultants working on their respective areas of the infrastructure, all the way from designing, racking and cabling physical servers, through the network and storage stacks, virtualization stacks automation and orchestration, before getting ready for the application consultants like the Exchange and SQL gurus to turn up and work their magic.

The point I’m trying to make (and it was mentioned a few times during the twitter conversation), Devs and IT need each other. For now and for the foreseeable future, Developer and IT functions cannot be 100% consolidated without cutting corners. John also said something that makes me think evern more. He said, "I think a lot of this is just that Devs finally can do what they want instead of shitty tools"

The content of this post is just my opinion, and an opinion that was actually only formed during the last 24 hours, and an opinion that is likely to change as I keep thinking it through.

Written by  2 comments
Last modified on Saturday, 04 April 2015 15:39
Rate this item
(1 Vote)

Comments (2)

  1. Simon

It's funny, I come from an infrastructure back ground, I work for an organisation that now finds itself DevOps heavy and unfortunately the Devs in that place either don't want IT or think that they can do IT their way and not worry about it.

My...

It's funny, I come from an infrastructure back ground, I work for an organisation that now finds itself DevOps heavy and unfortunately the Devs in that place either don't want IT or think that they can do IT their way and not worry about it.

My frustration is that the Devs think they know Infrastructure, they think they can do away with IT and just rely on automation to do everything for them. Server hardware breaks, easy, rip and replace and be done with it. In the ideal world sure I can see that but in the real world it's never quite as easy as that, it's never simply a case of build another server.

The other thing that I am experiencing at the moment is that the Devs want it all their own way, they don't want Enterprise level software and support, they want FOSS, they don't want the Enterprise level SDN provider with over 300 implementations, they want the one with 26 (world wide). They want to re-invent the wheel and do it their way and unfortunately it's not the Enterprise way and they can't understand why having an Enterprise Support agreement in place works better than relying on a developer in Bulgaria to fix something... maybe.

I know that working with the team I do that none of them would accept a position in a company that is currently DevOps heavy because of the frustration of working to their tune. Currently it's all their way or the highway.

We had a working Cloud Solution that was canned because it wasn't owned\operated by the DevOps guys, they are replacing it with their own solution, never mind the 2+ years it took us to implement, they think they can do it in 6 months.

Read More
  Attachments
 
  1. BSA

I'm a 15 years IT pro and I do disagree on few points. First of all the complexities of IT which you mentioned of course exist, but what if one day you won not have to deal with them at all, past design and install or just past design point ?

Cas...

I'm a 15 years IT pro and I do disagree on few points. First of all the complexities of IT which you mentioned of course exist, but what if one day you won not have to deal with them at all, past design and install or just past design point ?

Case in point converged systems build from Industry leading blocks - aka VCA (Cisco + EMC)
Step forward to so called hyper-converged - VMWare EVO:Rail - No need to worry about FOSS. All the enterprise support you want from giants like HP and DELL.
I don't AWS, but API level load provisioning on Azure seems like need for pure IT would shrink considerably.
And this is just today stuff. What would show up in 5-10 years??
Lets just say - The sooner I switch to DevOps the better it would for my own carrier.
YMMV.

Designing IT backend - yes - this would stay to be pure IT function, but like CCIE expert - how many full-time employed CCIEs do you know? (outside of MSPs)

Read More
  Attachments
 
There are no comments posted here yet

Leave your comments

Posting comment as a guest. Sign up or login to your account.
0 Characters
Attachments (0 / 3)
Share Your Location

@evankirstel I know what they are for. It just feels wrong to throw a good cable out, even if it seems obsolete
Follow Rynardt Spies on Twitter