James Wickett: An Innovator's Journey

James Wickett is one of those people who fly under the radar, but are essential to the foundation of the DevOps community. Through his work in DevOpsDays Austin, his participation in countless podcasts and presentations, and in the work he’s done in the Rugged Software movement, he is one of the most well respected members of the community. 

In this “Innovator’s Journey” profile, we speak with James about his work with DevOps methodologies with his friend Ernest Mueller at National Instruments, his recommendations on how to get started with DevOps, and his desire to encourage the intersection of traditional Information Security and DevOps.



Mark Miller: From the beginning, as a kid, were you a technology guy?

James Wickett: I would say yeah, as much as I could be. I had legos and that kind of stuff. My grandfather would give us his old laptop--which was a laptop in a generous sense of the word--it would be in a large briefcase with the foldout keyboard with the green screen. I guess I was about 14 or 15 years old that my father got us the first computer for our family.

Mark Miller: Do you remember what it was?

James Wickett: Let's see. It was a 233, I thought it was made by Micron or somebody. I don't know, I know it was expensive.

Mark Miller: When you saw it as a kid, did you get it?

James Wickett: Yeah. I was ... I mean we were pretty excited. My friends had computers so we'd always go to their house and mostly just play games or whatever. The internet was still coming out at that point and it was great.

I was just recounting this the other day to my wife. I learned a lot about computers by breaking that computer early on, I think I was trying to install a questionably sourced version of Quake. A friend of mine had a crack. We had it sort of workingand the whole thing blew up. It was like, "Uh-oh. What do we do?" Then we were hunting through Windows config and quickly realized that we didn't know anything about computers.

I started trying to learn how to fix computers from that experience, and became more interested in computers and then quickly followed in college where I enrolled in the MIS program over at the University of Oklahoma.

Mark Miller: You’re a Sooner?

James Wickett: Yeah, from University of Oklahoma, Boomer Sooner! Grew up in Oklahoma, my whole life.

Mark Miller: Where did the transition happen? You come out of school, what do you start doing after school?

James Wickett: During school, I worked as a tech in the computer labs for the business college. Then I got to where I was running some of the back end server stuff there, just part time, while I was also going to school. I got a job down in Austin, at National Instruments as a programmer. It was basically doing some development projects, working Lotus Domino web servers and stuff like that. It was not a good thing to use for a web server but they had a lot of Lotus stuff. I wrote a CMS-like thing fresh out of school -- it was very painful.

Mark Miller: Do you remember the first time you heard of DevOps?

James Wickett: Yes. At National Instruments, I did some web admin work, for several years. Then I went to work at a startup for a while and ended up coming back to National Instruments with my good friend Ernest Mueller. He was moving over to the R&D group to build out cloud services. National Instruments realized they needed cloud services for all the embedded devices (IoT devices) that emit a lot of data.d We wanted to build back end cloud services that we could capture this stuff in.

That was in 2010. I went back to National Instruments and we set out to do devops at the point as well.  My friend Ernest Mueller had just returned from Ops Camp where he found devops for the first time.

Mark Miller: Relatively early, then.

James Wickett: Adam Jacobs, Luke Kanies and some other folks were there and just happened to be in Austin. Then he brought that vision back to the rest of our team and we were like, "Yeah. Let's do this, this makes sense."

Mark Miller: What happened then? You brought it back to the company and you just say, "We're going to sprinkle some magic dust on this thing." What happened?

James Wickett: Nowadays we think of a DevOps team as an anti-pattern. Most people when they think of that, they think of taking your old SysAdmins and turning them into DevOps titled or something like that. We had a DevOps team but in more of a sense of we're basically doing something completely new. It's like a start-up in a large enterprise to build this cloud thing. We had 3 team members that you would consider developers. Then we had a couple of people that were sysadmins and operations folks. We just started working together collectively and collaboratively.

Mark Miller: Did you call it DevOps?

James Wickett: Yes, we called it DevOps, because the name had already been socialized. At the startup, I'd been doing a lot of stuff in the cloud but for National Instruments, they were a larger enterprise. It was new for them so we were already bringing in clouds. We were like, "Let's go ahead and bring in DevOps at the same time. We're just going to start everybody trying to rally around this together."

That's where I really had a great experience with working with Ernest and several of my close friends and several of us blog over at theagileadmin.com together. A quick plug for the blog, it has one of the most widely read papers on DevOps out there.Check it out > https://theagileadmin.com/what-is-devops/ .

Mark Miller: You're currently with Signal Sciences. What's that about?

James Wickett: At Signal Sciences, we looked around at the security landscape and we realized that the way people do things like web applications, firewall, and really web application security in general, really there hasn't been a lot of innovation in there for a while. Some of the core founders were previously at Etsy and they had built some of the stuff that we're doing now at Signal Sciences. We provide a next generation web application firewall (NG-WAF) that is solving a problem that current WAF solutions aren’t able to address. We're adding in visibility, telemetry, defensive countermeasures to everything that's going on in your web application stack. We're cloud native design, with cloud first principles.

