devopsy.kinsta.cloud

Category: DevOps Chats

DevOps Chat: Prem Chandraskearan, VP of Software Engineering at Barclaycard

In this DevOps Chat we spoke with Prem Chandraskearan, VP of Software Engineering at Barclaycard. Prem led the DevOps transformation there. He sums up his learning thusly:

The best way for an organization to approach DevOps is from a collaborative angle. When development and operations experts actively work together in a cohesive effort, solutions are well designed, efficient and smart from both a development and maintenance perspective. When operations is viewed as a software problem, Dev and Ops can work in tandem to implement a tool that is holistically a part of the process from start to finish.

DevOps is always a work in progress, but the initiative can only improve with quality resources that implement a variety of backgrounds and perspectives on both Dev and Ops working together. Barclaycard has had some interesting challenges with DevOps due to being in the credit card/banking industry, so for example, the “you build it, you run it” mantra doesn’t work as well for us as it would for other enterprises implementing DevOps. It is definitely a learning curve, and our goals and best practices are still coming to fruition, but we are continuing to find ways to automate.

The best way to get teams to work together is to simply ensure that they are not in silos, meaning that if there are distinct dev and ops teams, they must spend time in each other’s sectors to understand the pains, how the functions work, what makes it tick, etc. When the development and maintenance perspective are strategized in tandem, it automatically makes for a better, more streamlined workflow.

The best way to ensure a DevOps initiative’s long-term success is to ensure that the foundation of the program is collaborative and understanding of how each function works. With this, automation testing for failure is imperative to discover problems that are typically only otherwise found in production. If all the bases are covered and the process is streamlined and collaborative, the overall quality of your DevOps function will be much higher.

As usual, the streaming audio of our conversation is immediately below, followed by the transcript of our conversation

Audio

Transcript

Alan Shimel: Hi, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Got a great chat scheduled for today. We’ve got a real, live DevOps practitioner. I’d like you to welcome to the show Mr. Prem Chandrasekaran—and I mangled that terribly—Prem, why don’t you give us proper pronunciation?

Prem Chandrasekaran: The name goes “Prem Chandrasekaran.”

Shimel: Fair enough. I don’t think I did that bad then. So, Prem, you are a software group leader at Barclaycard US, correct?

Chandrasekaran: That’s correct.

Shimel: Okay. And, well, before we get into it, let’s make sure that, in case people aren’t familiar with Barclaycard, who they are and what they do, if you wouldn’t mind just giving us maybe a quick little background on that.

Chandrasekaran: Yeah. So Barclaycard in the US is a credit card provider. Our primary business is co-branded credit cards, so, for example, when you’ve got an Apple credit card, if you look carefully, it actually says “Barclaycard” on it, in the background somewhere, but we’ve got a whole bunch of partners like that and we provide credit card services for our partners and customers through the co-brand. We also have a consumer lending business, which is a lot recent, but the credit card business is what is our primary revenue _____ _____, if you wanna look at it that way.

Shimel: Very good. And, Prem, in your role as software leader, what exactly does that mean? ‘Cause it means different things in different orgs.

Chandrasekaran: Yeah, yeah. So my actual title is that of a vice president, but, you know, what I was hired to do was to incept this new line of business. We were coming up with a new line of business called “consumer lending.” And our infrastructure, both hardware, software practices, all of those were on a pretty old legacy system, and we had two choices. One was that we would build on top of the legacy system or create a new platform, as we wanna call it, have all of the modern techniques that we use, including CI/CD, a lot of XP factors, and so on.

And I was brought in as a consultant first when I took the role on full time, two years ago, to lead the launch of that new consumer lending business. And I’ve been doing that. And now we’re trying to apply the same processes, software, hardware, all of those solutions, onto the credit card business, as well as we try to migrate.

Shimel: Excellent. And how long has this project been ongoing?

Chandrasekaran: Consumer lending started somewhere in 2015 and we launched at the end of 2016. It’s been live for the last 18 months or so. And what I’ve been doing after that is, again, I’m still in charge of making sure that consumer lending runs in production, but we’re also building what we call a “global platform” – basically, a set of design patterns and application templates and CI/CD pipelines to allow us to create new services, migrate existing ones, and develop what we call the platform –

Shimel: Oh, sorry. Go ahead.

Chandrasekaran: Yeah, so what I’ve been doing is we’ve been defining the learnings from what we did for consumer lending and making it available to development teams here, so that they can focus more on the business-logic portion of things, solving real problems, as opposed to grappling with a whole bunch of the surrounding stuff, nonfunctional stuff like log-in monitoring, CI/CD pipelines, tracing, and authentication authorization, and so on and so forth.

Shimel: Correct. So, Prem, I didn’t hear you mention security or cyber security, though, and that’s obviously something that’s important anytime we talk about financial services. Where did that play in, in the program here?

Chandrasekaran: I mean, we like to think that it’s something that starts with the code that you write, you know, so we make sure that all of our developers and teams think about security right from the ground up. And we have tests, both static and dynamic and penetration test frameworks, which check the state of the code that you’re developing from a security perspective, right through the CI/CD pipelines. And you’ve got a whole bunch of automation and a bunch of manual penetration tests that the teams do, to make sure that we are producing things that are secure not only for ourselves but also for our customers.

Shimel: Got it. So, Prem, let me ask you a question then. What I think is interesting is this was a project that, as you said, started in 2015, and here we are, 2018, talking about some successes you’ve had. And now rolling some of the lessons and learnings and success from that throughout other parts of the organization. And that actually – no two DevOps transformations, no two experiences, are exactly the same, but that’s right in sort of the sweet spot of how we see DevOps expanding within an organization. You get a project and many people are surprised that, in spite of the speed and automation that we think about in DevOps, it actually takes time. It takes time to launch a project. It takes time to bring a project to market like this.

But, once that’s done and you have good results, part of that DevOps way, if you will, is to take the feedback loops, take the learning, take the lessons learned, and apply them in other places within the organization. Prem, what about executives sponsorship of this, if you will? I mean, you’re a group leader, but, above you, what kind of buy-in or sponsorship did you have from your exec team

Chandrasekaran: Oh, absolutely. I mean, without exec sponsorship, I don’t think we would have progressed to where we are. I mean, we’re by no means done, but, you know, we are still in this journey and we’ve got a very solid leadership team which basically said that we need to operate not as a traditional bank, but as an IT organization, rivaling the best in the world, right? And that’s where we want to be. And it starts from there. And it percolates pretty much every single facet of our organization, starting form hiring to the way that we think. Basically, you know, DevOps is really a means of shortening the cycle of getting a product out of the door reliably and repeatedly, right?

Shimel: Yep

Chandrasekaran: So it does take a huge amount of effort in terms of the automation and the processes that we need to put in place, but, yeah, I mean, we’ve got very strong support from our leaders to help us transform the organization that way.

Shimel: Okay. So, Prem, let me put you on the spot here a little bit. We have listeners out there saying, “Wow, this guy’s done a project where they did this,” right? If you could – and we didn’t discuss it, so I apologize for putting you on the spot – can you give our listeners sorta three things they should avoid? What were the three biggest lessons you learned in the course of this project?

Chandrasekaran: Yeah, so, okay, I’m gonna try to look for three things, right? Okay, so the first thing that comes to mind is that, at least at a place like where we are, in a bank, right, buy-in is very important. So you might have buy-in from the top, but you need to have buy-in from pretty much every facet of the organization, that automation isn’t a threat to their jobs and existence, right?

Shimel: Mm-hmm.

Chandrasekaran: Where, you know, it’s normal that now our time and operations person – “Oh, my job can be automated and now I’m out of a job.” Right? That’s one thing that it’s largely a psychology thing, where you have to address that and give people the confidence that that’s not the motive here. The motive here is to churn out software fast and enable both DevOps, business, QA, information security – I mean, you name a whole bunch of these groups – it’s about collaborating and working closely together to achieve the end, which is putting out software solutions for our customers and our stakeholders repeatedly and reliably, like I said before. That’s one. It’s more of a mental shift that needs to happen. And, unless you do that, you’re going to meet with a lot of resistance.

The second thing is in terms of who you hire, right? Like I said, it’s a mental thing. It’s a philosophy where you need to have likeminded people who want to do the automation, as opposed to doing something that’s manual and error-prone, right? So hiring the right kind of people definitely is second.

And, third, it also needs your business folks to be patient while these transformations happen, where you might not see the benefits of it on day two, right? It takes a while for the benefits to start appearing because it does take a lot of practice. And we’re not there yet in terms of saying that we’ve achieved perfection – I guess nobody can say that – but it does take a few patient stakeholders as well. I mean, those are my three things.

Shimel: Excellent. So, you know, Prem, when we started, I said the 15 minutes go quick – we’re wrapping up here – but, again, for our listeners who maybe are contemplating or in the throes of their own DevOps journeys, I mean, this is certainly a success story to date. What else – I mean, what’s next here, though? Beyond what you’ve already mentioned to us?

Chandrasekaran: Yeah, you know, so, right now – I mean, our next step is to scale this out, right? I mean, we’ve got one product line that is using all of these, and a bunch of the rest of the organization, at least here in the US, has drawn a lot of inspiration from the successes that we’ve gained here. You know, we still operate in a private-cloud environment. We’re targeting going to the public cloud, which basically means that we now allow ourselves to scale a lot more quicker and a lot more faster. So, yeah, I mean, that’s probably the next step, where we’re targeting the public cloud and provide value to our business and customers a lot more quicker that way.

Shimel: Excellent. Excellent. Well, Prem, thanks so much for giving us a little bit of insight into how Barclaycard US has leveraged DevOps here and has started out on their own DevOps journey. We’d love to hear more about it in the future; maybe we can check in.

Chandrasekaran: Yeah. Thank you very much, Alan, for having us.

Shimel: Okay. Prem—and I’m not even gonna mess it up or attempt ’cause I will mess it up—Prem, thanks so much for joining us here on DevOps Chat. This is Alan Shimel for DevOps Chat and we hope to see you soon on another DevOps Chat. Have a great day, everyone.

— Alan Shimel

April 24, 2018
DevOps Chat: The CEO’s View with Derek Langone, XebiaLabs

This DevOps Chat features “the CEO’s view” as seen by XebiaLabs CEO, Derek Langone. Derek is one of my personal favorite CEOs in the DevOps space because he is very articulate, to the point and sharp. I think all of these characteristics come through in this DevOps Chat. As CEO of XebiaLabs, Derek is leading one of the leading companies helping transformations in enterprise DevOps. In this chat, Derek talks about with us about cloud and cloud migration.

As usual, the streaming media of our conversation is below. The transcript of our conversation follows below that.

Audio

Transcript

[su_pullquote align=”right”][su_custom_gallery source=”media: 122032″ link=”post” target=”blank” width=”200″ height=”200″ title=”never”]Derek Langone
Derek Langone has been the Chief Executive Officer of XebiaLabs, Inc. since April 21, 2015. Mr. Langone served an Executive Vice President of Global Sales at Telerik, Inc. since February 2014. Prior to Telerik, he served as the Chief Executive Officer of 5nine Software where, in less than a year, he significantly increased revenue, lead generation and conversion rates. He served as the Chief Executive Officer, President and Chief Operating Officer of SmartBear Software, Inc. (also known as AutomatedQA Corporation). He served as the President and Chief Operating Officer of SmartBear, Inc. He began his career on Wall Street focused on technology investing. For over 15 years, he has focused on building and scaling Technical Sales Organizations. Prior to SmartBear, he served as Vice President of Sales at Quest Software and IMCEDA Software. He held senior Sales Positions at Vality Technology, (now IBM), Embarcadero and SAP America. He is an Industry Veteran, has more than 15 years of expertise in cultivating enterprise IT and application development adoption. He has been a Director at XebiaLabs, Inc. since April 21, 2015. Mr. Langone holds a Bachelor’s Degree in Business Management from Boston University.[/su_pullquote]Alan Shimel: Hey, everyone, this is Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps chat. Happy to be joined today on DevOps chat by Derek Langone, CEO of Xebia Labs. Hey Derek, how are you

Derek Langone: Alan, I’m excellent, thanks very much for having me today.

Shimel: Thank you. Just a heads-up to our audience, I had been working on this for a long time. Derek’s agreed to be sort of a regular guest here on DevOps Chat and we’re looking forward to hearing from him, oh, maybe once a month or so on topics that are of interest to hopefully our whole audience so you know they’ll be around DevOps and related to technologies.

So, this is the first one we’re doing and we were going to talk today a little bit about cloud and whether you already are a cloud customer or new to the cloud, how can DevOps and related technologies help you.

But before we do, Derek, in case there’s anyone out there who maybe is not familiar with Xebia Labs, you want to give them a real quick kind of pitch on Xebia Labs and what you guys are doing?

Langone: Sure, here’s the 30-second commercial. So, Xebia Labs is entirely focused on enterprise DevOps. We provide a software platform for large enterprises that encompasses three primary components, released orchestration so basically create your pipelines in our technology that are templated, repeatable, standardized, use our automated deployment engine which is a model-based agentless engine.

And then lastly, we have a machine-learning and AI-oriented reporting engine that collects all the data associated with your journey from development to production. It allows you to report on that for things like compliance purposes, regulatory purposes, security, and just a good old-fashioned scorecard – am I going faster? Is my quality up? Are my customers happier?

Shimel: Couldn’t have asked for more than that in 30 seconds, Derek, thanks. So, here’s the deal, we are approaching I think this year a threshold in cloud adoption where it’s something like 50 percent of enterprises will have significant infrastructure in the cloud, not just a toe in the water or an R&D project, but significant infrastructure in the cloud.
And that’s big, right?That means half of all enterprises have a large investment in cloud. But it also means half, don’t, right? And that’s always the flip side of the coin. I want to talk today to both of these audiences but let’s first start with the half that already has, right?

They’ve invested a lot time, a lot of money, probably a lot software or tools and personnel, but maybe they’re not getting everything they need out of their cloud deployment? How can DevOps help?

Langone: Well, DevOps by principle is sort of an accelerate opportunity, right? And if you look at a cloud investment, it’s a similar value proposition that you don’t have the requirement to manage this infrastructure, you’ve got less administrative overhead, you’ve just got on-demand, scalable infrastructure. So, that’s all oriented around speed.

The challenges we see with our customers that are generally large enterprises, the biggest banks, insurance companies, airlines, in the world represent our customer base. They’re moving aggressively to the cloud because it’s just generally less expensive and certainly much less administrative overhead.

But the consequences, the applications they’re trying to get there are very complex and don’t necessarily lend themselves to moving to the cloud very neatly. And what I mean by that is if you use an example like a large bank might have a money transfer application, core to every business that’s a big financial institution.

That application lives in many places; the back-end horsepower may be a mainframe, there’s referential databases that do some validation every time there’s a query. You’ve got distributed architecture, maybe a containerized front end that gives you your mobile banking access and things like that.

Moving all of that to the cloud is not simple, it really requires an incredible amount of orchestration, some very sophisticated deployment functionality. And we see most of our customers when we get engaged, them trying to do that with either the simple tools that come with the cloud platform providers, you know, the out-of-the-box Amazon or Azure tool portfolio.

Or in most cases, just using the good old- fashioned, using extremely talented valuable developers to write tons of scripts to try to move these components around and shift them to the cloud. Neither of those initiatives are generally successful.

Shimel: And I think you just hit it, Derek. Those are the two ends of the dumbbell if you will, right? One is to use the vanilla tools that the cloud providers give you and not to bang anyone but AWS is notorious for this, right?

They give you 60 percent of the functionality at a really low, low price of some of the best __ tools but it comes bundled. Or you go the other way, right, just totally customize the heck out of things, which is not scalable usually, nor repeatable.

Langone: No, it’s not, that’s the challenge. And just to hit those two ends of the dumb-bell as you said, the tools that come with the cloud providers, I mean, look, they’re sort of minimalistic by nature because it’s not the core business that they’re trying to provide. They’re infrastructure providers, they’re really not deployment technologists, right?

So they’re gonna give you a little bit to get some basic applications there but anything complex is really gonna fall down. And like you said, the other side of it is, and the more traditional approach, is just using your engineering assets to write a ton of scripts to provision infrastructure, to migrate applications, to request instances.

You know, it’s just an incredible amount of plumbing code that gets written that is super low-value and basically comes at the expense of much higher value activities that those engineers could be participating in, things like building new features and fixing bugs and just basically delivering more customer value.

Shimel: And with that approach, Derek, to me it’s always been, well, what happens next month when I have to do this again? I’m gonna rewrite all the scripts, waste all that time? It just doesn’t make sense. But you hit on this with your opening, the reality is that most of these organizations who may already have significant infrastructure in the cloud are not totally in the public cloud certainly.

They still do have mainframes, they have stuff in the closet, they have stuff in the data center. They’re living in a hybrid world, right, Derek? And so for whatever reason, and I’ve heard this from numerous, they hate the idea of using one tool for their public cloud stuff, one tool for their on-print stuff, one tool for their private cloud. They want one throat to choke, right? They want one tool.

