Business Leader Interview with Manish Mathuria

Learn how Infostretch can help with your CI/CD maturity

Alan: Hi, Alan Shimel here of here at Jenkins World day two. And our first guest today is Manish Mathuria.

Manish: That’s correct.

Alan: We did it. Manish is CTO of Infostretch, and they’re a big player here at Jenkins world this year. Manish, first of all, welcome. I think this is the first time has interviewed Infostretch. Can you give our listeners a little bit of background? Who is Infostretch? What do you do?

Manish: Infostretch is a services company, Alan. We are about 800 people strong. Our headquarters is right here in Santa Clara; walking distance from here.

Alan: That’s convenient.

Manish: We largely focus in three main areas: quality engineering, optimizing quality and making everything automated is the biggest part. We also do a whole bunch of front end development around digital technology. So we do mobile apps as part of that.

Alan: Oh, you do?

Manish: Around responsive design; anything that goes more front end as opposed to some more around system self engagement. And the third thing that we – by extension we’ve got drawn into is this whole CI/CD. So we’ve been very active in it for the past three years, doing CI/CD DevOps and a bunch of activities around that.

Alan: Who is sort of your typical customer?

Manish: Being in the Valley, definitely a big part of our customers are really kind of well-funded growth companies. So they can be the startups getting into the growth phase; so anybody whose quality and skill is important. The second part is – second segment I would say of our customers are enterprise organizations. So broadly Fortune 1000, some of the big companies in the Valley in healthcare, financial services, retail are our customers.

Alan: Is it geographically – though headquarters are here, most of your customers are here, too?

Manish: No, we have an office on the East Coast in New York. So we have a fair bunch of customers on the East Coast. We have also an office in London, and therefore we have customers around UK and we serve the rest of Europe from there.

Alan: UK is just exploding. Do you have a lot of customers then who span both UK, New York, and multiple offices?

Manish: Yes, interestingly is our story is that we got almost pushed to start our Europe operations because our customers were looking to expand.

Alan: So you followed your customers there.

Manish: We followed our customers and now there are again use cases like that coming up where customers are expanding in Asia Pac, in Singapore, etc.

Alan: Looking? Yeah. Well, you have to go where the customers are.

Manish: You have to.

Alan: So are most of your engagements more – so is it a body shop type of engagement where they’re hiring people in? Or is it a project kind of engagement?

Manish: So you know, most of it is some kind of an IP-led initiative. So the company, we are very committed to building IP around which we do our projects. So to answer your question specifically, it is most of it is some kind of a managed activity, which typically starts from some level of strategy. So a typical customer would come in and say hey, we’re looking to do DevOps or we’re looking to do quality engineering and these are our pain points. And for most of our services we would have a maturity model along which we would help place a customer on multiple dimensions.

So if you look at DevOps, then what is your organizational maturity, what is your CI maturity, what is your CD maturity? And then we help build a blueprint on which we advance our customers. So in the more standard price scale customers, this tends to be a multiple months’ process. We start through like a very localized implementation, then expand it to enterprise-wide. So it’s very, very project-driven, very, very IP-driven. We are bit committers and big believers in open source. We have released or own automation framework in open source that we and our partners use. So yeah, it’s very technology-driven.

Alan: You said you’ve been doing this CI/CD for about three to four years, now. And I imagine it is rapidly a high growth area of the business?

Manish: Yes, it absolutely is. Most organizations are doing the CI in pockets. So you would have a particular project doing their own CI with Jenkins running under their desk, under some developer’s desk. And because it’s working, nobody worries about it. The day it breaks down, people start to kind of run helter-skelter and try to fix it. So most organizations that we come across are somewhere around that kind of a phase and they’re looking to mature that.

Thereby we found it very prudent and relevant to partner with CloudBees because that’s their story, as well that we need to kind of advance these organizations to get into a level where they take these things more seriously and look at it from the enterprise perspective. Have the quality of service of higher availability, security, all those aspects of any – particularly in the CI/CD infrastructure it’s becoming very relevant.

Alan: Excellent. You brought up the partnership with CloudBees and obviously you’re at Jenkins World. And before we get into more of the partnership, I wanted to kind of get your thoughts on is this the first time you’ve attended Jenkins World?

Manish: No, this is the – I’ve attended Jenkins World before, at least a few times. This is the second year we are having a booth here.

Alan: A booth here. It’s much bigger this year than last year. It’s a pretty big event. For our audience who probably haven’t had the chance to be here, what can you tell them about Jenkins World this year so far?

Manish: It is – you can see it is very widely attended. I think the concept of taking CI and Jenkins being the center of your CI effort from running under your desk to making it more enterprise is getting more mainstream. So now everybody is worried about what if my bills break down, what if my deployments break down because there is so much glueware that goes around this; there is so much tribal knowledge that goes around it that unless you automate it, it can be a huge productivity sink.

Most people don’t realize it because it’s working somehow. But to optimize this process and remove the tribal knowledge and make things automated is just there, and it happens to be single biggest sink of time and productivity.

Alan: I think what you just hit on there is also the driver for moving from Jenkins to CloudBees. It’s one thing to use an open source tool in pockets and – but once you start getting into enterprise scalability, SLAs, uptime, and these kinds of things, that’s I think traditionally where we see enterprises move from the open source to an open source supported commercial version such as a CloudBees. And it’s not just Jenkins CloudBees.

Manish: Or Red Hat.