We're seeing a lot of uptake with companies that need to scale quickly, and don't have full time engineers dedicated to managing web app firewalls, which is pretty much everybody.

Mark Miller: When you look back at what you've done so far, what are you most proud of?

James Wickett: I have a 4 year old and a 2 year old. I guess I'm even more proud I got their mother to marry me all those years ago. Which I still wonder at most days. I have 2 daughters and they're great.

Work wise, I'm proud of the work that I do and the different projects I have worked on. Really being able to work alongside other people and help other people, that's been fun for me. Helping people have tools and things to really help improve their daily life and put those in place.

Mark Miller: I get asked all the time, and I assume you do too, at conferences is “How do I get started?” Have you found the answer to that? How do you recommend people get started in this?

James Wickett: A lot of it depends on where you're at. That answer's going to vary. If you have a large enterprise versus if you're willing to take the risk to go to a small team and startup. I think we don't do a really great job of mentoring people. I mean it's a new-ish space and even computer science in general is a young discipline. My advice is find a way to go work with other people that are doing stuff that you are interested in. Start there.

Mark Miller: There's no curriculum right? It's not like you can go to college and say, "I want to study DevOps."

James Wickett: Yeah, right, right, yeah. That is not here yet ...

Mark Miller: Is it on the way? Do you think it is going to be?

James Wickett: I don't know. I always encourage folks to get involved in the local DevOpsDays events.  In Austin we have a really big one, we bring in people, a lot of people outside of Texas come to the event.

But it's really crucial to go to the one that's nearest to you and they're popping up in cities all over the United States right now. You get to know the local people that are doing stuff, you get to know local companies that are involved and that are actually active in participating in DevOps or at least verbally acknowledging, "Hey. This is what we want to do."

Then you get to see really great speakers. In the afternoon there's open spaces, you get to ask questions and you get to help others ... There's a different community feel that you don't really get at a lot of other conferences, that you do get at a DevOpsDays event.  I recommend that highly for people that are thinking, “I've been sysadmin for a long time and I've heard of this thing called Chef or Puppet or I'm a developer but I'm not really sure what all this continuous delivery stuff means” to go to DevOpsDays. Find those places where those people are already naturally getting together and just taking part in that conversation.

Mark Miller: Now the hardest question of all is if you were going to look at your role in DevOps, what superhero would you be? Create your own superhero for yourself.

James Wickett: I really want to see the joining together of the security tribe and the DevOps tribe if you want to think of them that way. More or less, I really want to help security find their way forward.

I think security in a lot of organizations, gets pushed into doing compliance type work or they get stuck in heavy, heavy research, pen testing, stuff like that which is a really good thing. You need to have that but I really think that security is today, where operations was 7 years ago, pre-DevOps.

In the organization, they're situated in a similar spot and you get that vibe.

I feel like today when you talk to Ops people, they're noticeably happier about their daily lives at work. They're more engaged about what's going on. Not everywhere, or everybody, but just particularly like a rough happiness index or whatever across the spectrum. I would say, Ops is happier today than it was 10 years ago.

For security, I feel like that needle hasn't really moved and I think it's because they've been stuck in the old way. They haven't really moved in the new model of either moving faster or being part of the value stream of the business and getting involved in that.

Mark Miller: Would your character, your hero, have a shield? Would he have a weapon? What would he have?

James Wickett: Wolverine had those sweet claws.

Mark Miller: Yes, he did.

James Wickett: I'd have a problem going through airport security but that's okay.

Mark Miller: Do you want to protect the security professional? Do you want to ... From the slings and arrows basically. From everything coming at them because they catch all the crap that's coming downhill.

James Wickett: Actually I want to encourage them to morph or to change. To adapt to the new way because in Ops, it was the same thing. Basically you can't work in Ops today like you did 10 years ago and expect to either have a fulfilling job or to even have a job in 5 more years. Everything's trending to infrastructure as code. Security as code is coming.

Some of the research I've been doing for Signal Sciences is around the “web app firewall suck” movement back in 2007. Everybody claimed WAFs suckso we really focused on doing developer awareness training, application security training, OWASP Top 10, all that stuff. We abandoned WAFs in the sense that we just let them do their thing and as a result, we haven’t seen much innovation in that space in more than a decade.

I picked up a whitepaper from a WAF vendor. It was dated 2012 or 2013 and in it, they proclaimed, "You're going to need 2 or 3 full time engineers to manage this." In today's economy, that's untenable for most companies. We want to enable teams to optimize, not to waste precious resources on operational management.  It's a real heavy burden on the company that is wanting to implement this as WAF or something that really adds value. In Operations, when we had performance problems and we had database connections overloaded or whatever, we didn't have the tooling to find the root problem. We'd have to troubleshoot it, take days, weeks or whatever. Nowadays it's almost as simple as install New Relic.

I just haven't seen that change yet in security. I feel like there's an uptrend or an uptake towards that but we still have a ways to go.