Langone: Well, I think they want one platform that can kind of account for the migration and IT landscape that they are going through, right?

Shimel: Yes.

Derek Langone:And that’s sort of what we’ve tried to build at Xebia Labs. We work with the legacy infrastructure and give you velocity, repeatability, standardization for your mainframe deployments in the exact same way that we will accelerate your journey to containers and leveraging Kubernetes and Docker as well as, you know, getting onto what is generally hybrid cloud infrastructure.

We definitely see large organizations leveraging things like Amazon but in most cases, they’ve got some combination of a data-center cloud that they’ve got under their own control, as well as the sort of less mission-critical applications or the things that don’t represent the family jewels if you will in true public cloud infrastructure.

And when I talked to CIOs in these organizations about their aggressive shift to the cloud, they look at me and say, look, we’re moving to the cloud with a lot of new development and some of the less mission-critical applications but the five apps that we run the bank on are gonna be running on mainframes five years from now.

That’s not changing. We can’t break them up into micro-services and they don’t lend themselves to refactoring. We’re gonna continue to just add, you know, additional workload front ends but for the most part, they’re gonna stay intact. And that just represents I think the reality in enterprises.

Shimel: And that is dead on the reality. And I just want to make sure we’re talking about tools like Xebia actually give these organizations the ability to use one platform across these multiple infrastructures.

Langone: Yeah, I mean, look, I don’t want to just plug our platform because there’s others out there, there’s others out there, but at the end of the day, yes, what we’ve tried to do is basically build the technology that can accommodate the mission-critical requirements of a large enterprise. So, not only have we baked in the ability to deploy any technology from any starting point to any destination including public cloud, private cloud, hybrid, containers, you name it, right?

We’ve also baked in all of the things that enterprises need to account for, like the compliance steps, the security steps, the who did what and when to the software reporting, so that all of these standards are met if you’re migrating to infrastructure that’s off of your own premises.

None of those business requirements go away. In fact, in most cases, they get a little bit more stringent as the security team start to understand that if you’re gonna move applications outside of the firewall of the organization, then we need to put even more validation steps and security procedures in place.

And again, if you’re doing this manually with engineers, they need to script for all of that activity and maintain it every time there’s a slight change in the application.

It just becomes 50 percent of an engineer’s day managing these scripts that were built to move applications around when they could be using that 50 percent of their day to do things that are much, much more interesting for them and much more valuable to the organization.

Shimel: Sure, I mean, and again, we’re not tooting Xebia’s horn here but you know what, Derek, from a manager-executive point of view maybe listening to this, knowing that there are tools like that that will allow them to go across these different infrastructures, single platform, is important. I mean, that was always one of the big inhibitors.

Langone: No, you’re absolutely right, and look, what we’re tried to build into our platform is this templated approach. We have a model-based architecture, it’s agentless so you create templates and every single application that you have to move from development to production follows one of maybe three or four templates.

And we’re talking 3 to 4 templates account for 500 different applications, whereas the alternative is you’re basically hand-scripting 500 different paths to production. So it’s much easier to maintain, it’s centralized, it’s controlled, there’s reporting, there’s visibility, there’s sort of all the things that you need to be able to score your process for migrating applications, whether it be to the cloud, the containers, or just frankly, to an existing data center.

So, that’s really an important consideration. The other piece to consider, and again, a place where we’ve put a lot focus in our platform is leveraging what you’re doing already. So, we are a part of the process but you’ve got provisioning tools, like Puppet and Chef, you’ve got service ticketing, like Service Now or Gira, Jenkins on the CI side.

A lot of technologies are required to move applications from one destination to the next, so we integrate with all that infrastructure that’s already running right out of the box, and we basically allow you to pick best-of-breed components so that you’re not locked into one specific vendor. And that’s been a lot of the feedback that we get from our particularly big financial services customers.

They like the fact that if they want to switch cloud providers on the fly and move from Amazon to Rat Space or from Rat Space to Azure, they can do that with changing one configuration file in our product rather than having to rescript everything from scratch to reach a new destination.

So, it really comes down to you avoid vendor lock-in, but when you want to make a pivot, that pivot in our technology and our platform takes five minutes versus months of scripting.

Shimel: Months, exactly. So, Derek, let’s make our own pivot, let’s talk about the other 50 percent of companies that aren’t moving major infrastructure to the cloud, or big parts of their infrastructure to the cloud. Let’s first of all say should they? Should they feel they’re getting left behind? Is it fatal to their business? What’s your feeling?

Langone: You know, I think every IT organization makes choices that line up to the business objectives of their firm. I wouldn’t say that the shift to cloud is mandatory. There’s certainly a strong value proposition associated with it. It’s very, very expensive to keep technology infrastructure fresh. That’s always been the issue.

You could build the data center but then, you know, 18 months later, all the technology in there is sort of out of rev, right? So you’re forced to buy it over and over and over again versus the cloud providers. You’re certainly paying the rental fee and that rental fee can be steep but you’ve always got state-of-the-art infrastructure to work against, and that’s just a very compelling argument.

The other pieces, the administrative element goes away so there’s less people required to maintain it because it’s getting maintained for you. But the majority of our customers are moving to the cloud but for specific reasons and with specific applications, right? They’re not just wholesale-lifting their entire application portfolio to the cloud because it’s just not practical.

So in the cases of customers that are still on premise, and that’s still the majority of large enterprises, I am not at all a cloud-denier. People are moving there and moving there aggressively, but when you look at large enterprises, I think your number was 50 percent are using and 50 percent are not.

My on the ground sort of feeling is it’s less than 50 percent that are aggressively using the cloud for many different reasons, not the least of which are just security concern that still sort of haunt these large organizations. But the fact is anywhere your applications reside, right now DevOps is a good investment.

Being able to increase the velocity at which you can build technology and deliver value through software to your end users is sort of a fundamental requirement nowadays in order to stay competitive in your own given space.

So, we help with velocity, like I said earlier, on mainframes distributed technology, legacy systems, building a repeatable standardized release and deployment process with all the reporting that you’d expect to be able to identify where you’ve got areas of friction that can be remedied.

So, we sort of approach with the same – our approach is the exact same whether it’s a legacy application or a nimble application that’s being written in containers to run in cloud infrastructure.
The templates are the same, the mechanics of how you release and deploy those applications is the exact same.

So, the beauty of our platform becomes anybody can use it, it’s understood, it’s centrally managed and it scales infinitely versus writing code which just is difficult and impossible to maintain over time.

Shimel: Sure. So, Derek, you brought an interesting point up though and it was one that I wanted to hit on. And that is, look, for those who are just moving to cloud, right, there’s a choice to be made. Do I take my inherited legacy, not so much infrastructure as much as my legacy stack and just port this existing stuff to the cloud?

Or do I really just bite the bullet in Greenfield, right? Like, my stuff hasn’t been built on containers, maybe it wasn’t even built on hypervisors and virtualizations – who knows? But you know what, if I’m gonna move to the cloud, the heck with it, I might as well containerize and take advantage of micro-services and all of this.

But my goodness, that’s such a major, you know, throwing out babies with bathwater potential. What’s your advice to companies faced with do I just port my existing architecture, or do I go for broke in more ways than one and adopt the new stuff?

Langone: Yeah, I’ll tell you, in my experience, and I wouldn’t want to give advice ’cause every company sort of has to line up against their business objectives. But what I will tell you, what we see most often is people threading the needle, right? Basically taking these monolithic applications and starting to build components of those applications in containers on sort of more nimble infrastructure.

You know, a good example, as I mentioned earlier, a money transfer app, right? That’s a legacy application that’s been running in a big bank for 25 years. The horsepower on the back end that does all the computations is still a couple of IBM mainframes strung together. But you’ve got referential databases that are living in distributed architecture maybe onsite, maybe offsite in the cloud somewhere.

You’ve got containerized and mobile-centric front ends so you could do your mobile banking, web banking, things like that. So, that application lives in a lot of different places and you can, with some small investment in more nimble development platforms and infrastructure on the front end, really energize and give life to these legacy applications.

So, there isn’t a need to move the entire thing to the cloud. You can move components of it to the cloud, but again, when you do that, you get the benefit of the faster architecture and the ability to deliver value through your software more frequently for your end users.

But the consequences, getting those components to the cloud becomes really complex and that’s where our technology really lends a hand, where we understand those complexities, we’ve accounted for them already.

We do this sort of every day for the biggest banks in the world so you can take advantage of not having to reinvent the wheel and still get the benefit of the velocity that you’re looking for and the flexibility you’re looking for in these applications that need to live on.

Shimel: You know what, Derek, that was one of the best examples of hybrid cloud that I’ve heard. I think for too many people they think of hybrid cloud, they say, well, this application lives in the cloud, this application lives on my mainframe, this application lives in a data-center, my payroll system is here, my HR system is there, but that’s not really hybrid cloud.

Hybrid cloud is we have one application that different elements and components of it live in this hybrid world, right?

Langone: Yes, I think there’s a misunderstanding that you’re either in the cloud or you’re not, right? The fact is, I think, that in most cases, most of our clients, you’ve sort of got one leg in both places.

Shimel: Yeah, at the same time.

Langone: You’ve got I’m somewhat in the cloud, and they make decisions relative to where can I get the biggest bang for my buck? Some of this application needs to be in the cloud for a bunch of reasons so let’s do it, and then we’re just not gonna forklift up our mainframe apps and dump them on AWS. It’s a cost-ineffective strategy; we’d have to refactor them like crazy.

So, yeah, and I don’t think that trend is gonna change, right? There’s certainly a bunch of Greenfield development that’s going on, containerized apps micro-services, just cloud-centric development. And that’s great but that represents generally less than ten percent of the application portfolio in a large organization.

And that’s the fact is that 90 percent of the apps have been around for five years or longer, and those apps are critical to the business.
And they, over time, will migrate to the cloud and be refactored and rewritten.

But it’s just too big of an endeavor for any large company to take a 1000-application portfolio and say, hey, this year we’re going to rewrite all these for the cloud. I mean, I don’t know anybody that’s doing that.

Shimel: I would hope not. Hey, Derek, I think I told you before we started, time goes really quick here. We’re at maybe 25 minutes now, we were supposed to be 15, so we could probably talk about this all day, but we’ll continue the conversation on our next visit with you.

But, hey, this was great, Derek Langone, CEO, Xebia Labs. Thanks for being our guest on DevOps Chat today and we hope to have you back real soon here.

Langone: Thanks, Alan, talk to you soon.

Shimel: All right, this is Alan Shimel for devopsy.kinsta.cloud, we’ll see you soon on another DevOps Chat.

— Alan Shimel

April 17, 2018
Devops Chat: Interop China Features DevOps and DevSecOps Tracks

Interop China has been growing steadily since its inception in 2013. It is part of the Cloud Connect conference in Shanghai. This year the conference will feature both DevOps and DevSecOps tracks and talks. Jayne Groll of the DevOps Institute is the DevOps track chair and Alan Shimel of devopsy.kinsta.cloud and Security Boulevard is speaking at DevSecOps.com. We sat down with Molly Huang and Kelly Yao of UBM China to discuss this year’s event.

Molly and Kelly give us a little of the history of Interop & Cloud Connect China, as well as a behind-the-scenes look at what goes into selecting tracks and putting on a major event such as this. It is also a great look into the tech scene in China.

As usual, the streaming audio of our conversation is below followed by the transcript of our conversation.

Audio

Transcript

Alan Shimel: Hey, everyone. This is Alan Shimel.

Jayne Groll: And this is Jayne Groll.

Shimel: And you’re listening to a combined podcast tonight of DevOps Chat, along with Continuous Chit Chat, which is, of course, the podcast from The DevOps Institute and the Community of Continuous Learning.

Jayne, welcome!

Groll: Hi, Alan, how are you? I don’t think we’ve done a podcast together in a little bit, huh?

Shimel: Well, we—[Laughter] that’s what happens when you travel around the world.

Groll: [Laughter]

Shimel: And I’m traveling as well, but we have certainly been on opposite ends of the world, and that’s actually a great lead-in to tonight’s show, Jayne, where we talk about traveling around the world, because we’re happy and lucky to have two of our colleagues coming to us from China today. We have Kelly Yao, who’s a Project Manager at UBM in China, and Molly Wong, who works with UBM for Interop China, and it was a Cloud event, wasn’t it?

Kelly, Molly—welcome to our podcast.

Molly Wong: Hi! Hello, Jayne. Hello, Alan.

Kelly Yao: Hi, Jayne and Alan.

Shimel: Thank you.

Wong: It’s really nice to help out.

Shimel: Ladies, thank you. Molly, besides Interop China, what was the Cloud event you mentioned?

Wong: Okay. So, the whole name of our event is Interop and Cloud Connect China.

Shimel: Ah, I got it.

Groll: So, it’s one event?

Shimel: Yes, so—

Groll: It’s one single event.

Shimel: Got it.

Wong: Yeah, it’s one single event.

Shimel: Interop and Cloud Event China. Very good. Now, Molly, if you don’t mind me asking you, many people in our audience, I’m sure, are familiar with the Interop name. It’s been one of the top IT shows here in the United States for 20 plus years. But they may not be familiar that China has an Interop event. How long has Interop China been held? How many years?

Wong: So, as we all know, Interop is an international event focused on information technologies and the ecosystems of the cloud community. But when it was first introduced to China in 2013, however, only the deliberation of cloud computing was capped, because at that time, Chinese companies were just at the same point switching from hardware to cloud services for cost reduction.

So, that’s why, initially, the Interop China event is not called Interop, it was called Cloud Connect China.

Shimel: Ah, interesting!

Groll: And I was gonna ask, and it kind of makes some sense, if you think of Interop as an international event, which is really about operations, and Cloud Connect certainly is about operations. So, it sounds like, Molly, that the approach here was really to produce an event that spoke to not only cloud from an operational perspective, but also just IT operations in general. Is that correct?

Wong: Yes, because, you know, UBM, by its nature, is an event organizer. So, we have to keep up with the global trends and add different burning topics into the conference every year so as to make the event more compelling.

Shimel: Absolutely.

Wong: So, this year—and Alan, if you don’t mind, let me ask a little bit about DevOps. Because, as you know, I’m gonna be the track chair for the DevOps track. So, tell us why you decided to add a DevOps track to Interop, and even including DevSecOps, which is a security—obviously, DevOps and Security.

So, what are you hoping to come out of the DevOps track?

Wong: You are asking me, or Kelly?

Groll: Either one. We haven’t heard from Kelly, so maybe Kelly wants to answer.

Wong: Okay, I will answer that for Kelly, because I’m mainly responsible for the content.

Groll: Okay.

Wong: So, I think nowadays, the technological benefits of DevOps is very obvious, and organizations that successfully implement DevOps, implement DevOps tools and practices in general, they tend to be ahead of their competitors across key metrics like profitability and growth. So, that’s why the Chinese DevOps communities are growing so fast, as a lot of professionals are flocking into the DevOps ________ and to learn and adapt.

So, from our part, we think we would love to contribute to build up a platform for these lovers and learners to communicate, to collaborate, and to excel.

Shimel: Excellent. Jayne—so, Molly, if you don’t mind, I’d like to hear from Kelly a little bit. Kelly, in your role of Program Manager, how are you sourcing content? Where is the content for the DevOps and the DevSecOps and so forth? Is it internal to the Chinese community? Are you bringing in also people from around the international DevOps community? You know, I imagine it must be quite a job putting this all together.

Kelly Yao: Yes, yes. Exactly. Like, for us, it’s just a platform. We are an event organizer. So, we are not professionals who are familiar with this content. So, what we do is, we will have a—what is it? Like—

Wong: An advisory board.

Kelly Yao: – yeah, advisory board. So, we will have the board meeting like twice a year to put up all the content. So, this year, we decided to put this DevOps tracks, and so, it will benefit our event, it will benefit the whole content for this event. So, that’s when, but you recommended it to us—you and Jayne recommended it to us by Interop ITX, because it’s like—yeah. We’re like partners, so both Interop ITX and Interop China, we’re working together to deliver the content.

And so, when we decided to make the DevOps tracks and then that we reached out to you at devopsy.kinsta.cloud and also for Jayne—

Wong: Yes, for Jayne at the DevOps Institute.

Kelly Yao: – yeah, DevOps Institute. And, of course, you are the expertise that—you are the experts, that you will know how to make the content right and how to recruit speakers for, the most suitable speakers for this content, for this topic.

Shimel: Understood. Fantastic. And ladies, how has—you know, from what we understand, and of course, we’re on the other side of the world, but it’s a small world in today’s Internet, right? We’re all connected.

Wong: Uh huh, yeah.

Shimel: We know that the DevOps community in China is, as you said, Molly, is growing very fast. It’s already very large, and I’m wondering, what kind of have you gotten from the community about adding the DevOps tracks? Has it been a positive reaction?

Wong: I think everybody here are fully aware of the benefits of DevOps. But, you know, the challenges of actual adoption remain huge. Because, you know, for the DevOps design for the architecture, it’s all about the tradeoffs. The development of DevOps in China now stands between the early and middle age, because, for the DevOps professionals, they need to consider what they deem as the most important thing and what are they willing to sacrifice or give up for and, really, how to lower the costs when running in a public cloud.