Alan: Red Hat is the perfect example, or Red Hat Enterprise Linux versus what – you know, Fedora. We’ve also seen what Puppet and Shafton and some of the others here in DevOps. And speaking of some of the others here in DevOps, this leads us to a big announcement hear yesterday around something called DevOps Express. We spoke with a number of people – with the folk from CA and a few others about DevOps Express. But why don’t you give our audience – what is DevOps Express to you? What do you think it is? Or how would you describe it?

Manish: Sure. So DevOps Express is basically an initiative which allows multiple organizations to come together to establish reference architectures, industry blueprints, best practices so that an initiative that is going to take a lot of pain and a lot of effort in getting it right can be expedited. In general in the marketplace, there needs to be far less room for not learning from mistakes. If it has taken us 24 months to three years to actually optimize what we would go and offer to our next customer, to the next and next customer, that should really shrink down to a matter of weeks. Or else how else are we actually helping the community, and how are we helping our customers?

Alan: I call that saving the idiot tax.

Alan: DevOps Express, if you look at it broadly, and we talked about it yesterday as well, it is largely about glueware and change management. Basically there are so many dispersed endpoints when you look at a pipeline that goes all the way from check-in to – even forget deploying but getting something ready for deployment; there are about 30 different touchpoints to different systems in there. And no one product can solve that problem. So if you think about it, you can’t say that CloudBees get in a corner and come out with a formula that will apply to all organizations.

It requires really a multi-party engagement, including companies like us who actually can go out in the marketplace and implement these things to make this successful. Yes, there can be a lot of skepticism around how would this all work but I don’t really see an alternative to it. It has to work. Otherwise, you know, every customer that we go to will have the same learning process that comes from change management, creating –

Alan: And the same pain and the same idiot tax. It’s that same – I think that’s a big part of it. So when we look at this DevOps Express, though, there’s tool vendors such as a CloudBees, and Puppet, Blaze Meter, more of a software as a service but tool vendors nevertheless. And then you are, right now I think anyway, the only one in the group that’s more of a traditional service integrator, if we will. And you and the DevOps Institute, they’re a training but they’re also not a tool provider. So this represents a different outpost, a different look for the Express. Do you think we’ll see more integrators join in as time goes on?

Manish: I think there’s definitely room for a lot more integrators. Because like I said, unlike a lot of other aspects, if you take development or testing, right, there’s a good part of it which is directly solvable by a tool. You install this tool and you can figure it or you customize it and it starts working. DevOps is a different beast. It is very integration-centric. Bulk of it is actually putting together somebody’s work process or work flow in and translating it to a core that works with these 25 different endpoints, which is all system integration. I think there is room for a lot of engagement from other system integrators.

Alan: Absolutely. You know, one of the things Manish that I’ve seen, and I’ve been to London and a lot in Europe as well as across the U.S. here – haven’t been to Asia as much – is the rise of what I call DevOps integrators; this whole DevOps consulting where so many companies, they want to do DevOps. They know they should; they almost have to to compete. They’re just not sure. It’s one thing, as you said, to just get a tool, right?

I could take a hammer and I could bang a hammer, knowing where to bang that hammer, knowing how to get the team to bang the hammer in the right way and in unison, that cultural thing. How do we kick off those DevOps transformations? How do we get these people started? And I think that is still a big hurdle for many organizations today.

Manish: Right. I can tell you how we do it. First of all, we have a start from assessing where you are to where you’re going. And like I said, I talked about a maturity model. We’re working with CloudBees and the community in general to kind of make it more adaptable so the quadrant play round – basically it’s about assessing an organization and saying okay, you fall in this quadrant. And that’s not to say in a demeaning way but you know, it’s like here you are and within a particular quadrant of maturity around in general around DevOps, this is your maturity; this is your capability.

And you want to be there, and not just because everybody wants to be there but these are the business goals around which you want to be there. So that is the first step, to understand okay where you are going and like everything else today, it’s a very dynamic world. Today you think you want to go there but it needs to be continuously reassessed.

So that’s one part of it. And the second part is having a whole bunch of acceleration around it. For example, we have these pre-created pipelines. They are, if you will, reference architectures for the common stacks. So we would have one for mean stack, for your Java concord-based stack or we would h have one for IOS, one for android. And what this is, you know the common pipeline, which goes everywhere; everything from check-in to deploying it in the marketplace –

Everything automated in there with quality with – now, none of these things we can take it and as is put it in a customer’s hands. So what we have to do is that becomes an excellent pool for communication. We say okay, look, this is how we have implemented in a reference way. Now let’s talk about where this needs to go –

Alan: We customize…

Manish: Exactly.

Alan: You know what? So a hundred years ago, I had helped start what we called an ASP in the dot com days. And we were offering hosted notes, hosted people soft, hosted org, [inaudible]. No VM. Bandwidth was expensive. It was very hard. But we thought we would be able to host these out of the box. And what we discovered is never – 75, 80 percent and that’s the best – you always need to customize the last 15, 20 percent. So I understand. Manish, we’ve gone way over our eight minutes. I apologize.

Manish: Right, no problem.

Alan: But we’re gonna – we could continue this conversation maybe in a podcast or something remotely. But thank you so much for joining us today. Manish, I’m not going to say your last name –

Manish: Mathuria.

Alan: Mathuria from Infostretch, a member of the DevOps Express here at Jenkins World. Thank you for joining us.

Manish: Sure. Thanks, Alan.

Alan: This is Alan Shimel for