This episode of DevOps Chat has us speaking with John Harris of LeftShift IT. LeftShift is based in London, but has customers the world over. He speaks with us about DevOps consulting and continuous testing. John has some great insights to share that I think you will find interesting.
Alan Shimel: Hi, everyone. Alan Shimel – DevOps.com here for another DevOps chats. This episode’s guest is John Harris of LeftShift IT. John, welcome.
John Harris: Thanks, Alan. Good to be here.
Alan Shimel: Thank you. So John, what exactly is your role with LeftShift
John Harris: My role is the Head of Continuous Delivery in DevOps with LeftShift.
Alan Shimel: Okay. And John, you know what? Some people in our audience are probably not familiar or may have not heard of LeftShift IT before. Why don’t you give us quickly a background of LeftShift?
John Harris: Yeah. We’re primarily a services consultancy in the continuous delivery – DevOps continuous testing space. We work quite a lot with IBM, a lot of other different vendors. Based in London and the UK, but we have a lot of our business offices based in the U.S. as well.
Alan Shimel: Sure. And John, before we jump into the subject of today’s chat, which is around continuous testing, I want you to take a moment and just talk about this burgeoning field of DevOps consulting. It seems to be exploding. I was in London for the DevOps Enterprise Summit last month and I was absolutely blown away with the diversity of firms from big to small that are offering DevOps consulting services. How long has LeftShift been in the DevOps consulting space?
John Harris: We’ve been in the area kind of on and off I guess you could say ten years. I guess most people would say DevOps has only been around since that original kind of DevOps coining days again in Belgium, but I guess a lot of people say the discipline itself had been around before the name, so I guess the processes around DevOps you could say we’ve been involved in for quite some time I guess.
Alan Shimel: Sure. And John you know I don’t think we would be seeing this explosion of DevOps consulting if there wasn’t a wanting audience for DevOps consulting continuous delivery consulting services. Is that pretty much what you’re seeing with LeftShift? I assume business is good.
John Harris: Yeah. It’s one of those interesting areas where one of the things I guess the DevOps consultants could say is you don’t just want to create a new DevOps practice in your company. You don’t just want to bring in these pieces, but it’s a difficult loop because you’ve got to then support those processes and you’ve got to get that knowledge into the organization somehow, so I think our model is firmly to go and help people get started and gussy up their own practice and their own good processes and then kind of lead them to it, so yeah absolutely.
Alan Shimel: Got it. So John, let’s pivot a little bit here and talk about continuous testing. So, I will tell you that on DevOps.com the whole notion of testing, continuous testing, automated testing is one of the most hotly debated and in some ways controversial topics within DevOps. Wondering if you see similar?
John Harris: Yeah. I think so. I mean I think traditionally in so far development, testing has traditionally kind of been seen as just the necessary part that you have to do at the end, but I think now that continuous delivery is becoming a real discipline and people are being forced to go faster and faster for getting ahead of the market and things like – can’t afford to see testing as a poor cousin of development anymore and I think testing is really becoming – people realize I can throw stuff out into production as quick as I want really, but actually it’s throwing it out with the quality that it needs to – that product to still be viable in the market. So I think absolutely. The drive towards testing is long overdue, but it’s definitely getting started.
Alan Shimel: Got it. And John, can you have continuous without the automation though?
John Harris: Personally I don’t think so. I think that DevOps really – one of the biggest buzz words for me – DevOps and continuous delivery is really the organization. I think you have to have the process behind it, but I think when you go towards anything delivering more rapidly through all of these stages in our development life cycle in production, I think you just cannot scale at the size that we need to in order to get that stuff out without automating the process.
I mean when you talk about the union it forms like Netflix and Etsy and all of those guys, now three, four years ago, there’s no way you can deliver that kind of scale without putting in the automated tool in and also the processes and the culture around that to enable that to where it will have the effect that you need.
Alan Shimel: Sure. So John, I think one of the controversy – not controversy, but one of the big discussion points around this though is what does this mean for the traditional Q/A role and for the people in the Q/A space?
John Harris: Yeah. I think teams have traditionally kind of been split. I mean obviously we have these silos and DevOps as kind of trying to address the silos of development and testing and ops and those kinds of things. I think again, testing’s one of the things that gets left out of that, but certainly in the customers that we work with, we’re seeing a lot of Q/A teams being retrained in certain ways, brought into the development side of the organization, having their practices changed to more of a development software engineering kind of way of working.
We’re certainly seeing some of the geographic splits that have been traditional in this area kind of being broken down, perhaps testing, quite a lot of off shoring work in testing. Some of that’s coming on shore. Testers are becoming more technical but yeah, retraining and the different skills required now for the Q/A role, to bring that into more of a technical automation. That’s certainly a question a lot of our customers are grappling with right now and I think the decisions they aren’t just technical, but they go into the culture side of the company and how the company has organized itself. So yeah, it is a contentious area. I agree.
Alan Shimel: Yeah. It certainly is and it’s really one of those – for people in the Q/A space, it’s a pocketbook issue, right? They perceive a threat to a livelihood, even though I don’t think that’s the case. I think it allows them actually to soar and higher and do bigger and better things, but there’s certainly that element to it.
John, I want to talk for a moment about service virtualization and we actually have a webinar coming up on I think it’s August 23rd where we’re going to looking at a real unicorn company – Mertz Shipping Lines, which is I think is 80 years old or something in traditional shipping, not what you would think of as your Google, Facebook kind of company. But they’re going to be talking about service virtualization, shifting left. Thoughts on that at all?
John Harris: Yeah. Service virtualization is an area that we work with quite a lot, especially around the IBM tool set. And yeah, Mertz is doing great work. Almost all of the organizations that we work that are trying to do some kind of parallel development, I mean one of the patents that we see is building the y and Rex API layers on top of some of their legacy – so business services and things like that and they want to do some parallel development with the ____, with the Rex, with the user in space layers. So SV’s really able to give those teams a really solid platform because everything’s based on their service interface definitions and it can really do some proper parallel development there and we’re seeing some great shifts left with those development teams and actually the ability to identify a whole bunch of defects before they would even go and integrate with each other.
I think we had one team who identified over 100 defects in the early testing stages using service virtualization before they even would have integrated with the other services. They were able to get those fixed even before they went into their next integration environment, so that was a really great success story – service virtualization.
Alan Shimel: Yeah, absolutely. I think I interviewed the Mertz guys at Interconnect last year and it was an interesting case study. I guess we should mention – there is a Service Virtualization for Dummies book that people can download and I don’t have the URL in front of me. I’ll try to include it in our notes. I think it comes out from IBM for people who are interested in this. But John, let’s return – what do you see – what in your role with LeftShift, what do you see as sort of the next frontier where the – not the battle, but where there are points to be made, where there are battles to be won for lack of a better word in the near term future?
John Harris: I think the biggest one really and we’re starting to see the shift now, but it’s still early stages and the custom is that – for the unicorns and the startups, this is probably not going to be a big bull, but certainly for enterprise – user interface testing is still very prevalent and we talk about the testing pyramid how most of our tests are one of the unit tests and then we’re gonna have a good base of integration tests and then a small percentage of UI test if you want.
I think currently a lot of our organizations have one of them that’s flipped on its head because it’s easy to do UI testing and reason about it going to the business, but now when we go faster, I think the traditional focus on UI testing is going to have to go away, but when we talk about APIs on top of everything and things like the API economy and a lot of systems now just don’t have UIs. Coming out with a lot of systems that are all API driven and smart devices.
I think everything’s going to have to be integration tested. I think the APIs and the logic behind them is really where the core business functionality is, so I think that’s where the importance is gonna be and it’s going to be moving organizations and showing them that integration testing and API testing is not the way to go and obviously automating that as part of their delivery pipeline, which is sometimes a little more difficult to do on the UI side.
Alan Shimel: Yeah. Quick question on that because I thought about how to deal firsthand with this issue. Shouldn’t the API testing – at least the tests themselves come from the same people who are writing the API? In other words, where’s the burden? Should the people who are providing the APIs also provide the testing for it or is that sort of letting the wolf in the chicken coop, right? Where you’re using someone else’s API. The burden is on you to make sure that that is in fact working with your system.
John Harris: Yeah. That’s a really interesting point I think and there are different kind of philosophies around it. Myself, we work a lot with the virtualization and the testing side of it, so we would say that if you’re developing the interface then you’re also in charge of developing the basic virtual service for that to integrate with your consumers, but I’m very much on the side of consumers developing the API test or the APIs that you consume, because if you think about the case where I’m a consumer, I may not need every field in an API. I may just use a few if I’m developing loosely coupled micro services let’s say.
So I’m really in favor of each team who consumes an API developing their own tests and then contributing those tests to the API team so they can be run as call, every build or every deployment. So then if I change functionality and those tests fail, I know which team gave those tests to me and I can go and alert them, “Well, look I’ve made a change and I’m just going to break your implementation or your call of this API, but I may not have broken anyone else’s.”
I mean I think putting the burden to test every piece of functionality, especially as we go to more loosely coupled services is kind of an unreasonable burden on the team developing that API.
Alan Shimel: Got it. You know what, John? Believe it or not as I told you I think before we went live, time goes really quick on these and we’re coming up on the end. If someone wants to find out more about LeftShift, where can they go?
John Harris: I think it’s LeftShiftIT.com and we’ve just revamped out website, so they can find out all about our services and products and everything we offer on there.
Alan Shimel: Okay. And then finally John, I wanted to end with the kind of question I guess I ask just about every guest, which is for our audience out there, if they’re gonna read, what should – if they –hopefully if they do read everyone should read books. What do you recommend is the next book our audience reads?
John Harris: I’m a big Jez Humble fan and I’m not going to recommend Continuous Delivery, because I’m sure everyone’s read that who’s listened to the podcast, but is Lean Enterprise book – How High Performance Organizations Innovate at Scale and it’s Jez Humble, Joanne Molesky and Barry O’Reilly is an awesome book for any enterprise looking to get into this kind of area.
Alan Shimel: Absolutely. I actually have it on my book shelf in the office. Good one, John. Anyway, I think that’s gonna use up our time here on this edition of DevOps Chat. John Harris, LeftShift IT, thank you very much for being our guest and we look forward to hearing more about LeftShift and continuous testing service virtualization going forward and continued success.
John Harris: Great. Thanks for having me, Alan.
Alan Shimel: Thank you. This is Alan Shimel for DevOps.com and DevOps Chats. Until next time, have a great day.