So, I think there are a lot of concerns. There is a need to figure out the full implementation.

Shimel: Understood. And, you know, Molly, just—Interop ITX in Las Vegas is a large show, thousands and thousands of people. How big is Interop China? How many attendees do you expect?

Wong: I think the estimated number would be around 3,000.

Shimel: That’s a big, that’s a—

Wong: Yeah. Each year, like—

Groll: It’s a nice sized continent, you know?

Wong: – around 3,000 people are coming to—yes, 3,000.

Shimel: Very interesting. And, you know, DevOps is great, but give our listeners a sense—what are some of the other tracks about, besides DevOps?

Wong: Besides DevOps, this year, we also have AI—

Kelly Yao: Artificial intelligence—

Wong: – big data—

Kelly Yao: – big data, and data mining.

Wong: Yeah.

Kelly Yao: Yeah, as well as information security.

Wong: Information security, yes.

Shimel: Mm-hmm. So, I have to tell you ladies that listening to both of you talk about the challenges of DevOps and what other areas are of interest to the crowd, you know, to the community in China, it really is a very small world. Because these are the same issues, the same topics that we see here in the United States, it’s the same thing that we see in London and in the rest of Europe. Jayne, you can talk, you were just at a few conferences in Europe.

There are some things that just seem to be universal in today’s technology scene, and everyone is excited about artificial intelligence and machine learning. Cyber security information or InfoSec is top of mind; every day, we seem to hear of more breaches and hacking. And, of course, DevOps is very exciting.

Jayne, as Molly said, you are the DevOps chair for Interop China. I mean, that’s very exciting. Give us a little idea of what you’ve done in your role there.

Groll: So, I’m also the DevOps Track Chair for Interop ITX U.S. So, it’s been very fascinating working with both teams, because, you know, Alan, as you said, the challenges, the successes, the emerging practices in DevOps in particular are very, very universal. And some are starting to emerge differently. Some are, for example, to start, reliability engineering in the U.S. is starting to gain some momentum. I’m not sure, specifically, around the world, but I do know in Asia-PAC ________, there’s conferences like that as well. So, that’s an emerging practice.

Looking at continuous delivery and how it relates to operations is a theme that’s carrying through from both conferences. So, I’m particularly excited about really visiting with the Chinese community, as you know, DevOps Institute is a very, very global organization, and really having some face to face time, bringing content, bringing learning to Interop China and the Cloud Connect.

The other thing we’re gonna do at this event is, we’re gonna do some DevOps training. So, working with one of our Chinese partners, we’re going to do a half-day Essential DevOps workshop. So, for those that are not even so much, “What is DevOps?” but really, a visit to, “What are these practices?” like continuous integration, continuous delivery. I mentioned site reliability engineering. So, in addition to a traditional conference program, we’re going to also bring a half-day workshop to Interop China and Cloud Connect. So, I’m really very, very excited about that in particular. And we will have one of our Chinese colleagues, one of our Chinese partners deliver it so that it can be localized, and he’ll bring not only being able to deliver it in a native Chinese language, but also bring some very, very good local examples and case studies to the training as well.

Shimel: Excellent, excellent. You know what? We didn’t really get the details that, Kelly and Molly, if you can share with us, what are the dates for Interop China?

Wong: Yeah, it will kick off on May the 9th to 11th this year.

Shimel: Okay, and it’s in Shanghai.

Groll: In Shanghai—in Shanghai.

Shimel: Yes, it is, it’s in Shanghai.

Wong: Yeah, in Shanghai.

Shimel: And for people who may be listening to our podcast who are in the area or maybe would like to attend, where can they go on the web to get information about that?

Wong: Yeah, sure. They can register online through our official web portal, cloudconnectevent.com.

Shimel: Cloudconnectevent.com—excellent.

Wong: Yes.

Shimel: And that is for Interop China. So, this—if I’m understanding, this is the fifth year for the event.

Wong: Actually, it’s the sixth year, yeah.

Shimel: Sixth year—yes. So, Molly and Kelly, how many years have you been involved with the event?

Wong: Yeah, actually, we two are—we’re jumping into this platform, this event from last year, 2017.

Shimel: And so, from ’17 to ’18, do you see a big change?

Wong: Yes. I think the market is changing itself. Like, most of our exhibitors, sponsors, most of the cloud enterprises, they’re changing themselves and also their knowledge, their application on the technology. So, it’s changing themselves, and also ________, it’s like, we’re also changing our content to adapt to the market.

Shimel: Like any good event organizer should, correct? You’ve got to adapt to what the market is there.

Wong: Yes.

Shimel: Well, I have to tell you that I am personally very excited to be coming to Shanghai and delivering a presentation on DevSecOps and why security, it’s vital that security become part of the DevOps equation, we’ll talk more about it. And to be there with Jayne and Jayne will be delivering as well, as well as some DevOps Institute training. It promises to be a great event for the Chinese DevOps community as well.

Molly and Kelly, I want to thank you for joining us. We’re just about out of time, unfortunately. But—

Wong: Okay.

Shimel: – this was great. We’re looking forward to coming out to Shanghai in May, and we’re hoping that this will be a tremendous event, and we hope to see you there soon. Thanks very much for joining us tonight.

Groll: Really enjoyed it.

Wong: Thank you, Alan and Jayne.

Shimel: Thank you.

Groll: And maybe we could do a podcast from the event.

Shimel: That would be great!

Groll: So, let’s—you know, [Cross talk] maybe we can do a live podcast from the event.

Wong: Yeah, yeah. We’re really excited to see those in the event.

Shimel: Fantastic.

Wong: And I’m also looking forward to—yeah, looking forward to the podcast if we can have, on site, the Interop China.

Shimel: That would be fantastic. Jayne, I’m gonna give you the last word tonight.

Groll: [Laughter] Well, thank you. Molly, Kelly—it’s a pleasure to work with you. For those that are listening, if you do have the ability to attend, it really does promise to be not only a fantastic event, but an event where there’s lots of opportunities to learn and really track some of the emerging trends not only in DevOps, but particularly on the operational space. So, if you’re going to be in Shanghai, we all look forward to meeting with you. Molly, Kelly—see you in a few weeks. Alan, see you in a few weeks. And for everyone, thanks for listening.

Shimel: You’ve just listened to a Continuous Chit Chat and DevOps Chat. Have a great day, everyone! Bye bye.

— Alan Shimel

April 16, 2018
DevOps Chats: Jim Gochee, Chief Product Officer, New Relic

In this DevOps Chat we speak with Jim Gochee, Chief Product Officer, New Relic. In his role at New Relic, Jim has seen years and years of evolution in digital transformations. Jim and I spoke about a number of topics including about how to succeed with DevOps, the rise of SRE and APM. Great discussion all around.

As usual, the streaming audio of our conversation is below, the transcript follows that. Enjoy.

Audio

Transcript

[su_pullquote align=”right”][su_custom_gallery source=”media: 122025″ link=”post” target=”blank” width=”200″ height=”200″ title=”never”]Jim Gochee
Jim is New Relic’s Chief Product Officer, overseeing the teams that design, build, and deliver New Relic’s products. He has a passion for building world-class products and loves technology – especially when it’s well architected, scalable, and fast. He takes great pleasure in helping New Relic’s customers analyze their technology and build great digital experiences. Prior to New Relic, Jim was the Chief Architect for the Wily Technology division of CA, where he was the technical lead for Introscope, an industry-leading web application performance monitoring solution. Prior to that, he was Chief Technology Officer for an internet-based trading system for the wholesale food industry. Jim also spent four years at Apple, Inc. and three years at Connectix Corporation working on VirtualPC. He holds an A.B. in Computer Science from Dartmouth College.[/su_pullquote]Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud and you’re listening to another DevOps chat. Today’s DevOps chat features Jim Goci of New Relic. Jim, welcome to DevOps chat

Jim Gochee: Hey, Alan, how are you? It’s good to be here.

Shimel: Thank you, it’s good to have you here. So, Jim, let’s get some stuff out of the way here, a little housekeeping. What exactly is your role at new relic?

Gochee: Yeah, Alan, so I oversee all of product development and that includes engineering, product management, design as well as operations. So pretty much the whole shooting match.

Shimel: Fantastic. And Jim, I was talking to you off-mic before we started today, we haven’t done a good job frankly of covering New Relic at devopsy.kinsta.cloud but when we first launched, which is going on five years ago, New Relic was already a well-established player in the DevOps market and is certainly even more established now.

But why don’t you give our audience maybe just a quick little history to bring us up to where New Relic is today.

Gochee: Yeah, absolutely. We’ve been around actually for ten years, Alan. So we just had our tenth-year anniversary party just a couple of weeks ago if you can believe that. So, 2008, and when we started, we were focused on Ribyon Rails, monitoring the backend services, grew the product portfolio over time to include other languages.

But mostly sold to small companies, startups, companies that got bigger like Air B&B. But really, it was a couple years ago we started to pivot more into the enterprise and that was a very exciting time for us.

We were already getting pulled into bigger and bigger companies at a project level and then we found ourselves being kind of drawn in organically to more and more groups to the point where these big companies were wanting to have more of a formal relationship with us, from a sales perspective.

So we built out an enterprise sales team and have been really focused there. So maybe, in one way, while you haven’t seen a lot of us in the last couple of years as we’ve been pretty heads down, focusing on the needs of the enterprise market. But what I’ll also say is we’ve been releasing a lot of product as well in the last a couple of years and the biggest thing that we did is we rounded out our offering to include an infrastructure monitoring component.

And that really complicates, not complicates, but it complements our offering at the application layer as well as the end user layer. So at this point, we have a pretty comprehensive portfolio of offerings that cover that full stack.

Shimel: Very cool, very cool indeed. So Jim, I would imagine in your role around product and everything you’re doing at New Relic, you get to talk to more than a few customers, yeah?

Gochee: Well, I do and I just feel so blessed, Alan, because this is an incredible time to be in technology. So I’ve seen a few really interesting times in tech. I think the first was when the Internet really started to get mainstream, back in the mid-’90s, but what’s really interesting now is this thing that you hear a lot about which is digital transformation.

And we all feel it, which is we want a relationship with the companies that we do business with, we want a relationship via our mobile phones or the web browser. And so a lot of companies are trying to figure out how do they have that new customer relationship, right? And how do they come up with new ways of engaging with their customer?

And then, of course, again, companies like Air B&B completely rethinking business models, companies like Uber, and so it’s just a really fascinating time to be in the tooling space that supports and assists a lot of these digital transformations that are going on. So, yeah, we definitely see a lot of interesting things.

Shimel: Excellent. So, Jim, one of the themes that we have run into here recently at devopsy.kinsta.cloud is this idea that somehow people thought digital transformation and DevOps transformation was gonna be easy. And they’re a little bit taken aback.

You know, you speak to them, the first kind of foray into it it’s like, you know, this is hard. And I feel like saying no one promised you a rose garden, right? If it was that easy everyone would be doing it already. Are you seeing any of that?

Gochee: Well, you know, Alan, in fact, we do see a lot of that but I would say is this, I guess I see the full continuum. I see the early adopters and the enterprise to DevOps. I mean, DevOps, you guys have been around for five years and we’ve been doing it for 10 and it’s early to do when you start a company that way.

In other words, when you start a company and you have a DevOps organization already, it’s easy to grow and keep doing that. But when you’re a traditional enterprise and your operations team is very siloed from your development teams, to bring those two together is a pretty big task, right? And you hear a lot about the cultural challenge involved, and that’s very real.

The thing I’d like to ask, the question I ask when I go into one of our customers and I’m not familiar yet with really where they’re at in the journey, I ask them one simple question. Who takes pager call? And if it’s still the operations team that’s taking pager call, then normally they’re still complaining that the developers don’t care, the developers are very isolated, and you see those silos still in place.

And it’s really not until a development team, then with the help of operations, people like SREs embedded on that team, it’s really not until that happens where I would really see the crossing of the chasm into more of a true DevOps model.

Shimel: Absolutely. You know, you mentioned SREs, Jim, and that’s another area where we’re just seeing it, man, it’s blowing up, right, in terms of companies hiring SREs, incorporating SREs on to their ops team. Many people have gone as far to say SRE puts the ops in DevOps. What are your feelings around the SREs and that?

Gochee: Well, what I like about the SRE role is Google wrote a book about what they believe it is. And so while that probably just applies to Google and nothing’s ever as perfect as it seems, they clearly define these are the things that this role does.

And this is why these things are important, and it’s a real philosophy and it’s a real mindset, and they wrote it down and these are all things that other people had been doing in various ways. But I think the SRE role, it got really clarified what exactly it is.

And so I am starting to see this more and more as well, and it’s not like SRE is a new concept; again, Google’s been doing it for a very, very a long time but I just feel like it’s kind of catching on.

I can tell you ourselves we’ve been doing DevOps for a long time but just in the last year, we’ve really formalized around SREs as well and we got a vice president of site reliability engineering, we converted people’s titles over, we got really crisp about exactly what are you doing.

We’re trying to figure out right now whether central versus embedded or a hybrid of the two approaches, so you know, how to organize SREs and how do they really attach into development teams? There’s still plenty of work to do even that we’re looking at, but I think this is helping the industry really figure out a model that they can work with.

Because that’s the biggest thing I see, Alan, is people want to transform to be more agile into DevOps and to use the Cloud, but they don’t really know how to do it, right? They don’t really have a good playbook for it yet.

Shimel: I agree with you 100 percent. It’s interesting you guys are eating your own dog food with that.

So, Jim, in many ways, New Relic, sort of, if you will, pioneered what we call APM, you know, and we recently did—it got too big but it was a DevOps tools primer, just trying to at least draw it so that the taxonomy of categories—and certainly APM, but APM itself has become so intertangled in this whole software development life cycle. Is that still where New Relics thinks they play?

Gochee: Yeah, so it’s a great question. We like to say that we’ve democratized APM; in that, we created a service that anybody could subscribe to, download our agent, install it into an application code, relaunch your application and now you’ve got your data showing up on our screens.

The technology around APM, though, has been around a lot longer but we were the first to bring it to everybody in a very transparent selling model, right, and again try it before you buy it. And we have by far, in a way, the most users in this APM category. These categories are funny things though, yeah, applications here but there’s also end user, there’s synthetics, now there’s infrastructure tier.

It’s all kind of collapsing and probably the markets sort of get renamed after a while. One of the things that we like to say that we think we have is a digital intelligence platform, digital intelligence just means data about everything that’s part of your digital system, all the code running, all the infrastructure that’s running.

And so at the end of the day, if you want to be agile and deploy a lot code and make a lot production change, you need to have data that tells you that things are still working correctly about all the different pieces of your infrastructure, right?

And without that data, you’re flying blind and so, flying blind, it’s okay if you deploy code once every six months, you can fly blind for a little bit while you sort out any issues. But if you’re deploying code every day, you’ve got to have real-time data about what’s happening in order for that to be successful.

Shimel: Sure do, sure do. And Jim, when we talk about the move to the enterprise, I think that’s one of—not that startups or non-enterprise customers don’t use data or that they do fly blind. They don’t. That’s not the case at all. But when you go to the enterprise and you start thinking about enterprise-class functionality, right, is when you start realizing what—really, things have got to be locked down, right?

There’s got to be sort of—I mean, sometimes it can be overprocessed and overcomplicated but you can’t just fly by the seat of your pants as much. And I think products like New Relic, they can’t help but bring some of that regimentation to a company.

Gochee: Absolutely, no, I mean your point’s really well-taken. When you’re a smaller company, you can take more risk, you don’t have to do things the right way, you know. That’s common. When you’re bigger company, you have a lot more experienced people who are used to having better tooling, better processes, better governance, right?

Because there’s a lot at stake. I mean, these are some of the largest companies in the world who are betting their future on their digital projects, and those projects have to function and they have to work. So, I don’t know, can I tell you one story, Alan?

Shimel: Sure.

Gochee: It’s a few years old now but do you remember when healthcare.gov first launched?

Shimel: Yes, I do.

Gochee: It first launched and the thing didn’t really work. It was hung and broken and the president was like apologizing to the nation, right? This is an example of we looked at each other and we’re like this is the highest-profile example of a web project gone awry.

Shimel: [Laughs]

Gochee: Yeah, right, I mean the president has to apologize for poor web performance and –

Shimel: At least we had a president who apologized then, but go ahead.

Gochee: That’s another story altogether.

Shimel: That’s a whole other story.

Gochee: The president brought in a team from Silicon Valley to help fix that site. I forget Mikey’s last name from Google. Anyways, they brought New Relic in and then we gave them the data to help sort that out, and then from now on, we have been the tool of record for how that system has been performing. And they’re just 1 of 15,000 customers that we have.

Shimel: Interesting. But that’s a classic example of it, too. That was done probably, frankly, without the necessary requirements in laying it all out there. Jim, let me ask you a question. From your catbird seat, what do you see at the future of the market here?

Gochee: Yeah, so just in terms of digital transformation and digital customer experience, that’s absolutely gonna be powering the whole economy and tech sector in particular for the next five to ten years. Cloud, the move to Cloud, the opportunities you can get by some of the Cloud services.

In particular, Amazon is really blazing the trail in just the sheer number of services they offer the market, changing how people can build and deploy software, it’s incredible. So we see a continued explosion in software and digital experiences, and then that drives companies like us, we offer tooling in this area that really helps companies move more quickly, have a better customer experience. And so I mean, I think the whole category of tech and DevOps and Agile and tooling, observability is a trend, SREs, all of this is gonna continue to have a lot of strength and a lot growing over the next five or ten years. I just absolutely believe that.

Shimel: Excellent, Jim, as I mentioned to you, when we first got started here, 15 minutes goes really quick. I think we’re probably closer to 20 at this point but it’s okay. Maybe we can have you back on here at New Relic and a DevOps chat because we would like to stay on board with everything that’s going on there. But in the meantime, thanks for being a guest on this episode of DevOps chat, Jim.

Gochee: Alan, it’s been enjoyable, thank you so much for having me. I’m happy to come back on as well

Shimel: Absolutely, we’ll make you a regular. Hey, that was Jim Gochee, Jim runs products and a bunch of other things over at New Relic and this was another episode of DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud. I hope to see you soon on another chat soon, everyone. Take care.

— Alan Shimel

April 9, 2018
DevOps Chat: The State of Alerting & On-Call Survival for IT Ops, with OnPage CEO Judit Sharon

In this DevOps Chat we sit down with Judit Sharon, CEO of OnPage. OnPage has been providing alerting and incident management services primarily to the healthcare industry since before DevOps was called DevOps. As DevOps has exploded on the scene, the security and functionality built into OnPage was a perfect fit for IT Ops and DevOps teams. As a result, OnPage has expanded beyond its healthcare industry roots to become a very popular solution in the DevOps space.

OnPage recently conducted a survey on the state of alerting in the IT Ops space. Judit gives us some insight into the findings, but you can download the full survey report at www.onpage.com/the-state-of-it-operations-ebook/.

As usual, the streaming audio of our conversation is below, followed by the transcript of our chat. Enjoy!

Alan Shimel: Hey, everyone, it’s Alan Shimel, and you’re listening to another episode of DevOps Chat. Today’s DevOps Chat is a really nice one that I think you’re going to enjoy. I have as my guest Judit Sharon, CEO and co-founder of OnPage. Judit, welcome to DevOps Chat.

Judit Sharon: Thank you, Alan. Happy to join you.

Shimel: Happy to have you here. So, Judit, let’s start off a little bit, as I mentioned, you were the founder and CEO of OnPage, but maybe some folks in our audience are not familiar with OnPage. Why don’t you give us a little bit of background on the company and how you came to start it?

Sharon: Sure. So, OnPage is a SaaS based incident management platform hosted in a secure facility across the U.S., and in a nutshell, we—OnPage gives you visibility and feedback on incident status. You can track alerts, delivery, ticket status, and response, and it’s rock solid reliable. As one of our customers once said, it’s a must solution for those who need to elevate critical incidents.

Shimel: Mm-hmm.

Sharon: So, if I just go a little bit deeper, OnPage was built around the incident resolution life cycle to enable an organization to get the most out of their digital investment, ensuring that sensor and monitoring system have a reliable means to escalate urgent notification to the right person and immediately.

So, you know, Alan, just a few years ago, when we wanted to come up with a product, all we needed to do is plan the product, develop, test it, and deploy it. That’s it. That was the end of it. Today, in the DevOps era, we also collect data. We use a special tool to collect data, to remove the noise. We calculate the data, we learn normal behavior, we predict anomaly, and we even attempt to correct it if possible writing a little script.

So, we invest a lot in collecting this information, and as long as the process is working well, machine to machine communication is ideal. However, in the case of failure, disaster, or outage, when a technical person is needed, e-mail and SMS or even a phone call is not a sufficient means of notification, and OnPage is the best, most reliable solution to be used. And why? Because the technical person on call will get all the information right to their device, can start working on the incident immediately. If they’re not available, there are escalation rules that are pre-defined, and they can escalate it to the next person.

Furthermore, in the event that the person did receive it and now they need help from a different person, from a different team—so, they don’t need to know who is on call in that team, all they need to do, they can forward the entire ticket, add some notes to it, and send it to the different organization. OnPage will send it to the right person on call and will escalate it within the next team.

So, in one sentence, to summarize, OnPage automates the entire notification process to avoid human errors.

Shimel: Yep. And Judit, I want to call out another not feature but characteristic in the history of OnPage. You know, we see so many companies that saw DevOps as a gold rush. You know, founders who say, “Wow, I want to start a company around DevOps,” and they build a tool for DevOps.

Not the fact with OnPage. OnPage has actually been around for some time, and its mission dovetails nicely with DevOps but it’s not one of these Johnny-come-latelies trying to capitalize on how many people are searching Google for DevOps or something like that. Correct?

Sharon: Right. So, we started about seven years ago. We started as incident notification, and actually, we started in health care. That’s why our solution is HIPAA-secure, something that is very unique about us.

The other thing that we did, because we started in health care, was, we needed to alert until read. So, we are very unique in that, that we don’t just send you an alert, like send an SMS or an e-mail or send you just a push notification. We will alert consistently for eight hours to ensure that the message was delivered to the right person. And we have the audit trail, so now, accountability is a must. Now, we have the audit trail of who got it, when, how long it took to open the message.

And another very nice feature other than the fact that we are HIPAA-compliant, so you know, we are secure, all the communication is secure at rest, and it’s encrypted in our database. We also save all the information for up to six years. So, other than the fact that we are HIPAA-compliant and other than the fact that we have the alert until read—we have other very nice features. Right now, there are a lot of companies, large companies mainly, that have a lot of systems and processes and sensors that sense just e-mail notification. And you will see from our study that we will talk about later, a lot of people are using e-mail notification for incident notification. And we just integrated those e-mails, and basically, you can leverage all the OnPage capabilities and elevate those messages if they’re important.

Yeah, that’s what we do.

Shimel: Sure, absolutely. And Judit, I wanted to kind of shift the conversation, if we will—if you will—to a larger topic, and that is sort of the state left alerting in the IT Ops world and the state of IT Ops. I know recently OnPage conducted a survey of IT Ops professionals. There’s been a few articles on devopsy.kinsta.cloud about it by Aura Lee, love of your company as well as download the full report.

But for those of our listeners who maybe haven’t had a chance to go on the site and check out the report—and we’ll put links to it in our show notes—can you talk a little bit about that, give us a little insight, here?

Sharon: Yes. So, the state of IT operations, we conducted a study where we surveyed about 96 different companies, and the nice thing about that survey, we got a few people from each organization. So, we see the response from different levels of leadership. So, 20 percent were SVP or C level, 22 percent were directors, 34 percent were managers, and 24 percent were individual contributors. So, you see a nice distribution among the different levels in the organization.

And the findings were—I mean, first, what did we want to look at? We looked at how teams are notified in critical incidents, how many alerts the team received, who received the critical alerts, and how did they get handled?

So, the findings were really interesting. As I told you before, we found that 80 percent of the respondents said that they get notified via e-mail. You know, e-mail—the same e-mail that you get as junk mail, the same e-mail that you get on a regular basis—80 percent of IT get their notifications via e-mail. Which means they need to be on top of e-mail all the time. They’re always on, they’re never off. And I don’t know if you remember Target, they had some cybersecurity?

Shimel: Mm-hmm.

Sharon: Apparently they did get alerts, right? They did get notified, but they got notified via e-mail. So, three days later, they found the e-mail that they got notified. So, what OnPage says is, “Yes, you have processes that are sending e-mails. You can always change those processes and maybe extensively change the processes.” But why don’t you elevate those e-mails so they find you in case of emergency rather than you sit there and always, always check your e-mail?

Another interesting point that we found is that 40 percent of IT teams get more than 10 alerts per day; 20 percent get more than 20 alerts per day. So, couple that with the fact that two-thirds of the respondents saying that they sent alerts to the team—so now, you don’t send alerts to one person, every alert gets sent to the entire team because they don’t want to miss the alert, right? So, what OnPage does, they say, “Okay, you get a lot of alerts. Don’t send it to the entire team. Send it to an escalation team, so one person will get it, and then always change who is the first one in line so the burden gets distributed.” So, you don’t get as many alerts, and you don’t—like, basically, the workforce, right, and the quality of their life, you don’t diminish it completely.

So, that was just a few very, very interesting facts that we found about that demographic that we surveyed.

Shimel: Yep. You know, Judit, I’d like to make a comment, but more of a question to you and get your advice, because this is an issue we deal with here at devopsy.kinsta.cloud, even. We have tried so hard to move off of e-mail as our primary communication, alerting, operational format. And we have tried. We’ve tried things like Slack and Chat and Google Chat and texting and I can’t tell you how many different tools we’ve given a try to. And yet, we keep coming back to e-mail.

So, it doesn’t surprise me that many Ops people still rely on e-mail, with all the spam and all the noise to signal ratio problems there. What do you—for people listening out here in the same boat I am in—what’s your suggestion? What’s your advice?

Sharon: Well, I think that e-mail is really good for audit trails, right? You want to know what happened, who said what. All the communication gets distributed to a distribution group—that’s fine.

What we say is, when it’s critical, right—e-mails are okay for day-to-day communication. E-mail is okay, it’s actually for events or incidents that don’t need to be taken care of right away. So, those events that don’t need to be prioritized, they should go to e-mail. That’s absolutely true.

What we say is, when there is an event that needs your attention immediately—and that’s another thing that I would like to go into are the costs, right? Those incidents that need to grab your attention immediately, those should be elevated. Those should find you rather than you always check your e-mail and always be on.

Another interesting thing that we’ve found is, 12 percent said they are still using a pager.

Shimel: Yeah?

Sharon: And then we looked into those 12 percent, what vertical they come from, and we found that they come from the healthcare industry. Come to show you that the IT follows the technology implemented in the organization; they don’t kind of bring new technology for themselves. So, if the health care organization is using a pager, the IT organization of the same organization will use pager. Only with those who responded. We have a lot of customers, health care IT, that are using OnPage to elevate those messages.

Another thing I want to get into is the cost, right? How much it costs. So, 99 percent of the organizations say that a single hour of down time costs them $100,000.00. So, every minute that we delay working on it and remedying the issue costs you about $1,670.00—every minute, right? You know, the counter is working, and we found that 62 percent of responders, it takes them 5 to 15 minutes to deliver an alert. Twelve percent said it’s more than 15 minutes to deliver an alert.

So, here we see that just the delivery costs of the down time is between 8,000 and 25,000 per incident. Now, compare that to the cost of the solution. The cost of the solution is almost like a no-brainer. When we started the company and we pitched the idea, it was a quote—it’s a no-brainer. The cost is so miniscule in comparison to the cost of the lost time in delivering the alert to the right person and having the audit trail and having the reporting so you can afterwards go and even audit your team, make sure that everyone is accountable, that everyone is reliable.

So, that was an interesting finding from this survey. Actually, we think it’s so interesting that we would like to run the survey in a different venue as well to try to get maybe a bigger audience, because this one was about 200 to 150 responders, but maybe if we can go on a larger scale and see if it’s working the same across all industries.

Shimel: Sure. That would be fascinating. And I think—you know, it’s funny, I happen to be working on an e-book we’re writing on the state of DevOps in 2017, and I will tell you, there’s frankly not enough research being done and that’s available on these kinds of subjects, right? I mean, people are going more on kinda what their gut tells them on subjective rather than objective data.

Sharon: Yeah.

Shimel: And that’s always—you know, sometimes it works, but it’s always risky. So, I would encourage you to do that if you guys can, for sure.

Sharon: Right. The other thing that we found that, you know, security became really, really important, like, this is top of mind for everyone. It used to be only health care, right, that cared about security and compliance, and now we go through one survey after another about our security policies from IT organizations, right? So, security becomes very, very important, and 40 percent of the responders said that encryption, even of alerts and messaging is very important for them. So, that’s another nice piece of information that we got from this survey.

Shimel: Absolutely. Well, Judit, as I mentioned to you off mic when we were talking before recording today, the time goes really quick here. We’re already—we’re well past 15 minutes, so we’ll try to be respectful of our audience’s time, and maybe we can have you on for another chat to continue the discussion, maybe if you continue another leg of the survey.

But thanks for being our guest on this DevOps Chat. I just wanted to end it, because I forgot to ask you in the beginning. For people who want to get more information about OnPage, where can they go?

Sharon: So, of course, there is our website, www.OnPage.com. If you want a copy of this survey, it’s located at devopsy.kinsta.cloud, and there is another location on our website, OnPage.com/DevOps-ebook. A little bit more complicated than devopsy.kinsta.cloud, but we are going to publish another part of this survey, because we put the white papers in two sections, so part two is going to come up soon.

Shimel: Great.

Sharon: And I would love you guys all coming to look into what we do.

Shimel: Okay! Judit Sharon, founder and CEO of OnPage, thank you for being our guest.

Sharon: Thank you, Alan. Pleasure to be here.

Shimel: Pleasure to have you here. Judit, we’ll see you soon.

Sharon: Sure.

Shimel: This is Alan Shimel for devopsy.kinsta.cloud. Thanks for joining us. Hope to see you soon on another DevOps Chat, and have a great day, everyone.

— Alan Shimel

March 21, 2018
DevOps Chat: Continuous Testing with Sandeep Johri, CEO, Tricentis

In this DevOps Chat we take a dive into the continuous testing market, which is one of the most dynamic in the DevOps space. Our guest is Sandeep Johri, CEO of Tricentis, a leader in the space.

Sandeep gives us his own personal background, as well as the history of Tricentis. The company is not an overnight sensation in the continuous testing space. In fact, it has been perfecting its offerings for many years. Tricentis literally helped usher in the continuous testing age, making continuous testing part of the CI/CD pipeline.

This chat is a great way to learn about what some of the important points for continuous testing are. Have a listen. As usual, the streaming audio is immediately below, followed by the transcript of our conversation to follow along. Enjoy.

Audio

Transcript

[su_pullquote align=”right”][su_custom_gallery source=”media: 120253″ link=”post” target=”blank” width=”230″ height=”230″ title=”never”]Sandeep Johri
As the CEO of Tricentis, Sandeep brings over 25 years of enterprise software experience. He manages all business-related functions including business strategy, products, services, sales, marketing, and operations to achieve business profit and sales objectives. Sandeep most recently served as the COO of Appcelerator, the leading open source mobile application development platform. He was Vice President of Strategy and Industry Solutions at HP, where he also served as Vice President of Corporate Development. There, he was instrumental in developing and implementing the growth strategy that resulted in the software business growing 2X market over the last four years. Sandeep was instrumental in the formation of two startups, Determina (VMware) and Bluelane (VMware). He was also the CEO and founder of Oblix (Oracle), and co-founded eBoodle (EW Scripps), one of the first ecommerce comparison shopping services. Sandeep has an MBA from Stanford University, a Master’s degree in Industrial Engineering from Wayne State University, Detroit, and a Bachelor’s degree in Mechanical Engineering from Pune University, India. Sandeep is involved as an advisor and investor in various startups in Silicon Valley and India.[/su_pullquote]Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Got a really great chat lined up for you all today. I’d like to introduce you to Sandeep Johri. He is CEO of Tricentis. Sandeep, welcome.

Sandeep Johri: Thank you, Alan.

Shimel: First of all, Sandeep, I just wanted to make sure I’ve got your – we pronounced your name correctly.

Johri: Yes, you did, actually. You got it absolutely right.

Shimel: Good. All right. It’s always a good start. So, Sandeep, let’s start foundational here. Tricentis is a company that, really, had a very, very strong presence over in EMEA, I think, and has most recently really begun to exert themselves in the North American market. But some of our listeners may not be familiar with Tricentis at all. So why don’t we start with that, if you can give us a sort of a – not an elevator pitch, but a little background on Tricentis?

Johri: Sure. So Tricentis was founded about eight, nine years ago. It was founded by Wolfgang Platz, who was actually a tester and working on complex enterprise applications for testing and was frustrated with all the tools out there. So, like any good entrepreneur, he decided to write his own tool. And the tool initially was focused primarily on automation. And it sold – they were – Wolfgang was based out of Vienna, Austria, and they sold it locally into the German-speaking market, so Austria, Germany, and Switzerland.

Shimel: Mm-hmm.

Johri: And they had a nice, little business going and they had a great product. I ran into them about 4 years ago, in 2013. I found them and felt that this could be a really interesting offering because what the market needed was automation, especially as people were going to Agile. Given my background with Mercury at HP, I knew that there was not much automation, but, if you go Agile, you have to have automation. It becomes a critical component – automation on the testing side becomes critical – and that’s why I joined the company. You’re right; they were initially focused primarily on Europe. And, remember, this is pre-coining of the term “DevOps,” but the need for automation was always there, especially as you kind of shift towards Agile on the dev side.

So now, you know, cycle ahead four years and we are now a global company. We did as much business in US as in Europe, so we are now really very well balanced. And we also have now created a presence, over the last few years, in Asia-Pac, so Australia, New Zealand, and Singapore, so we’re truly kinda global, with a typical balance of about equal between US and EMEA, and then another additional APAC component to it. And, obviously, once DevOps became the kinda mantra in the industry, we had a really nice fit and people started talking about continuous testing. Well, with automation, what you really get is continuous testing, so that’s why we are all about continuous testing. But the core engine is an automation – is a test-automation engine, so for the enterprise.

Shimel: Absolutely. So I wanna get into the whole automation and testing market, but you mentioned a few things that I, if you don’t mind, I’d like to dive into. I don’t mean to embarrass you, Sandeep, but, when you get to my age – and you’re a contemporary – you know, we like to reminisce. So you mentioned Mercury and your experience there. I mean, for those who aren’t looking at your CV or the management team details up on the Tricentis site, why don’t you give a little background on yourself to our audience so they get a flavor for this?

Johri: Sure. Sure, Alan. I’ll try to keep it short. I’ve been in Silicon Valley for almost 30 years and I’ve been entrepreneur. I started a few companies. One was Oblix, which was a leader in the identity space. And then a couple of other companies, Blue Lane and Determina, which were then acquired by VMware. I joined HP after that because they were looking to build out their IT-management portfolio, and, over 3 or 4 years, from 2005 to 2008, we acquired about 13, 14 companies, including Mercury Interactive, which was the largest, but we also acquired Opsware for data-center automation; we acquired Peregrine for asset and service management. And that whole portfolio became HP ALM, so it was – that business went from about $600 million to about $3.5 billion.

Shimel: Wow.

Johri: And then everyone knows HP was having some challenges and were increasingly focused less on the software business, which they eventually sold last year. But I felt the need – I felt the opportunity was there for a next-generation tool or next-generation testing platform that better suits the Agile automation environment, which we now call more “DevOps” because it takes the whole cycles and kinda creates a continuous-delivery chain, if you may.

Shimel: Absolutely. So, Sandeep, that’s sort of the quintessential Silicon Valley entrepreneur story, where you’ve done everything from start-ups that had some very successful exits. As I mentioned offline, I remember Oblix and I remember Blue Lane almost like it was yesterday. And then, of course, you had this big company, HP kind of experience on the resume, and I would imagine, knowing what I know about the Insight Venture team, who I believe is an investor in Tricentis, I would imagine you would have been a very, very attractive candidate, when they were looking for a – the team was looking for a CEO to take Tricentis to the next level, so right person at the right time there. Fantastic story.

Johri: Yeah, I joined before Insight came in. Yeah, I joined four years ago – Insight came in last year – because I thought that they were really promising, and we spent the first couple of years kind of building out the product to be more – you know, filling out the product. We added service virtualization. We added test data in it. You know, we’ve added a whole bunch of capabilities and we were beginning to get recognized by Gartner and the like as a leader and we also started having some really large enterprise customers in the US. That’s when Insight also had a similar thesis, that, “Hey, HP seems to be walking away from this market, but there’s a need – there’s an opportunity there,” and they found us. And that’s why they invested $165 million late last year, so.

Shimel: Wow. That’s quite an investment. And so sort of I had the horse before the cart, but congratulations. Right? This is not an easy thing with that kind of investment, but also comes when there’s that kind of opportunity. Let’s turn now, if we can, Sandeep, and talk a little bit about the testing market. You know, testing – before DevOps and Agile, the whole QA testing thing was really, really super geeky and I don’t know how interesting to people. Back in my day, at StillSecure, the hardest thing for us in testing was just building up a test lab that could handle the scale we wanted to test at. Right?

Johri: Right. Right. Right.

Shimel: And testing software and so forth was relatively a bunch of open-source tools that the development team did as part of the release cycle in the old Waterfall. But, you know, with Agile and automation and, look, there’s Agile with automation and then there’s automation in and of itself, throughout the software life cycle.

Johri: Uh-huh.

Shimel: It’s become imperative, right? And, all of a sudden, now –

Johri: Right.

Shimel: – yeah – testing has taken on a super role, right? I mean, it’s really become kind of the – you know, when we look at the continuous integration, continuous delivery pipeline, right, that testing, man, it sticks out. And it’s like swamping everything else, if you will, right? It’s swallowing it.

Johri: Right.

Shimel: And so tremendous opportunity. We’ve seen a number of companies try to enter this fray, many of them based on open source, whether they’re doing Selenium or something like that, but there’s different aspects of testing. Can you share with our audience, Sandeep, what type of testing is it that Tricentis is doing?

Johri: Right. And so, Alan, I think you cover a lot of the history and perhaps I can comment on that because that’s really interesting. So, you know, testing, for an enterprise, has always been critical, but you’re right. It was kind of a “Oh, God, I have to do testing and it’s a lot of manual process,” so people mostly outsourced testing. And, when you were in Waterfall mode, that was okay because you did a bunch of development and then you threw it over the wall. In most cases, at an enterprise, it went offshore and people did it manually. But it has always been a huge spend. Even today, there’s a $30-billion spend on testing services.

Now the challenge is that the tools that were out there, both open-source and commercial tools, were primarily script-based tools, so it was really difficult to automate. And, because you had outsourced, you kinda got the labor arbitrage and people continued to do it manually. And, even today, 80 percent of testing, enterprise testing, is done manually, which is kinda crazy, right? ‘Cause here we’re getting ready with autonomous cars on the one hand, but, on the other hand, we’re doing software testing which is – software’s so fundamental to every enterprise – we’re doing all the testing manually. Well, now – and that was okay in the Waterfall environment.

As you go to Agile on the dev side, you start doing frequent builds. And, as you start doing frequent builds, if your testing cycle is still six to 12 weeks, you’ll fall right back into a Waterfall mode, even though your dev might be Agile. So testing is becoming – the need for automated testing is becoming critical because, otherwise, it becomes the bottleneck in your delivery chain. And what we do or our view of testing is that testing should be at the same cadence as development, so, if you’re doing daily builds, you should be testing on a daily basis.

Now you mentioned developers. Developers do unit testing – they do subsystem-level testing as they build – but, for a large enterprise, which has a complex environment that has a mix of technologies, just doing subsystem-level testing doesn’t work. It is necessary but not sufficient. And, therefore, what you need to be able to do to really deliver faster or to really be getting – to get into a continuous-delivery mode, you need to be able to build continuously but also test end-to-end on a continuous basis. And that is fundamentally what we enable through automation. We can get to 90-percent automation; we leave manual testing only for usability and exploratory. And then, you know, you truly have your DevOps tool chain in a continuous mode, where you’re doing continuous builds and then –

Shimel: Mm-hmm.

Johri: You’re doing continuous builds on the one hand, you’re doing continuous testing on the same cadence, and then you can push it out into ops, so you’re right. It becomes absolutely critical, and the manual testing is rapidly decreasing, and people are shifting more to automation now.

Shimel: Absolutely. And not only shifting. You know, it’s a global, massive shift to automation and especially with the testing. And, frankly, look, that’s why you get the kind of valuations we’re seeing. That’s why you’re seeing the kind of acquisitions by large companies that we’re seeing. You know, I don’t see how you can do testing, going forward, without automation, so this is a fundamental change in the way this is being done. You know, you look at some of the companies from the old way of doing it, who are maybe selling testing equipment and so forth. Right? And they’re kind of dead men walking, to a certain extent. Right? And I –

Johri: Yeah.

Shimel: Geez, I don’t know what to tell you with it.

Johri: But, you know, Alan, one more point on that. I think when you think about a large enterprise – a bank, an insurance company, or the like – their business processes span technologies, meaning they have modern front ends, but they also have a lot of legacy systems. And most of the early DevOps work has been done only on the front-end systems, where you can go dev and, as long as you’ve done some unit testing, you can move to production. When you’re thinking about enterprises with large end-to-end systems that span every technology that’s been invented, you have to get into a continuous-testing mode; otherwise, you cannot do DevOps for a large enterprise. So the enterprise DevOps is a slightly different animal than, let’s say, a smaller startup in Silicon Valley doing DevOps, where they have a relatively modern tech stack and a relatively monolithic application, if you may.

Shimel: And, frankly, I always like to say, Sandeep, those companies – first of all, it’s DevOps, right? I don’t care whether you’re big or little – you’re all like do DevOps – but they do DevOps because they just don’t have the resources to do it any other way, frankly, right? Everyone wearing multiple hats and the way they – they have to – it is just no other way. It’s in their DNA, if you will. Where, with large enterprises, it’s DevOps or die, to a certain extent, in today’s competitive marketplace. And when I say “DevOps,” I’m talking about continuous – continuous testing, continuous delivery, continuous integration. You know, that automation is wherever – I mean, you know, all of the things we’ve come now to recognize as DevOps. So –

Johri: Mm-hmm.

Shimel: Sandeep, I guess we see these mega-trends. We see the way the market’s heading. We’ve heard about your background and the company’s history. I mean, it’s an eight-year-old or nine-year-old startup, right?

Johri: Mm-hmm. That’s right.

Shimel: What does the future hold? Specifically for Tricentis.

Johri: Well, you know, we see ourselves as – and also we have about 600 large enterprises across those regions that I talked about – US, most of EMEA, and then Australia, New Zealand, and Singapore – and we focus primarily on large enterprises, the Global 2000 or the Global 5000. Competitively, we’ll end up replacing the old HP, which is now called “Micro Focus.” Most enterprises are looking for a modern tool set, just like they use AppDynamics or New Relic to replace the old app-monitoring solutions and they’re replacing old defect-management systems with newer things like Jira and the like. So we see a lot of replacement, but the really exciting part is that the $30-billion spend that I was talking about, on testing services, that is, like I said, mostly manual, and, as you start automating that, what we are really doing is disrupting that $30-billion manual-testing market. So the global opportunity for us is incredible. There’s a multibillion-dollar opportunity, in terms of what a platform like us can be selling out there.

Shimel: Mm-hmm.

Johri: Mercury was a billion-dollar company – almost a billion-dollar company 10 years ago, 2007, and so we see that not only as a replacement as a replacement opportunity, but also, because we’re disrupting the services play, as you disrupt manual labor, you know, a big chunk of it goes towards the automation tools, and that’s what we see. So, in terms of the future, we see a very, very bright future. And we wanna be the marketshare leader in testing tools, so we have a very comprehensive solution already for end-to-end testing, both performance and load testing, and we will continue to enhance it so that we’re the innovative leader, as we are right now. We will maintain that and continue the leadership, so.

Shimel: Sandeep, I have little doubt of that, as long as you’re at the helm, driving this. It sounds like, based on your track record – and I have to agree with almost everything you said about the market. That’s kind of where we are right now and it should be an interesting next couple of years. The opportunity is certainly there, right? Someone’s gonna dominate this.

Johri: Wonderful. Yes.

Shimel: Yep.

Johri: Mm-hmm. Mm-hmm.

Shimel: Sandeep, as I told you when we started, the 15 minutes goes really quickly, so we’re at 20 minutes already. So we’re gonna need to kinda wrap up on this, but, before we do, for people who may be – we’re doing a bunch of activities with Tricentis, where I believe we’ll have some webinars and some content up on devopsy.kinsta.cloud, but, beyond that, where can people maybe either see you guys at conferences or speaking? Or, obviously, they can go to tricentis.com – T-R-I-C-E-N-T-I-S.com – for information, but just if you happen to know off top of your head where people might get more info even or a little hands-on –

Johri: Yeah, well, we have – yeah, absolutely. Well, we, like you said, Alan, we do participate in most of the major conferences, either on DevOps or testing. You know, there’s testing-focused conferences we participate in. We also participate in larger vendor conferences, like the Appalachian Summit and SAP’s SAPPHIRE. But what is most exciting for me is that, this year, we’re organizing our first US user conference, which will really be a conference focused on continuous testing. And we have scheduled that for April, yeah, here in – actually, no, no, wait a minute. It is scheduled for –

Shimel: I don’t know.

Johri: Oh, God.

Shimel: You know what?

Johri: Yeah, I should –

Shimel: I’m looking it up myself for you. Hold on here. Tricentis Accelerate? Would that be it?

Johri: Yeah, it’s – yeah, it’s on the 8th or 9th.

Shimel: San Francisco, May 7th to May 8th.

Johri: Yes. Yes. Yes. May 7th and 8th. Sorry about that.

Shimel: It’s okay.

Johri: But that conference is gonna be completely focused on continuous testing. We’re gonna have – obviously, show all our product capabilities and the like, but what’s more interesting and exciting is that we’ll have a whole bunch of large enterprise customers that are gonna talk about how they’re tackling continuous testing, as they are on their journey of DevOps, so it should be really exciting. I would really welcome everybody to come attend that conference in San Francisco on May 7th and 8th.

Shimel: Yep. And also you’re doing, it looks like, one in Vienna, Austria, October 9th and 10th. And ’cause – you know what? – our audience, like DevOps itself, about 36, 37 percent are US-based and the rest of the world makes up the majority. For anyone interested, though, you can go to accelerate.tricentis.com – that’s accelerate, A-C-C-E-L-E-R-A-T-E, at tricentis – or accelerate.tricentis.com, to get information on both of those. And we’ll probably be covering them from devopsy.kinsta.cloud as well. Well, this has been a great introduction to Tricentis and a great discussion of the testing, Agile, DevOps market. Sandeep, thank you so much for joining us.

Johri: It was wonderful, Alan. Thanks a lot for the time. And I have a special offer for you. For your listeners, we will make some tickets available to the conference and you can distribute it to your favorite listeners, so we will follow up and get you a whole bunch of tickets to the conference that you can distribute to your readership. Your readership is exactly who we target and who we – that’s in our domain. That’s exactly our domain, so we’d love to have as many of your readers – or listeners and readers –

Shimel: As both, right.

Johri: attend the conference as possible. Yeah. Wonderful.

Shimel: Really kind for you. I will put it in the show notes as well as on the article on devopsy.kinsta.cloud, for people who are interested. We’ll raffle ’em off, depending how many we have here. Sandeep Johri, CEO, Tricentis, powerhouse in automated testing. Thanks for being this episode’s guest on DevOps Chat and continued success.

Johri: Thank you.

Shimel: Thank you. This is Alan Shimel for devopsy.kinsta.cloud, DevOps Chat. Thanks for listening, everyone, and we’ll see you soon on another DevOps Chat.

— Alan Shimel

March 9, 2018
DevOps Chat: Concurrent DevOps with GitLab CEO Sid Sijbrandij

In this DevOps Chat we speak with GitLab CEO Sid Sijbrandij. Sid has guided GitLab as a co-founder to the heights of the DevOps market. Joining Sid and me is Ashish Kuthiala, who recently joined GitLab. I have always been impressed with the completeness of GitLabs’ vision of the DevOps toolchain and what the company wants to offer. Sid’s vision for this is something he calls Concurrent DevOps. You will hear more about Concurrent DevOps in our chat, as well as in the months to come.

Another thing about GitLab is is an open source-based company, which allows for a lot of transparency. With hundreds of thousands of organizations using GitLab and thousands of paying customers, GitLab is a great example of a DevOps success story.

As usual, the audio of our conversation is immediately below, followed by a transcript of our conversation.

Audio

Transcript

[su_pullquote align=”right”] [su_custom_gallery source=”media: 120255″ link=”post” target=”blank” width=”200″ height=”200″ title=”never”]Sid Sijbrandij
Sid saw the first ruby code in 2007 and loved it so much he learned to program and made this his profession. Before that he was engaged in various businesses, from selling programmable infrared receivers to starting a recreational submarine company. He is always looking to publicly document an answer or to make a process more efficient. He was never good at sports but tries to make it up in quantity by hiking, sailing, skiing, snowboarding, speed skating, dancing Zouk, squashing, and running. In love participating in conversations on Hacker News, and reading Marc Andreessen’s tweets (now that Marc stopped this greatly increased his productivity).[/su_pullquote]Alan Shimel: Hey, everyone, it’s Alan Shimel, and it’s time for another DevOps Chat. Our DevOps Chat episode today is gonna be all about GitLab, and we’re joined by two GitLab folks. First joining us is the co-founder and CEO of GitLab, Sid Sijbrandij, and I hope I did that justice. Sid, welcome to DevOps Chat.

Sid Sijbrandij: Thanks for having me.

Shimel: Thank you. And joining Sid and I is a friend of mine, recently joined the GitLab team, Ashish Kuthiala. Ashish, I didn’t mess that up too bad, did I?

Ashish Kuthiala: No, you didn’t. No, that was perfect.

Shimel: Alright! Well, one of the nice things about tech is, I get a lot of experience. Not a lot of Smiths in the group. [Laughter] And as I said, this is Alan Shimel, and we’re here with DevOps Chat.

So, guys—GitLab. You know, first of all, Sid, I’m sure you’ve probably heard this before, but I’m sure there are people in our audience who still have to ask themselves, “GitHub, GitLab,” right? And as silly as it sounds, they may confuse them sometimes.

So, let’s set it straight in terms of GitLab. Sid, you co-founded it. What exactly is GitLab and how does it differ, let’s say, from GitHub, and we’ll go from there.

Sijbrandij: Yeah, so GitLab started off as an open source alternative to GitHub, where you could have Git repositories, do version control, do some issue management, and it’s now grown a lot as a company and as a project. We now do the whole DevOps life cycle. So, anything from planning to rolling out what you’ve made—CI/CD, packaging, monitoring—all in a single application.

Shimel: Great. And I think you’re being modest, actually. GitHub is certainly—when you say branched out, it’s branched out, I mean, from what I know, and I’m no expert, obviously, the breadth of the vision is pretty dynamic. So, congratulations with that.

Sijbrandij: Thank you.

Shimel: Ashish, you were—thank you. Ashish, you recently joined GitLab, and why don’t you give us out, what’s your position there?

Kuthiala: So, Alan, I think you and I have known each other for a while, and I am very passionate about the promise of DevOps, especially at large scale enterprises, right? Not smaller teams or not those who had the luxury of building out their infrastructure and teams to adopt DevOps and realize the promises of that.

We still a lot of the larger enterprises struggle with adopting and realizing the promise of DevOps as it is. I mean, a lot of them are achieving results, but a lot of them are still in the journey and trying to figure out how to get there.

So, and I had heard about GitLab, I knew that they were building out a solution for this, but I think it was in the last DevOps Enterprise Summit, you, I, and Haydn ran into each other. And I started talking to Haydn and I learned more about the company, and I think it’s just the right product at the right time. Because if you look at all the challenges that exist in the big enterprise, there’s massive transformation needed, and there’s several things that prevent this from moving forward at the speed that everybody would like, whether this is different organizations within the large organizations to get them to collaborate together, whether this is stitching together the different toolset chains to kind of make this seamless.

And I think GitLab has really built something from ground up that addresses this problem. And the good news is that the velocity at which we are adding functionality, we are adding the needs that need to be addressed. Because we are an open source company, we are completely open and transparent, right? We gather input from everybody, a road map is opened. We take the input, we take contributions, and we build the right thing for solving today’s problems. And as needs change, I see this model as something that can really adopt to that, right?

Because the world of DevOps is changing very rapidly, and often there’s a fear of getting locked in with a vendor, too. With our solution, I think the openness of it and the direction it can go to solve problems as they change is a great promise, and we’re already solving a lot of problems. So, that was a big thing for me, you know, that I considered in joining GitLab.

And the other thing is the culture and open transparency that Sid and the company have built in the company. It’s just phenomenal for me, right? I mean, that was just an eye opening model of how everything we do is open to the world. It’s open within the employees. Anybody can contribute, anybody can look at everything we do and how we move forward to help our customers.

So, these two are the main things for me that really inspired me to join GitLab.

Shimel: Great. So, Sid, I’d like to come back to you. Certainly, we can all have vision, but execution is what kinda separates winners from losers in the market. And I’d like to ask you, as the CEO, what’s the secret, if you want to share it with us, right? How do you translate this vision that attracts someone of Ashish’s quality and character and then translate that into an execution that actually translates to success in the market?

Sijbrandij: Yeah, I’d love to talk about that. We’re biting off a lot, so I think we’re now—GitLab offers a great solution for 10 different product categories. So, that’s massive. There’s a lot of engineering effort. For example, we have a CI/CD team that is just 10 people, and that they have to compete with people that are 100 times bigger. So, how do they do that? First, they’re just selected. GitLab CI is the leader in this space. There’s GitLab CI on the top right and then whole lot of nothing.

Shimel: Mm-hmm.

Sijbrandij: So, how do you do that with 10 people? Well, there’s a couple of secrets. The first one is—you don’t do that with 10 people, you do that with 1,800 people. So, we’ve got over 100,000 organizations using GitLab, and over 1,800 people contributed to the product. So, in the release that will go out in a week from now, there’s not just 1 contribution, there’s not 10, there’s 93 features that people contributed that aren’t paid by GitLab.

So, we see it as, instead of having a tool chain where you have to make the integrations yourself—and that’s not just a few, we identified over 24 integrations you have to make in a standard DevOps tool chain. Instead of making them all yourself with your DevOps tooling team, you work together with 100,000 organizations and 1,800 people to do that.

So, that’s the big secret. It’s open source. We work together. Then there’s some small secrets, and one of them is iteration. Iteration is one of our six values, and it’s something that everyone is super excited about when they join, but they all kind of don’t understand how painful it is, because it’s very, very painful to do the minimal thing. We’re now in a call with Ashish that Ashish will probably not like that we’re gonna probably change the header on our home page today, because we thought of something better. He’s probably gonna say no, but give me a month, I can think of something even better. And I will be like, “That’s great, Ashish. Think of something even better and then change it again.”

Shimel: Yep.

Sijbrandij: It’s very, very painful, and we do that throughout the company, and in product, it’s a very painful thing. My previous call was with Martin, and they’re working on a cloud native chart for GitLab, and we have a thing with uploads and we probably are gonna ship a chart with an NFS server as a part of that. A very clumsy thing, but it unlocks everybody else, and we can keep shipping. And one of our other subvalues is boring solutions, and I love that, because it’s so obvious. You say “boring solution” and people understand what you mean. We don’t go for the shiny toy. Our mission is, everyone can contribute, and people can only contribute if there’s a stable environment to do that, if they understand what you’re doing.

So, when I saw the GitLab code base a year after Dmitri created it, I expected to see a hobby project. Someone super passionate, but doing this outside of work, like, putting some new development paradigms in it and having something that is hard to comprehend, especially since 300 people already contributed in that first year.

And instead, I opened up the code base, and I saw a pristine Ruby on Rails application. Totally idiomatic, like, exactly how it should be, and we kept that. We don’t allow anyone to do anything that isn’t boring, and that enables everyone to contribute. That enables us to make forward progress, and we adopt the best of what’s out there. We embrace Kubernetes, we embrace Prometheus—really great, rock solid open source solutions that we can build for later on, and that’s been a big success.

Shimel: Absolutely. You know, Sid, that was a mouthful in more ways than one, right? So, let’s hit on a couple things. First of all, harnessing the power of open source, right? Right out of The Cathedral and the Bazaar, you know, the book, and what’s gone on is, I mean, the false multiplier there is amazing. Of course, there’s a certain amount of a herding cats element to it, right, in getting everyone moving the same way. But if you can, harnessing that power is just—you know, it’s amazing.

No. 2, you know, you spoke about iterations and sort of feedback loops and constant change, right? This is core to DevOps, right? This is DevOps 101 kinda stuff.

Sijbrandij: It really is. This is exactly what we deliver to customers.

Shimel: Yeah.

Sijbrandij: Organizations adopt GitLab because we can make their DevOps life cycle three times faster, but you still have to work between the tools. They had these handles between the tools, they had these integrations that weren’t transparent, that weren’t seamless.

With GitLab, they can work concurrently. As soon as you push your change, QA is gonna run, security tests run, production is gonna have the first review up out there. There’s not a sequence to it. It is, you paralyze the whole process and you gain tremendous speed and you reduce your time to value, and you allow to get feedback and to improve based on that. That’s the value we bring as a product and of course, we try to practice that ourselves.

Shimel: Yeah. Well, so, but you more than practice it yourself. I think, you know, Sid, I’m a little different. You’re the CEO of this great company, GitLab. I’m an observer, I’m a fly on the wall of many DevOps companies, of many DevOps transformations, and I will tell you, the DevOps tools providers who do it best are those who eat their own dog food, who are practicing DevOps themselves. If you can’t do DevOps internally, don’t try to tell other people how they should do it or, you know, what they should be doing.

It’s not a case of “do as I say, not as I do.” You have to live that, you have to talk the talk, walk the walk in order for you to truly understand it well enough to get other people to buy into it and be successful. So, kudos to GitLab for doing that.

You guys recently announced an acquisition in the securities space. We’re kinda running low on time, but I wanted to just touch on that. Sid, your take on it?

Sijbrandij: Yeah, we acquired a company called Gemnasium, and I think they’ve done the best job of any company of assessing all the different libraries, all the dependencies that are out there and saying which ones are vulnerable, which ones contain a problem. And that is functionality that’s gonna, that’s part of the DevOps life cycle, so we want them to be right in the product.

So, we’re really happy to join their team, and I’m super proud of them for embracing our values, because they joined us, and within three weeks, all the Gemnasium functionality ended up in GitLab, so.

Shimel: That’s cool.

Sijbrandij: We know we hired the right people, they’re amazing, so congrats to Philippe and his team.

Shimel: Yep. Congratulations to them. And look, we see it here, you know, this whole DevSecOps thing, if you will, if you want to call it that, is probably, along with testing, two of the hottest areas within the larger DevOps community.

Ashish, we’re almost out of time. Let me come back to you, though. So, you joined this fantastic organization. We’ve heard from Sid a little bit of a peek into what’s making this engine roar, this rocket lift off. What are you gonna bring to the table? What are we gonna see from you, Ashish?

Kuthiala: I think we need to take this message out to the marketplace, like, you know, a couple of things you talked about when people hear GitLab, they sometimes confuse it with the Git community and other Git offerings like GitHub, for example. So, we really need to tell the world what we are doing, and we are much more than just a repository engine, right? We do a lot more.

And now that, you know, we are out there trying to help other customers with their DevOps challenges, it’s actually a little bit more than what Sid mentioned here; he is being humble. So, not only are we practicing our own DevOps methodology to develop and roll out our application, but we actually use DevOps in every single aspect of running the company, right? Right from the hiring process when I joined to everything that I do in the company adopts a pipeline—you know, you create an issue and you run it through the pipeline and you merge that issue and it goes to production. If something is wrong, you know, it comes back.

Amazingly, everything, between signing for benefits to updating the webpages to running our tracking of issues of what we do, it’s all run through pipelines. And I think I see that as a future. You know, DevOps is not just to be applied to delivering IT value, but you know, it is a methodology that can be applied across running your company for all functions.

So, I think the version of GitLab is much bigger than just helping companies deliver efficient software really fast out there with feedback on the DevOps methodology. It’s almost to pivot and change the way we think about delivering value to our customers, in every aspect of running the company that we do. And I want to be part of that. I think it’s really exciting. I can’t wait to kind of start talking about this to everybody and, you know, seeing how we go down this journey.

Shimel: Great. Sid, we’re over time, but I want to give you the last word, so I’m gonna ask one last question for you. What can we expect to see next from GitLab?

Sijbrandij: We detail a really ambitious vision, and the vision is called Complete DevOps. And we said we’re gonna realize that this year, and we’re executing on that. We’re really proud, we integrated a complete web IDE in GitLab, so VS code running in GitLab. No need to check out this autocode base, you can just edit right there and then.

But it consists of a lot of parts. We’re gonna have real time editing of issue and merge request descriptions. We’re gonna add logging to GitLab. You can already do monitoring, but we’re gonna add something for your logs, we’re gonna add application performance monitoring. Lots of other things that we think are needed to have a complete solution.

So, if you started a startup, the only things you have to do is incorporate it, get a Kubernetes cluster, and install GitLab on it—job solved. Like, you’re up and running, you don’t need any other tools, and the only thing you have to do is, you push your code and already today, GitLab detects what language is it, it builds your code, it tests your code, it tests for all the security issues that might be there, it tests your code quality. It gives you all that. It gives you a review app to work with, kind of a staging app. That already works in GitLab today and we’re expanding on that, and I’m super excited to deliver that to the market this year.

Shimel: DevOps complete. Thank you. Ashish, Sid—thanks so much for being our guests on this episode of DevOps Chat. Continued success with GitLab. We’ll be checking in—actually, I’ll see some of the GitLab folks at IBM Think in a few weeks, and we’ll get an update there, but Sid, you’re always welcome to be a guest here, don’t be a stranger, and congratulations.

Sijbrandij: Thanks so much. Thanks for having us. I enjoyed this. Looking forward to coming back.

Shimel: Alright, Ashish—

Kuthiala: Thank you, Alan, for having us.

Shimel: – good luck, my friend. Be well. This is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat, and we’ll see you soon on another DevOps Chat, everyone.

— Alan Shimel

March 2, 2018
DevOps Chat: Startup Playbook, Founder to Founder Advice w/ Rajat Bhargava

Two old, good friends of mine published a book yesterday called Startup Playbook. The book is “founder-to-founder advice on how to create and build your startup.” In this DevOps Chat, I sat down with my friend and co-founder Rajat Bhargava. We talked about why he and Will Herman wrote this book, what he hopes others can learn from it and Raj gives us 3 tips on what every first time founder should know.

Between them, Will and Raj have started more than a dozen venture backed companies and have had multiple 8 and even 9 figure exists. If you have ever thought about starting your own company, had a great idea but weren’t sure what to do with it or just thought you could do a better job than the people you work for now, this book could be what you are looking for.

For this week (Feb 19) the book is available on Kindle for just 99 cents! Here is the link for the kindle download.  Also a few times at the end of our conversation I referred to the book as the “Founders Playbook”. I tried to dub in the correct name, the “Startup Playbook” but my feeble interviewing skills are far superior to my sound engineering ability. Apologies.

As usual the streaming media of our chat is immediately below, followed by the transcript of our conversation.

Audio

Transcript

Alan Shimel:   Hey everyone, it’s Alan Shimel, devopsy.kinsta.cloud, DevOps Chat. We’re here with another great DevOps Chat. Today’s chat is a little different for a couple of reasons. First of all, my guest is a very long-time – did I say long-time? – friend of mine, Rajat Bhargava. Raj, welcome to DevOps Chat.

Rajat Bhargava:         Thanks for having me, Alan.

Alan Shimel:               Hey man, thanks. Secondly, our chat today is a little different. Rather than talking nuts and bolts of DevOps and that kind of stuff, we’re gonna talk about Raj’s new book, along with his co-author, another friend of mine, Will Herman, called The Startup Playbook.

Raj, I’ve known about the project for some time, but tell our audience, share with them what is The Startup Playbook. Why did you write it?

Rajat Bhargava:         Well, The Startup Playbook is really our founder-to-founder conversation with other entrepreneurs. We’ve seen so many books out there that are from DCs, they might be from analysts, they might be from other folks out there, but we felt that founders out there needed a book from us, from other founders. Whether we wrote it, Will and I, or somebody else, we just felt like somebody had to talk about the tips, the secrets, the tribal knowledge, the stuff that we get by getting together and talking to other founders. We just felt like that was missing.

We have these conversations with so many other founders on a daily basis because we mentor and advise and help support other founders, we just felt like we needed to write it down. It’s like around the campfire, we have so many of these conversations, we felt like we needed to write it down so that there was a place that other founders could go to to learn quickly.

Alan Shimel:               Just in the way of full disclosure, you know, Raj, you and I have worked together on at least two or three companies, maybe more. But in the way of background, you’ve actually founded, what, about eight companies now, starting when you were still back at university at MIT, correct?

Rajat Bhargava:         Yeah, that’s right. So, it’s probably now close to 10 that I’ve helped start, or started myself. There’s just a lot of mistakes that I’ve made and a lot of challenges that I’ve faced, and I wanted to share those. On the same, Will has probably started five different businesses and he’s got tremendous experience, tremendous knowledge. We’ve both been through so many different things that we wanted to share those so that other people didn’t have to go through the same pain that we went through.

Alan Shimel:               As we used to call it, the idiot tax, right?

Rajat Bhargava:         That’s right.

Alan Shimel:               Our audience – I don’t know how many “entrepreneurs” we have listening in, though I hope there are some – is made up of a lot of technical people. People, Raj, not that different, frankly, than you, right? Who have a great engineering background, live, breathe and die in today’s technology.

I’m sure there’s a big subset of them out there who maybe have a great idea, who see a hole in the market, who see a need in the market, have something that they say can really maybe change the world and make a great company. But they just don’t, they’ve never done it. They don’t know where to start. I know that’s who you are aiming for a lot in this book. Talk to us a little bit about that persona, that kind of person. What’s in the book for them?

Rajat Bhargava:         Well, this book is absolutely targeted directly at them. In general, the book is a founder-to-founder conversation. The founders we’re really trying to target are those first-time founders, the folks that haven’t been through it before. Like you said, they may not know all the steps that they need to go through. They may not even know if founding a business is the right thing for them.

So, we actually start before you start a business in the book. We start about whether this is the right thing for you to do for you, for your family, for you as a person. Is founding a company the right thing for you? We start there. So, it’s from the ground up and we build up from there.

I think our belief is – we’re biased because both Will and I were engineers by educational background – we think some of the greatest businesses are started by engineers, by technical folks. We love when technical folks bring ideas forward, and we think they can change the world. The challenge is that the idea is just not good enough. Ideas are, unfortunately or fortunately, either way you look at it, they’re a dime a dozen. It isn’t the idea that’s so differentiating; it’s all of the other work that you do around the idea that makes it differentiating, that makes the successful business.

That’s a lot of what we talk about in the book is that the idea really just isn’t enough. It’s a seed. It’s a kernel. It’s where you start, but it’s just the beginning. It’s a long, long journey, but a great idea is a wonderful place to start.

Even an okay idea is a great place to start because you can iterate on it and you can improve it. You can make it much better. Then, a lot of the stuff that you do around that idea is what differentiates you and helps make you successful.

So, for your audience, for technical folks who have an idea, we think that’s fantastic. That’s a wonderful, wonderful base to start with, to build a business.

Alan Shimel:               You know, there’s a lot in there, Raj. I want to highlight a few things. First of all, it’s true, whether you have a job or you’re starting your own company, but don’t underestimate that when you go to start, become a founder, that it doesn’t just affect you, right? It affects your family, your loved ones, your significant others and what have you. Because I’ve never met anyone who is successful with a half-hearted attempt to start a company, or to start a business, or to nurture an idea like that, to nurture a business. To me, it’s either you’re all in or you’re out.

Rajat Bhargava:         Absolutely, yeah.

Alan Shimel:               That’s one thing I think people need to think. Let me also hit on one other thing and that is when you speak to people, and you’ve spoken to more than me, but I’ve spoken to my share, what’s the biggest thing holding people back? If I took a poll, Raj, and said, “Hey, who would like to start their own company, be their own boss, and make a lot of money and be successful?” Very few people are gonna keep their hands down; everyone wants to do that.

What stops people from doing that? Well, number one, it’s a little bit of fear of the unknown, having never done it. But number two, the biggest thing I hear from people is, “My god, I don’t have the money to get there. What am I gonna do until my company makes enough money? How do I bridge from having a job with a steady income that keeps the lights on to the time where my startup is enough for me to support myself?”

That’s probably the single most scariest thing for first-time founders. What do you think?

Rajat Bhargava:         You know, I think you’re right. I think there’s absolutely the fear of the unknown and fear of failure which, by the way, 9 out of 10 startups, according to the research, fail, which we actually think is low. We probably think it’s closer to 95 out of 100, maybe even 97 out of 100. Very few companies succeed long-term. The ones that are breakout successes that we hear about in the media are few and far between. It’s so few of the ones that start.

I think the second point is such an important point, which is how do I go start this business when I need money to live on, and there’s no cash coming in at the beginning? Well, that is a very, very hard problem. The good news is there are so many solutions to it, but some of it is a leap of faith, too.

The thing I would start with is there is so much prep work that needs to happen before you launch a business. That is where we spent a tremendous amount of time in the book talking about how do you vet your idea? That doesn’t have to happen only with you quitting your day job, and going and working on it. Some portions of that at some point you may need to do full time, but you can do a tremendous amount of research, of vetting your idea, of building your plans, of figuring out whether this concept that you have can be really, truly built into a business.

We encourage people to spend an inordinate amount of time at the beginning going and doing that. Because if you can build the right foundation at the beginning, you’ve got a shot at making it successful. If you start with a very shaky foundation, those cracks are gonna get exposed very fast and the chances of you succeeding go down dramatically. So, even if you need that job, even if you need that income coming in, there’s still a lot you can do to build out your concept and build out your business, even before you take the plunge.

Alan Shimel:               Fair enough. So, Raj, if we take that as okay, that’s one tip for prospective first-time entrepreneur founders, ’cause we’re running low on time, give me three or four others, if you can. Maybe a top five of what a first-time founder should…really idiot tax saving tips here that they can really rely on.

Rajat Bhargava:         Sure. I’ll give you three. The first one is the one we just talked about, but I’ll expand it.

I think completely vetting your idea before you really go all-in is so critical. That includes things like the value prop, the target customer. How can you build a team, or who is the team? Can you actually build the product or service that you’re proposing?

Can you differentiate it in the market? How are you gonna go get customers? How can you make money? Can you raise money to support yourself? All those things are the art of what we call vetting your idea. The more you can vet the idea from the beginning, the more solid of a foundation you have. That’s tip number one is completely vet your idea.

Tip number two is build a team around you. People think that starting a company could be just a single founder. Especially as an engineer or a technical person you might say hey, I’ve got this great idea. Why do I need to have another co-founder until later?

Well, we encourage you to get other co-founders right out of the gate. At least one, if not two. It’s critical that you have some people who are side-by-side with you as you go through this journey. Find people who have different perspectives, but that you can really work with. It’s one of the most important relationships that you’ll have in the business.

The third thing is find mentors, advisors, board members, people that have done it before that you can learn from. There is nothing like saving yourself time, mistakes, challenges, problems by hearing advice from others. You have to be open to it, but if you’re open to it, you can really accelerate the progress of the business.

Those are three quick tips that I would say are things a first-time founder ought to think about really hard.

Alan Shimel:               Yeah, and those are three good ones, too. I’m sure the book is chock full of more of them.

Raj, let me throw you a little bit of a curveball. In addition to wanting to start businesses because they see needs in the market, I can’t tell you how many engineers and technical folks I speak to that would like to write a book. Again, I don’t know what stops them. Many do cross that chasm, right, and write a book; many don’t.

For people who maybe don’t want to start a business today, but do want to write a book…and most of them are not novels. They’re much like Founders Playbook, non-fiction kind of books. What advice can you give to budding or prospective authors out there?

Rajat Bhargava:         You know, It’s different for everybody, but the thing that I think helped Will and I the most was we just broke it down into a little bit of time every single day. When I initially wrote the first draft of the book, I had a target of 1,000 words a day, which isn’t a lot, as you know, Alan. You can write 1,000 words probably in about 30 minutes, so it’s really not that much time. But if you plug away at that for 90 days, for just one quarter [break in audio]. The typical book is really more like 45,000 words. If you did it for 90 days, you’ve got 1,000 words, and you can throw away half of those words because –

Alan Shimel:               And still have a book.

Rajat Bhargava:         And still have a book. Or you could have two books, right? I think that’s the biggest thing is just don’t try and do it all in one sitting ’cause you can’t. That’s not the way it happens. You need to just chunk it up and do a little bit at a time. In my case, what I did was I just started writing. I didn’t even really have too much of an outline. I just started writing 1,000 words a day.

Then, we took that and we started formulating that into a book. So, we threw out tons of it, we rewrote it a couple of times. There’s just a tremendous amount of editing work. But the editing work turns out to be a lot easier – at least it feels easier; it probably isn’t easier – because you already have something down. It’s the blank sheet of paper that’s really daunting. But if you say, “I have a blank sheet of paper today and I only need to write 1,000 words,” that’s not that bad. You can get there.

Alan Shimel:               Sounds like an agile methodology to authoring a book. Doing it in sprints.

Rajat Bhargava:         Exactly. Yeah, exactly. Do a sprint a day.

Alan Shimel:               Yeah, that sounds cool. A little scrum meeting in the morning.

Well Raj, we’re about out of time here, but for our audience who maybe are interested in taking a look at Founders Playbook, I know you guys are offering sort of an introductory launch as the book goes to launch special. Where can we get some information here?

Rajat Bhargava:         You can go to startup-playbook.com and you can also go to Amazon and just search The Startup Playbook. It is 99 cents for the Kindle version for the first week or so; that’ll come up on Monday the 19th of February. It’ll be 99 cents for a week. We’ve tried to make it really accessible for everybody. We really just want to get the knowledge and the content out into the founders’ hands.

Startup-playbook.com, or look on Amazon, The Startup Playbook.

Alan Shimel:               Raj, beyond the book itself, I know you and Will have plans to try to nurture a community here with that. If people have questions, are there places on the website where maybe they could ask and stuff?

Rajat Bhargava:         Yeah, absolutely. You can reach us on Facebook, on Twitter, on LinkedIn. If you go to the website, there’s links to all of that. You can reach out to us pretty easily. You can find us, and we’d be happy to engage and chat with you.

Alan Shimel:               Sounds great. Hey Raj, I know this was a labor of love, but it was nevertheless a labor, and a long time coming for both you and Will. So, congratulations on the launch of the book, The Founders Playbook. You know what? We’ll keep an eye on it and watch it. I hope some of our listeners out here go check it out. The only thing you have to fear is fear itself. If you’ve got a great idea, the world’s waiting and you can make it happen.

Rajat Bhargava, my friend as well as author of The Founders Playbook, thanks for being this episode’s guest on DevOps Chat.

Rajat Bhargava:         Thanks for having me, Alan.

Alan Shimel:               All righty. This is Alan Shimel. We’ll see you soon on the next DevOps Chat.

— Alan Shimel

February 20, 2018
DevOps Chat: ASRTM for DevOps with Rohit Sethi, Security Compass

In this DevOps/Security Boulevard Chat we speak with Rohit Sethi, COO of Security Compass about ASRTM, which stands for Application Security Requirements and Threat Management. Gartner has recently released a hype cycle on ASRTM, with Security Compass and its SD Elements offering named a leader in the market. Rohit gives us a good background and foundation on ASRTM and why it is important for both DevOps and security teams.

As usual, the streaming audio is immediately below, followed by a transcript of our conversation.

Audio

Transcript

[su_pullquote align=”right”][su_custom_gallery source=”media: 119457″ target=”blank” width=”200″ height=”200″]Rohit Sethi
Rohit Sethi joined Security Compass as the second full-time employee. As COO, Rohit is responsible for setting and achieving corporate objectives, company alignment and driving strategy to execution. Previous to this role, he managed the SD Elements team. Rohit specializes in building security into software, working with several large companies in different organizations. Rohit has appeared as a security expert on television outlets as such as Bloomberg, CNBC, FoxNews, and several others. He has also spoken at numerous industry conferences s and/or written articles on major websites such as CNN.com, the Huffington Post and InfoQ.[/su_pullquote]

Alan Shimel: Hey, everyone. This is Alan Shimel for Security Boulevard Security Chat, and this will also be appearing on devopsy.kinsta.cloud under DevOps Chat. So two chats for the price of one, though it’s one chat. Welcome, and we have a great guest lined up for today. I have Rohit Sethi—and I mispronounced that. I think it’s actually Rohit Sethi. But in any event, you can correct me. Rohit, welcome.

Rohit Sethi: Thank you.

Related Content:

How Developers Can Take a More Proactive Approach to Security

DevOps Chat: Aqua Security Seeks To Secure Containers

Shimel: Just for the record, say your name correctly.

Sethi: Rohit Sethi.

Shimel: Rohit? Okay. Rohit, you know, as my mom used to say, “Call me anything you want, but not late for dinner.”

Sethi: [Laughter]

Shimel: Welcome to Security Boulevard Security Chat and thanks for joining us. So you are the COO of Security Compass, correct?

Sethi: Correct.

Shimel: And there’s probably people in our audience who maybe are not familiar with Security Compass. So why don’t we start there. Can you give us a little bit of background on Security Compass?

Sethi: Sure. We are a firm that is specializing on software security. And we have three main offerings around that. So we have an advisory practice that does penetration testing, and code reviews, and threat modeling, but also helping people build up their secure software program. And especially more recently building up their dev sec ops program and building security into their DevOps pipeline.

Shimel: Mm-hmm.

Sethi: We have a training practice, which is specialized in training developers. We’ve partnered with ISC-Squared and we offer a certificate or batch program on secure development for software developers. And then we have a product called SD Elements, which is an application security requirements and threat management. I know that’s a mouthful. And what we’re going to talk about today is a platform that helps people build security and compliance to some extent into their software development process, and particularly for agile and dev ops processes.

Shimel: Excellent. Now, so a couple of things that we want to talk about relate. And one of them is recently Gartner’s come out with another magic quadrant or a new magic quadrant where they’re kind of lumping together what I personally always thought of was two distinct areas. And they’re calling it – and I’m going to mess this up. Why don’t you help me? AR –

Sethi: ASRTM.

Shimel: ASRTM. Why don’t you tell our audience what that stands for?

Sethi: Yeah. ASRTM is application security requirements and threat management. And it’s not quite a magic quadrant yet, but it’s on the hype cycle.

Shimel: Hype cycle. You’re right.

Sethi: Okay. So they’re identifying it as a sort of an emerging category for people to start paying attention to.

Shimel: Yep. And so for our audience and for me, talk to me. How did the nexus here between them?

Sethi: eah. So you can think of [Laughter] anything in this category as being tooling that helps you to build security into the onset of development. Most of the tools that exist in the application security category today are some form of static analysis, dynamic analysis, interactive application, security testing. So really all different kinds of testing looking for security defects, or blocking the tax in real time. Right? So real-time application security protection or web application firewalls.

And many people their entire budget is on testing and sort of blocking attacks. But really very little focus on building security from the start, except for perhaps in training. So everything in this tool category is essentially some kind of product that will help you to systematically and in kind of a scalable way build security in so that you don’t get those defects when you do your testing. And perhaps more importantly, to prevent defects that perhaps those automated tools are just incapable of finding.

Shimel: Got it. Got it. Got it. Got it. And so I think we’ve laid the foundation, if you will, Rohit. Let’s jump into a little bit of how this relates to dev ops and what we call dev sec ops. So why –

Sethi: Yeah.

Shimel: Go ahead. Why don’t you take a lead on that?

Sethi: Yeah. For sure. So DevOps is a phenomenon that it’s not just for sort of fast-moving organizations. Even some of the slower or I guess you’d say larger companies are starting to embrace DevOps, as you know. And it’s becoming really quickly sort of a mainstream philosophy. And there’s just really rapid pace of change of tooling that people are looking at – and not just tooling, but processes, to be able to accommodate continuous integration and continuous delivery in all of the mentality changes and processes that have to change to allow that to happen.

Now, when we think about the traditional secure software development life cycle, there’s a lot of activities that we’ve typically suggested in the security community about following a secure SDLC, that really kind of incongruent with this idea of either having really fast sprints or no sprint, no iterations, just being able to take one ticket at a time, build it, and deploy it. So the idea of doing like an architectural analysis, or a one-week or two-weeks threat model, these things are sort of thrown out the door when the pace of development is too fast to keep up with it.

And so that kind of opens up the need for automation. Now, there’s sort of a trend, and I would call it, I would label it a dangerous trend, that people are looking to 100 percent automated solutions to sort of take away the security problem. Right? So you’ll see sometimes people will put together presentations on DevSecOps and they’ll say static analysis is sort of your way to handle secure coding. And then perhaps some penetration testing on a periodic basis and you’ve kind of checked off the box for secure development. But the reality is that, in fact, security is a lot more complex than that.

Static analysis tools and dynamic analysis tools have their strengths, but they also have significant gaps. We actually put together a white paper that talks about the missing parts of what scanners can’t find, false negative gap. And one of the interesting things is if you look at sort of CC plus plus development for a second, one of the most pervasive vulnerabilities is buffer overflows. This is the thing that caused Heartbleed and WannaCry and pet. Yeah. It’s sort of the underlying root cause there was some memory management issue.

And if you were to take some of the best practice in terms of highly automated scanning solutions and put them all together, they’d still be able to find less than half of all buffer overflow vulnerabilities. Yet, this is what a lot of the industry is converging on as good enough from a software security perspective.

So not everybody looks at it that way, and there’s a lot of people who realize that there’s a gap here that we need to do more than just scanning. It is an essential part of the solution, but we need to be able to identify what are all of the relevant threats to an application development, and how do we actually build mitigating controls rather than fixing the vulnerability after the fact? So prevention instead of detection.

And that’s really where the ASRTM category fits in. It allows you to define what those controls are and build them into the software development process. Not only, in fact, from a security perspective, but also like compliance control, some of the GDPR issues that will come up there.

You have to kind of build data protection by design and default. You need a system, a systematic way to identify these as essentially requirements that go into your backlog, right, and that you can track whether or not they’ve been tested. And that’s quite different than the approach that people have typically taken to finding vulnerabilities after the fact and fixing them.

Shimel: Mm-hmm. So Rohit, our audience, especially from devopsy.kinsta.cloud, of course, is extremely savvy to the whole DevOps and DevSecOps terminology and kind of what’s happening. One of the issues that we see with this, though, is so many of our security solutions are geared for security professionals.

Sethi: Yeah.

Shimel: Where so much of the real responsibility for secure coding and secure apps lies with the developers.

Sethi: Yes.

Shimel: Right?

Sethi: Yeah.

Shimel: And to that no one – you know what? I’ve never met a developer, Rohit, who raises his hand and says, “I want to develop insecure code.” Or, “I want to have an insecure application.” They all want security, obviously.

Sethi: Yeah.

Shimel: But they may not have the expertise. They may not have the support. They may not have the time, frankly, to do it right.

Sethi: Yeah.

Shimel: So how does like a Security Compass type of solution help not only the security guy, but the developer, as well?

Sethi: Yeah. Excellent question. So the way that the work flow in an ASRTM solution works – and I’ll talk specifically to ST Elements, which is our product. But we’re not the only product that does this. Is that somebody in a product team – so we have a lot of clients that use it this way. It’s sort of a self-service model.

So let’s say like a project manager. And so you mentioned developer, but I would extend that to the entire development team, right? Product owners, product managers, scrum masters, etc., right, who are involved with building software. So you take sort of a lead, whether that’s product manager, project manager, product owner, scrum master, lead developer. And they fill out a questionnaire that’s kind of like a base online ramp up of that software they’re building. So they’ll answer like a multiple-choice questionnaire.

And then based on the results of that questionnaire, they’ll get a defined set of prescriptive controls that are essentially security user stories, right, that you need to build into your software. And then what they’ll do is they’ll integrate it into gira, or Microsoft Team Foundation server, or whatever it is that the development team is using to manage their backlog. And then the product owner is then responsible for grooming it, just like they do feature or functional stories. Right?

So now what we’re doing is we’re taking the backlog, which is sort of the de facto list of work that needs to be done, and we’re putting non-functional requirements alongside the functional requirements, which allows the development team to take control of when they’re going to implement security work or security features, as opposed to just reacting to a security defect that’s found later on. So basically you’re turning unplanned work into planned work. So that’s the first thing that you do to sort of empower the development team.

The other, of course, is that when you take a look at these requirements and these controls, you actually start to bake training into it. So someone might get a control that talks about how to implement a secure password reset. Right? So this is a feature in the system that is the kind of thing that you really can’t find with an automated scanner, but that could lead to significant risk if it’s done incorrectly.

So you can actually have a Gira ticket that talks about the correct way to implement secure password reset, and you can have an actual embedded training module so somebody could actually learn about well what are the ways that people exploit password reset at the time that they implement the control. So it’s what we call just-in-time training. We think it’s a really important and powerful concept, especially as it relates to fast-moving development.

Shimel: Absolutely. So Rohit, I’ve always wanted to ask this question, then. And that is it’s incredibly difficult, then, as a Security Compass, let’s say –

Sethi: Yeah.

Shimel: To, I mean, number one as a salesperson to, who do I sell to? Who has the budget? Who is my technical stakeholder?

Sethi: Yeah.

Shimel: Who is making decisions? But beyond, you know, pity, no one’s going to play hard to the flowers for the sales team. [Laughter] But beyond that, as a solutions provider, serving two masters here.

Sethi: Yes. Yes.

Shimel: How?

Sethi: You know it – go ahead. Sorry.

Shimel: No, no. I was going to say how does that – I just, it’s gotta be really hard.

Sethi: It is hard. I wouldn’t say that it’s easy at all. But I think that it’s critical work. Like our vision as a company is a world where you can trust technology. And we really think that if we don’t do security right, that that vision will not be realized. People will be afraid of technology to some extent. We won’t be able to exploit the possibilities that technology affords us because we’re afraid of vulnerable technology.

And really, when you think about the root cause of most of the security incidents, sometimes it’s an insecure web application, but sometimes it’s a vulnerability in your desktop or operating system, or like a browser component or something. But so often it’s a secure coding issue. And so much of the sort of cybersecurity budget and infrastructure is based on the fact that well, let’s just take for granted that the software is insecure, and let’s find ways to mitigate the risk.

And of course we’ll never get 100 percent secure code. But we really think that there’s a huge gap between what we can feasibly do, right, versus what’s being done in industry today. And so that motivates us. And I think often when we start to talk about the data, we talk about and when we’re talking to the chief information and security officer, or the chief information officer, we talk about a visibility gap that they have, right?

Which is that right now the way that most companies work is they have a GRC solutions and sort of a policy departments to talk about what their high-level information security policy is. And then they may have some automated solutions to help enable that policy. But there’s sort of a gap between this high-level policy and then what are the specific things that an IT team needs to do to make sure that that policy is being followed and being able to track that?

And that’s really, I think, at the heart of what an ASRTM solution provides is the ability to take this policy, turn it into procedure, turn it into something you can track, and ensure consistency, right? Because you can’t rely 100 percent on sort of automated scanners to catch everything. So you need to have this sort of translation there. And we find that that works pretty well. People are receptive to that need.

And then, in fact, it’s not just application security, but it also involves infrastructure security, hardening servers, and that sort of thing, bender security, bender risk management, cloud security, how secure your cloud applications, and how do you know what to test against? So just like a variety of needs are met by adopting a program, really, that allows you to define your security controls at the granular level that your DevOps teams can implement them and you can track that.

Shimel: Fair. Fair enough. So what does the future hold here, then?

Sethi: Well, my hope is that we realize that vision, right? We get to a point – what I would like to see, for me success in the long term is that when we find that there’s a vulnerability that’s exploited in the wild that that vulnerability never creeps into code again. Right? Like if we know how to mitigate it, then it’s mitigated forever. And we’re so far away from that reality right now. Right? Like a lot of the real-world exploits are traced down to what is the root cause? It’s a secure coding issue that we’ve known for 15 or 20 years, in some cases.

And that’s just not good enough. So we’d like to get to a place where the only hacks that occur are really novel. Right? Like we’ve never seen anything like this before. And some really profound security researcher has found a security issue that they’ve spent a significant amount of time understanding that specific domain. Right? But not sequel injection. Right? Not parameter manipulation. Not things that we’ve known for years. And that’s really, I think, where we want to go. And I think that inevitably that’s the direction that the industry is going to move towards.

Shimel: Agree. Agree. Rohit, when we started, I told you the time goes quick. And we are coming up on our 15-minute window. But let me give the listeners – we want to find out more about Security Compass. Where can they find out more?

Sethi: Well, of course, you have, you know, SecurityCompass.com talks quite a bit about what our offerings are. You can feel free to e-mail us, info@SecurityCompass.com. I’m personally on Twitter so you can follow me. Just @RKSETHI. We have a LinkedIn page for Security Compass, as well. So lots of different ways you can interact with us.

And like I said, we offer training. So a lot of people who are, just want to learn more about application security, we have courses that you can just sort of enroll yourself. And we’ll be releasing more of those in the near-term future, as well.

Shimel: Got it. All right. So Rohit Sethi, thanks very much for being our guest on this episode of Security Boulevard Security Chat, as well as DevOps Chat. And we look forward to hearing more about Security Compass in the coming months. Thanks for being our guest today.

Sethi: Thank you for the opportunity. Appreciate it.

Shimel: All righty. Rohit Sethi, Security Compass here on Security Boulevard. This is Alan Shimel, and we’ll see you soon on another DevOps or Security Boulevard Chat.

— Alan Shimel

February 1, 2018
DevOps Chat: Rosalind Radcliffe, IBM, on DevOps and Mainframe Systems

In this DevOps Chat we sit down with a frequent guest on DevOps Chat, Rosalind Radcliffe, distinguished engineer and mainframe expert from IBM. Rosalind talks to us about the latest generation of Big Iron from IBM, the z14 systems. Also, we discuss some of the new API and functionality that allows you to do just about anything with your mainframe that you do with your other computing platforms.

Rosalind is always an interesting interview with lots of great information.

Note: There are references to a video chat throughout the conversation. We tried to record this chat as a video, but unfortunately, the technology just didn’t work out well for us. But, as usual, the streaming audio of our conversation is below, followed by the transcript of our conversation.

Alan Shimel: Hey, everyone. This is Alan Shimel of devopsy.kinsta.cloud, and you’re listening to perhaps the first video chat or video DevOps Chat from devopsy.kinsta.cloud. And I’m happy to have as my first video chat guest none other than Rosalind Radcliffe of IBM. Rosalind, welcome.

Rosalind Radcliffe: Happy to be here, as always.

Rosalind Radcliffe

Shimel: Well, you’re not going to be able to sit and make faces while you’re talking because we can see you. But thanks for joining us. Let’s jump right into things. First of all for our audience who may not know Rosalind, Rosalind is a distinguished engineer with IBM and works within the IBM Enterprise Systems division, mainframes, e-systems, author, engineer, well-known speaker and just a great resource for anyone who is interested in DevOps, mainframe, systems of engagement, systems of records kind of stuff, and a frequent guest here of ours on devopsy.kinsta.cloud.

So, Rosalind, the last time I saw you was over at Gene Kim’s DevOps Enterprise Summit in San Francisco. And I thought it was a great show this year. Had a chance to do a bunch of interviews. I did a panel on DevSecOps. But more than that, I really enjoyed speaking to a lot of the people in attendance there, a lot of the attendees. Any key takeaways from you on it?

Radcliffe: Well, I think it was another really good conference, but it was one year next. So there was a lot of people who really have done the DevOps transformation or are a good long way on the DevOps transformation. And so there were a lot more stories about the value that they’re getting and how they’ve transformed, and more about the organizational transformation that happens after you start a DevOps transformation. So I thought that was very good.

We also had more mainframe customers talking about their transformations, and it was really good to hear the stories about mainframe is really just part of the DevOps pipeline, and more and more customers are starting to see that.

Shimel: I think so. And Rosalind, if you don’t mind, I actually wrote an article coming home from Gene’s event called “The DevOps Cha-Cha.” And it’s about this sort of undercurrent. I didn’t necessarily see it in the presentations, but I got it in speaking to people there. And that is this sort of whispered thing that hey, this DevOps thing isn’t that easy. Right? We thought it was going to be easy.

And you know, my DevOps transformation is not going as planned, and it’s not going as fast as we wanted. And it’s not—there’s a lot of work involved here. And I don’t know what gave people the impression that it’s a hockey stick. You know, it was straight up. Things seldom are. I think DevOps can be lumpy, or DevOps transformations can be lumpy. And it’s a little bit of three steps forward, two steps back, cha cha cha, and so forth. Your opinion?

Radcliffe: Well, I would absolutely agree. I don’t think people understand the cultural challenge to this transformation. Because it really is all about culture. And it’s not just bringing in tools, and a lot of people think, “I’m going to bring this toolchain in and it’ll all be fine.”

And maybe some of the teams that works for. But there are a lot of teams that that’s really just not going to work for. And there’s just no way that we can just have this continue in the environment. We really have to make sure we are understanding that this is culture, and that the culture is really, has to change. And it’s across the entire organization.

I think the other thing people didn’t realize is that it is a … what’s the best way to put it? It’s not just culture and you’re done, or it’s not just do it and you’re done. It really is a continuous improvement process. And we like to talk about the kicks team because they’ve been doing this for 15 years or something, and they know they’re not done.

Shimel: Mm-hmm.

Radcliffe: So it’s not something that ends. You learn your lessons. You get better. And you learn a new lesson, and maybe you didn’t get better. And so you learn the lessons. And it really is this continual improvement. And so it’s not easy. It’s not a piece of cake. But it delivers real value if you move down this pipeline.

Shimel: Yep. I mean, takeaways. Dev ops is never done, right? You’re never done with DevOps. And it’s only a failure if you stop trying, right? Anything else is just feedback loops. [Laughter] Everything else is feedback loops. So I think those are great takeaways from that.

So I went from Gene’s to another event to another event. And we’re rapidly, you know, Rosalind, approaching event season. And, of course, IBM’s big event this year is a little different than years past. It’s called IBM Think, right?

Radcliffe: Yes.

Shimel: It’s in March in Vegas. Can you –

Radcliffe: Yeah. It’s going to be an interesting event. We’re bringing everything together in one. So we used to have in our connect, and Watson’s event, and internet of things. You take your choice of names. Now it’s all one. So we’re going to have one big IBM event for all of our technology, all of our parts of the product. And they’re really trying to bring it in a focused way to make sure it’s a set of customer stories on what they’re doing and how they’re doing things.

Shimel: Do you know the exact dates, perhaps, off your head? Or if not we’ll –

Radcliffe: Yeah. See, it’s March 19th. It’s March 19th. The first day is an inner-circle day. And the next Tuesday, Wednesday and Thursday are the main days for the conference. And so it’s a shorter week this time, not making people come in on a weekend and giving you a chance to get home, which I think is a very good thing. But it’ll be a fully packed set of days.

Shimel: Fantastic. Hopefully we’ll see you out there. I’m not sure about devopsy.kinsta.cloud’s plans yet around it, but we will be making plans, for sure. So Rosalind, you spoke a little bit about Gene Kim’s event. We spoke a little bit about the upcoming IBM Think event. Let’s focus in now on Z systems, enterprise systems. I know you guys are, you released a new generation. What was it, around September or August?

Radcliffe: It announced in July, July 16th or 17th, and became available in September. And yes, the Z14 with the latest announce.

Shimel: Yep. And it’s brought a whole bunch of stuff to the forefront, probably some of the biggest might be around security and encryption from my point—humble point of view—anyway. But you’re excited about some new stuff coming up with the Z systems we were talking. Why don’t you share it with our audience?

Radcliffe: Yeah. I’m really happy. We’ve been doing a lot of work to make the dev ops pipeline work for z/OS software. And a lot of customers are turning to open source. And so they want to use Git. And so I got Rocket to port Git to z/OS, so that’s the first step. And that’s great. That’s been available this year. But we have to have a build system. And so we have made available something called dependency-based build, and it’s in beta, and it will be GA by Think. The idea is you can use Groovy Scripts to write your build definitions for z/OS.

So think about that. It’s not, you know, JCL. It’s not different. I can use Git just like any other language. I can use Groovy just like any other language. I could write my build scripts. And it’s not different. It can make our COBAL and PL/1 in assembler look just like all those other modern, fun languages.

And really they—okay, assembler might be a little hard. But, okay, other than that, COBOL is just English and PL/1 is a pretty good language. So why not? The fact that you have to do things so differently, we want to get rid of all that. And so this new capability, it’s in beta. Anybody’s well—it’s an open beta. Think about this. IBM open beta? Yep. There it is.

Shimel: IBM –

[Crosstalk]

Radcliffe: Go play with –

Shimel: That would be neat. [Laughter] Where can people go play with it? Did you have a URL or section?

Radcliffe: We have a URL. I’ll get it to you so you can post it. It’s not a friendly URL.

Shimel: You know, I can’t help but smile, Rosalind, and think about some of my friends and family who aren’t in the tech industry listening to this, or watching this, and hearing that we’re going to be playing with some Groovy scripts, what’s going through their head. But that is great news. And it’s part of this bigger movement.

You touched on it a little bit. We started at Gene’s event, and it does show. And that is initially with DevOps we’ve been through the binary IT mode, the multi mode, multi speed, binary speed, all this nonsense where let’s treat the mainframe folks as special, and all of that.

But I’m glad to see that—and Rosalind, I think I ran into you at CA World, perhaps, right, where IBM was a major sponsor. And that seems to be the message coming out of the enterprise world now, the mainframe world, which is that’s nonsense, that we’re not going to stand for being labeled special or anything like that. We move as fast as the next guy does, or as fast as the other systems do. We use the same languages in a lot of instances. And we’re even updating the languages that we do use to make them more relevant in today’s world.

So to me that’s a huge message, right? That we need to continue hitting home, though. Because I still hear people talking about multispeed and all of that stuff.

Radcliffe: Yeah. But bimodal is something that needs to go away.

Shimel: Uh –

Radcliffe: It just needs to go away. We’re done with it.

Shimel: Okay.

Radcliffe: The idea that things are going to go at different speeds is true, but it’s not based on platforms. If I build an API, I really hope I do a good job of that API. And it doesn’t matter if it’s running on a system of record or a system of engagement, it’s running in Java, or it’s running in Cobalt. If I write good code, I’m not going to be changing it 1,000 times a day. So the point is if you’re building APIs, you’re going to build them. But you need to be able to change them as fast as possible.

So it doesn’t matter the platform. I should be able to deliver that code today. I need to make a change, let me deliver it. And I really—I guess I want Z to be considered special for its qualities of service, i.e. its reliability, its scalability. Not because it’s different in the way you do work for it. So if it’s just another node in your pipeline, it’s just another node. It just happens to have a different set of qualities of service. And if you build your node, or your Java, whatever, and you end up needing the qualities of service of Z, run it on Z. Why not?

Shimel: Agree.

Radcliffe: And let’s get the differences because you think a system of record has to be slow, or the differences because you think Z has to be slow. I mean, it’s funny to me. We call the mainframe an old system, but really with the Z14 and the LinuxONE announcement, it’s the most modern platform that exists out there. It’s the most modern chip. So how is it old?

Shimel: Yeah. Yeah. I hear ya. A hundred percent agree. Rosalind, you know, we’re almost at the end of our time on this experiment and I do hope the video comes out. But if not, the audio will. And if you’re listening to this without video out there, it’s because the video didn’t work out so good. But at least we’ve got the conversation imparting the references to the video.

Rosalind, we hope to see you soon. Maybe between now and Think we can do something a little more in-depth, a webinar or something about what we’ll see from Enterprise Systems at Think and what else we have coming down the pike as we move closer to Think. And until then, though, have a merry Christmas, happy new year, happy holidays, and thank you for always being available to us here at devopsy.kinsta.cloud.

Radcliffe: Well, thank you. Thank you for your time. And you enjoy the holidays, as well as everyone who is listening if they hear this before the holidays. Merry Christmas.

Shimel: Yes, yes, yes. All right. Rosalind Radcliffe, IBM Enterprise Systems, distinguished engineer, and our guest on our very first video DevOps Chat. I guess they’re not DevOps Chats. All right, Rosalind. Thank you. Have a great day, everyone.

— Alan Shimel

January 26, 2018