devopsy.kinsta.cloud

Category: DevOps Chats

DevOps Chat: Microclimate and IBM Cloud Private with Toby Corbin

IBM Cloud Private has cemented itself in the DevOps space as a personal cloud environment, which is great for developers who need the agility and computing power of the cloud but don’t want to step into a public cloud setting. Tony Corbin, technical lead for the Microclimate Project, describes IBM Cloud Private as “a cloud specifically targeted at individual customer.”

In this DevOps Chat, Corbin and I talk more about IBM Cloud Private and its role in DevOps. As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

Transcript

Alan Shimel: Hey, everyone. It’s Alan Shimel, DevOps Chat, and you’re listening to another DevOps Chat. I happen to be joined today by a first-time guest on a podcast. So this’ll be an experience for him. It’s Mr. Toby Corbin of IBM. Toby, welcome to DevOps Chat.

Toby Corbin: Thanks, Alan. How are you doing?

Shimel: Doing great, and happy to have you on today’s show, Toby. Rather than introduce you to the audience in terms of your title and role and everything, I thought it would be a good icebreaker for you to kind of introduce yourself. So why don’t you kind of share with the audience, if you will, what your title is and what that means and kind of what you do with IBM?

Corbin: Sure. So at the moment I’m Technical Lead for one of the squads in the Microclimate Project. Microclimate is our developing experience, which we’re targeting to help onboard customers and developers into the IBM Cloud Private. So my role and my squad is – we sort of deal with the backbone of Microclimate. So we deal with making sure everything runs smoothly. We add in things like analytics and the sort of analysis application. But we make sure the whole thing sort of runs. So we’re kind of the backbone. So the squad that I lead, we’re the backbone of Microclimate.

Shimel: Excellent. So Toby, this sounds sort of like an Ops role, if you will, right? When we talk about the Microclimate – and you know what? Let’s back up. Some of our audience out here may not even be familiar with IBM’s Cloud Private offering. And I don’t claim to be an expert. I’m going to assume you know much more than I.

Corbin: A little more.

Shimel: Yeah, a little bit. I would hope so, so you’re not collecting your check under false pretenses, correct?

Corbin: [Laughs]. Correct.

Shimel: So Toby, let’s start with that. How would you describe Cloud Private to our audience?

Corbin: So we’ve all heard of public cloud – things like Amazon have a cloud and Google have a cloud and IBM also has their public cloud. And these are quite large deployments. They’re hidden in the ether somewhere, no one knows where they are, and that’s where all the really, really clever analysis goes, and that computing power that IBM can bring. Cloud Private is sort of the onboarding into that. So Cloud Private is a cloud specifically targeted at individual customer. So they won’t be sharing that with anybody else. It will be an instance just for them and they’ll have the very similar applications and things on there that the public cloud would have. The intention being that when our customers are happy using this Cloud Private installation – so they don’t have to have their own machines. They can have the Cloud Private stuff working for them, doing all of their processing. When they’re happy having that working, we can then take them up to the public cloud, where they get even more of IBM’s processing power and they have an even better experience.

So it’s kind of taking them from a private cloud that’s just for them up to the bigger public cloud, where although it’s still for them and they don’t share with other people, they have bigger computing power available to them.

Shimel: Got it. So is it sort of a way station along an upgrade path? Or can someone stay on Private Cloud indefinitely?

Corbin: Oh, you can absolutely stay on Private Cloud. You’re not forced to go up. But obviously as we go up through the clouds, the capabilities IBM can offer you get a lot greater. So that’s why often you’d find that the customers would want to move up to the next level, because there is an even greater amount of processing and a greater amount of options available to them and to their customer deployments.

Shimel: So they grow into it, I guess. So Toby, I was under the impression, and maybe I’m wrong, that in Private Cloud there was also – I thought it was a Kubernetes-based offering. Is that –

Corbin: That is correct, yes. So IBM’s Private Cloud is all based around Kubernetes. It’s IBM’s flavor. So it’s Kubernetes under the covers and IBM have made it sort of into their ICP, their private cloud offering. But it is Kubernetes-based, that’s correct.

Shimel: So it’s containers with Kubernetes and this whole sort of – you know, the _____ _____, obviously, but now we’re starting to see the domination almost of Kubernetes kinds of architectures.

Corbin: Yeah, and that’s how IBM’s helping our customers. So you think of the old way of doing things, you’d have a _____ application that was a huge monolith, a giant application that couldn’t really go anywhere. With IBM’s Private Cloud what we’re looking at is, how can we take these applications, deploy them on the cloud, free up all of the hardware – in a customer’s site they don’t have to worry about those things – and take these large-scale applications and deploy them into a cloud environment? And then it’s not just make them work in a cloud environment. How can we work with customers to actually make them change their applications and sort of rebuild them, if you like? Strip them down, put them back together again, as a microservice opportunity?

And that’s where Microclimate comes in. That’s what we’re doing for the developers. It’s how you create those microservices.

Shimel: Perfect. And of course, Toby – I think a lot of our audiences are familiar with the term “microservices,” and we see microservices being mentioned a lot around Kubernetes, around containers, around DevOps and cloud and so forth. And you anticipated my next question, which was, when we talk about a microclimate, is that sort of the climate in which we do microservices or perform microservices.

Corbin: Yes. Well let’s say for this, yes. Effectively what microclimate is, it’s the environment that we want to give to our developers to go from having absolutely nothing to being able to develop their very first microservice, test it and then deploy it up into production through things like the Jenkins Pipeline and using Travis, and get it running in their cloud, all without actually having to need any prior knowledge. We sort of do this all for you. So in the past there was always ways of being able to create an application and there was always ways of pushing an application into a cloud, but it was several steps, different technologies. You had to rely on the customer having various knowledge themselves. So Microclimate is aimed to make this really seamless. You don’t have to leave your web browser; it’s entirely web-based. But we give you the ways to easily create an application, develop it in the cloud in a web-based editor, test, adding in these performance issues that we’ll talk about in a second, and then when you’re really happy, then get it run in production environments, all with the under-the-covers work being done for you by Microclimates.

Shimel: That’s fantastic. So this whole Microclimate, if you will – excuse me, microenvironment and Microclimate, this is all managed via web browser? All web-based, huh?

Corbin: Exactly. Because this gives you the opportunity that if you are fully running in the cloud, you don’t actually have to have anything on your laptop at all. Everything can be based in your ICP installation. You need nothing on your laptop to run it, which means then you don’t have to have Swift installed or Node installed. But you can still go and create and generate Swift and Node and _____ applications without having anything local to your machine. It frees up your environment to do everything in the cloud, so you’re straightaway using the power of the cloud to do your development.

Shimel: hat’s fantastic. And Toby, it sounds to me, even more than that – you know, so I’m old, right? So I’ve been around for a while. And wen we first saw microservices and containers, to me this was like Heroku – better than Heroku. It was truly moving from infrastructure as a service to platform as a service. So that if you’re a developer and I want to write stuff let’s say in Swift or JS or whatever, I didn’t have to worry about, “Was that installed? What was the infrastructure like? What was going on? Was it installed in the OS level?” I could work directly on my application. Do these sort of Microclimate, microenvironments – is that what this really represents?

Corbin: Absolutely yes. So that’s one of the beauties. Before coming on to work on Microclimate, I was doing Swift developments and Node developments, and I would have to have the latest versions of Swift on my machine and I had to keep up with them to make sure that I would have the latest bug fixes done or whatever it was to make my application run smoothly. With Microclimate, we take care of that whole environment for you. So when you say, “I want to create myself a Swift application,” you get a container running with the latest version of Swift. All of the security patches for that run are already applied. You don’t, as a developer, have to worry about, “Do I have the right installer? Do I have the right version of he compiler?” All taken care of. As a developer you can now just write code and we will do everything else in the background for you, so it really frees up the developer to do their job and not have to worry about keeping their machines up to date with all of the latest patches and run-suns and everything else to do that.

Shimel: That’s pretty nifty. Good stuff right there. So then, Toby, as part of your – you know, you’re a team lead with portal, you had mentioned, and – but you know, but your whole team and what you’re doing – would you say most of the people you’re serving are developers? Or do you kind of correspond with their Ops team, who are still servicing the developers within their organizations?

Corbin: So this is where Microclimate has nicely evolved. We started off s being the developer experience. So we were the developer experience _____. And we were aimed at, how do we nicely onboard the developer from having nothing on their laptop to being able to write their first microservice and deploy it to the cloud? But then we quickly realized that we need to have DevOps. So we brought on a whole DevOps pipeline to the backend of Microclimate. So Microclimate is really _____ _____ as an end-to-end story of two either distinct parts, if you like, but they actually work in one. You start with, “I’m on my laptop, even though I’m running in a cloud environment.” So I’m coding on my laptop and I’m writing my first microservice. And then when I’m happy, I’ll use Microclimate to actually send it to my preconfigured Jenkins Pipeline, and the backend of Microclimate that deals with DevOps will take that and will build you on your Jenkins Pipeline, it will push towards your production and you’ll actually go the full end-to-end now.

So Microclimate is not just really about writing your first piece of code now. It’s taking any application and pushing it right through to deployment at the other end and have it run in production.

Shimel: It’s end-to-end. That’s beautiful, man. That’s really nice. So share with our audience, if you can a little bit, what are the kinds of things that you and your team are actually doing as part of maintaining this environment?

Corbin: So one of the things that we brought – so as I said before, my background in this, I actually came from doing tools monitoring for things like Java and Node. We now bring that to Microclimate. So we can think of things like a performance issue that you would typically see. You know, my CPU is going mad and it’s at 100 percent, or my disk is thrashing or running out of memory. And often it’s very difficult to know why that’s happening or even if it’s supposed to be happening. So what we do, what we bring to Microclimate is, we bring to the table our analysis tooling that we have outside Microclimate. So when you use Microclimate, we actually build in our monitoring stuff. So that means that when you write your very first line of code, we actually start monitoring it straightaway.

So you don’t even have to think about, “Okay, do I have to monitor my application for performance problems?” or, “I’ve got my application written. We normally have a performance team that does this.” We give it all to the developer. Because if a developer can see a problem with a line of code they just put in – for example, they’ve just coded a new function and when they run that function their fan goes mad on their MacBook and it’s thrashing away and they think, “What have I just done?” If we can tell them what they’ve just done at the point they do it, this speeds up development in the future and your testing gets quicker, because you don’t get a performance team two months down the line saying, “Hey, we’ve just run your stuff and it performs like a dog,” and then it comes back to the developer to have to re-find-out what they’ve done. We show you straight away. As you type your code in and hit Run for your first test, we can show you what performance was, so you can see, am I regressing? I can see where my CPU is going mad or I can see where my hard disk is lighting up or I can see where I’m running out of memory.

We build that in for you. So hitting the developer experience right from day one means that hopefully when you get to the end and your application deploys, there’ll be no surprises around, “Well it’s not running anywhere near as well as I thought it would.” So that’s what we bring to Microclimate.

Shimel: Got it. Like you’re the developer’s best friend.

Corbin: We’d like to think so, yes.

Shimel: So Toby, as I mentioned before, I’ve been around the block a little bit. You know, one of the problems with what you’re describing is territorial issues, let’s call them, right? “Hey man, I’m the Ops guy here from my org, and I’ll help my developer, thank you. Don’t be giving away our secrets, telling the developer some of these performance things.” You know, performance kinds of insights. Do you run into having to deal with pre-existing performance teams as part of the Ops at these organizations?

Corbin: Well not so much, because we actually find now is that the sort of dynamic of a team is changing. As we go into this sort of more agile world where each team is intended to be self-directing, we find by having smaller teams with sort of jack of all trades, we get away from this developing, developing, developing, testing, testing, testing situation that we _____ _____ five or ten years ago. And this means that much smaller teams can deliver functionality that’s fit for purpose a lot quicker, because you’re not waiting for a longer test run at the end or other sort of testings that happen that would typically end up in this loop of sort of, “I deliver my code, someone tests it, it comes back to me to make changes, someone tests it and it comes back.” This is a sort of way development has now evolved. So with the agile world, smaller teams can do things a lot faster, and that’s why giving them the tools they need means they can do that.

But this doesn’t mean we put testings out of business, as it were. Because we aim our stuff at the developer, for like the piece of function they’ve just written or for what that application is doing as a whole. There will always be a need for sort of larger-scale teams that need to oversee the entire application. So whereas before, if we take the example of the giant _____ monolith that was one giant application, you might find in today’s environment that that’s actually seven, eight, nine, ten small microservices. So a developer would be working on one microservice and he’d get the performance stats back from that microservice in isolation. But what about the bigger picture? What about when all ten of those are working together? How do you get the overall view of your microservice environment that’s 10, 20, 30 things all talking to each other? So that’s where you still have DevOps teams and other teams working on that. And there’s software for that as well.

So as an example, there’s Prometheus, that’s an open source monitoring solution that’s very good at taking data from different sources. And then what we do with the stuff that we add into the applications at the developer level so that the monitoring solutions we put into Microclimate for the developer, that will actually talk to Prometheus. Which means that if the developer is happy seeing their code running and their single microservice view of the world all looks good – “Yes, my database function is performing as I expect it too.” I’ll now put it into the cloud where there’s 20 other microservices running, all talking. And Prometheus, that sits over and above all of this, can now take the data from each of those 20, and the data they’ll be taking will be the same data that the developer has already been seeing when running it locally or in the small view. We just pass it up through. So this again gives the developer an easy way of seeing – or actually in fact _____ ____, the SysOps guys, what their applications are doing without any additional changes. Because the code has been in there from day one to provide this information.

Now that’s one of the hardest things about monitoring. It’s, how do we get at the data? If you can get at the data, there’s plenty of ways to visualize it. All sorts of fantastic tools, even the simplest of just writing out to the screen. It’s always the case of, how do we get to the information? So we build the information in from day one, and that’s what makes Microclimate so cool, as it were, because it’s just there for you. And no matter what sort of environment you run in, we’ll be able to make the data available to see the performance at any level.

Shimel: You know, Toby, that’s excellent. Hey, when we started – before we started recording I told you, “You’re going to be surprised when I tell you, ‘Hey, we’re going over time.’”

Corbin: [Laughs].

Shimel: So we’re really way over. That was a difficult interview. It was pulling teeth to get you to talk to us.

Corbin: [Laughs]. I’m sorry.

Shimel: No, not a problem. Toby Corbin, IBM’s Microclimate Developer Experience Tribe, thanks for being our guest on DevOps Chat today, and continued success with the Cloud Private team at IBM.

Corbin: Thank you very much for having me on, Alan.

Shimel: My pleasure. This is Alan Shimel. devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat.

— Alan Shimel

November 5, 2018
DevOps Chat: Security in the Cloud with Dome9’s Zolar Alon

Dome9 is in the business of cloud security, so it’s no wonder some of the world’s top companies rely in it to secure their sensitive data and applications in Amazon Web Services, Microsoft Azure and Google Cloud environments. And with last week’s announcement of Check Point’s aquisition of Dome9, an even greater number of users will be able to take advantage of its SaaS solution.

In a recent DevOps Chat, Dome9 co-founder and CEO Zohar Alon spoke with me about what he sees in the cloud security space as many organizations embark on their second generation of public cloud expansion.

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

Transcript

Alan Shimel: Hello, everyone. It’s Alan Shimel, devopsy.kinsta.cloud, Security Boulevard, and we’re here for another DevOps Chat. Today’s DevOps Chat features and old friend of mine from the security world, Zohar Alon, CEO and co-founder of Dome9. Zohar, welcome to DevOps Chat.

Zohar Alon: Alan, great to be here.

Shimel: My pleasure to have you here, my friend. Zohar, let’s get this out of the way first. Some of our listeners are not necessarily from the security world. They’re from the DevOps world. They may not be familiar with Dome9. So let’s first let them know a little bit. You know, you live and breathe it, but tell them who Dome9 is.

Alon: Sure. So Dome9 is a SaaS solution that helps security organizations and some DevOps and development organizations secure their public cloud environments as they grow and prosper from the single cloud to the multi-cloud focusing on AWS, Azure, and Google Cloud platform. A multitude of solutions.

We’ve been in the market from the very beginning covering elements like network security in the cloud which is a bit different, governance and compliance, continuance compliance, and how our customers can tie continuance compliance to their development processes and their build processes and things like identity and access management protection for public cloud that prevent attackers from targeting the developers as the weak link as a vector of attack for compromising the credentials in real time by hacking into their laptops and pigging-backing on their authenticated and trusted sessions to create mayhem and havoc in the public cloud environment of the customer. Just celebrated joining our hundred employee and going strong in both our headquarters in Tel Aviv and Mountain View, California.

Shimel: Absolutely. Very good. So Zohar, and I should mention, look, I know you and Dome9 pretty much from the year you started if not the day you started, right? I think it was an RSA event?

Alon: Yes, yes, 2012, very early on.

Shimel: I was going to say, you know, in a previous – you have a long history in the InfoSec world. Look, the topic for today is really have we seen, you know, the classic, you know, crossing the chasm model of early adopters, early mainstream, late mainstream, laggards, where are we with this in cloud adoption as it relates to cloud security? And at this point are we confident in saying that, look, it’s basically just the laggards at this point who haven’t already at least started their cloud migrations?

Alon: I can say this for certain, that the level – at Dome9 we focus on the top segment of the enterprise customers, let’s say the global 5000 organizations and their cloud deployments; and there’s not a single industry, there’s not a single geography that we are not seeing a race to the cloud, in many cases, multi-cloud deployments very early on. What I’m sensing is that we have a lot of organizations that already completed their kind of version one of public cloud experience that was comprised of some lift and shift and some building of new systems in the cloud. They are now busy architecting their next generation, their second generation of public cloud expansion where elements of making not just the default but actively working to decommission the old infrastructure.

And remember the motivation is you always have a software or a hardware refresh cycle happening somewhere, whether it’s for your switching fabric or for your compute fabric, in your various data centers or you need to upgrade those Windows 2008 and it’s all involves some interesting costs with it. So the drivers are already there. Once you already get the momentum and the velocity and the confidence, it’s something that is inevitable and it actually happens faster and is encouraged by kind of the known technical people, whether it’s the procurement or the finance people that realize that their support to this activity could save the organization actually a lot of money.

We saw that AWS revenue run rate, just AWS is around $40 billion now, and we just saw that the big Cisco revenue run rate is $48 billion. So the reality that we have crossed the chasm and even kind of gotten to the late point. The late majority is already feeling it quite seriously. I can say this for certain with a lot of certainty.

From our perspective at Dome9, we are also seeing organizations already architecting their second generation of what is to deliver continuous security and compliance and governance to their new architectures in the cloud. This is kind of it goes hand in hand. This is where we also see this kind of the maturity in the level of the people that we talk to and their requirements and their understanding that there’s not just a single or few parameters you need to take care of, but if you count them there are about 10 different areas of attention that you need to be very well covered with in order to provide to continue that trend and complete the migrations and sell those data centers as Intuit just did. I think they announced about two months ago that they sold their last data center. I believe we’re going to see a lot more of those announcements. We don’t need to worry. This real estate is not going away. Amazon buys it through Equinox and its partners on the other hand. So it’s not as if we need less compute. We just need a better, more resilient, more focused compute environment.

Shimel: Understood. Couple of things you mentioned in there that I want to bring to up or I’d like to kind of dive a little bit. First of all, yes, I do agree with you, even the late majority has moved to the cloud; but I think one of the things we’ve discovered about cloud migration is no one up and picks their entire – or very few people but some do – up and pick the entire infrastructure en masse over to the cloud, right? It’s a phased sort of migration, if you will. Some faster than others. And I’m talking now for large enterprises. I’m not talking startups. Larger enterprises. How long a migration do you think that usually is?

Alon: Look, so the key is the data. You know, when Amazon announced their Snowball device to lift and shift a couple of petabytes, I think it was three, four years ago at Korean event, people were in shock and like about the thinking of getting the data to AWS is, you know, FedEx is faster than the largest wipe you can find. And then they surprise last year with the full-blown semitrailer that has essentially storage on it that can take essentially any amount of data from your premises to the public cloud. So this is one thing.

Once you get the sense of trust with some data, then trusting the public cloud with your entire dataset is not something that is inconceivable, right? Trust is very binary. If you have it and if it’s good for the backend of my mobile application with the replication of a lot of my banking stuff, for example, then it’s good for everything. Then it’s just the technicalities on how we get there.

Now, I think one example I want to give is that other than data that can there are no barriers, sometimes the database can be a barrier and that’s why you’d see solutions like AWS will sell you migration services to move from your own – they’ll practically give it to you to move from your Oracle to their cloud-based RDS system whether it’s Aurora or whether it’s any of the other SQL versions that they offer as a service. You can say that probably what’s left is the big old mainframes.

I was fortunate enough to see that in real time about a year ago where Vanguard – so essentially after we figured out how to migrate data and databases, the only thing you might say may prohibit us from flying at speeds to the cloud may be an old system of record that sits tucked in in a mainframe computers in some data center at an unknown location. We have been able to see, to experience, and to help also several financial institutions in the process of securing a lot of replication process where they showed how they create using serverless computing and the AWS DynamoDB, a replica of their system of record of their big old mainframe, in the public cloud to provide essentially zero latency backend to their entire application framework. And I’m certain that one of the examples is Vanguard. There’s a very famous video of their heard of architecture describing how they used I think seven steps to create that replica of their mainframe.

It’s an amazing—and this was announced, this was shown a year ago, so you’d probably think that they’ve been working on it for two years before, and this is the reality, that when it started making sense, you know, the technological barriers to live in tandem until you are forced to make a decision about those old systems or those legacy systems is something that any organization should strive for.

And, you know, you don’t need to work hard, you know? Just, your public cloud rep, whether you go with Google Cloud or Azure or AWS, they will help you with providing the perfect architecture and how you’re baking security into it and how you optimize it for cost—they will pull in the partners that will help you on those things to kind of tie them across the board. And the reality is that—and that’s why I can say that, unless there is real slowness and some legislative or some other reason that could prevent an organization from starting its exploration, most of them are already picking it.

And sometimes it’s not advertised. I’m surprised to see, you know, industrial companies that come to us and, you know, I ask them how much is their public cloud spend, and they say, “We just crossed the $10 million-a-year mark.” And that’s a serious business. That means that the current way that things are going, they’re gonna get to ($50 million) or to ($100 million) in the next two years. And this means that you’re not investing in your on-prem systems any more. That’s what I’m seeing in the market.

Shimel: You know, I’m not gonna argue with what you’re seeing. You’re out there talking to people doing it. Zohar, unfortunately, we’re way past our time, but you know what, I’d love to have you back on. I know we had a little bit of a technical glitch; hopefully, it’ll be ironed out where people are listening to.

But let’s continue this discussion. I think it’s fascinating stuff, and I think people are interested to know. And we didn’t even—I really wanted to touch on what does this mean for cloud security? What does it mean for DevSecOps? Let’s do that in part two, if it’s okay with you.

Alon: Absolutely. Looking forward.

Shimel: Okay. Zohar Alon, Founder and CEO of Dome9—thanks for being our guest on DevOps Chat. This is Alan Shimel. You’ve just listened to another DevOps Chat.

— Alan Shimel

October 29, 2018
DevOps Chat: The State of Software Security with Veracode’s Chris Eng

Every year CA Veracode publishes its “State of Software Security” report, chock full of research about how well software is being secured during development and beyond. It’s eye-opening stuff and definitely worth a read for anyone even remotely interested in helping make software more secure.

In this DevOps Chat, Chris Eng, VP of research at Veracode, recently discussed with me this year’s report findings and some takeaways that are worthy of noting.

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

Transcript

Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Joining us on this episode of DevOps Chat is Chris Eng of Veracode. Now I’m proud to say, actually, that I know Chris, actually, before there even was a Veracode. But – so it goes back a while. Chris, I don’t remember your exact title, but don’t you head up research at Veracode?

Chris Eng: That’s right, yeah. VP of research at Veracode.

Shimel: Yep. Welcome and good to have you back on, Chris.

Eng: Good to be here.

Shimel: Yep. So, Chris, you know, I’m gonna assume, if people wanna know who you are, it’s Chris Eng – E-N-G. You could look him up. He’s a bonafide cybersecurity warrior, with a long track record of accolades and just being a great guy in the community. On top of that, though, I’m gonna assume people know that Veracode, for the last couple years, has been putting out a report called “The State of Software Security.” In fact, this is volume nine, so which assumes there was eight before then, right, Chris?

Eng: That is correct. [Chuckles] We do this every year and it gets bigger and better every year.

Shimel: Yep. So volume nine, you know, it’s CA Technologies Veracode now, of course. Some changes. And, Chris, it’s kind of your baby, right? You shepherd this report every year, no?

Eng: I’ve been involved in it since the first year we did it. I mean, certainly, going back to the early years, there were a lot fewer of us sharing the burden and doing all of the writing ourselves. And now, thankfully, we can spread that out among more people and get more eyes on it. And that’s actually one of the things that we did this year that was kinda different, is, in addition to ourselves, we worked with some data scientists, over at Cyentia Institute, to actually help us dig into some of the things we really wanted to probe, around remediation work and looking at different organization behaviors. And I’ll get into that in a little bit.

Shimel: Absolutely. Chris, before we dive into maybe the specifics of this year, let’s just take a minute and talk about, look, nine years running, my god, how the world has changed in nine years. Right? I was talking to the CIO of Box, Paul Chapman, earlier today, and we were just talking about how the world’s changed, let’s say, in the last 20 years but even in the last 9 years. I mean, what we can – you know, security’s still security, and, unfortunately, we still have incidents; we still have vulnerable software; we still have buggy and have trouble closing up vulnerabilities. But the game has changed, though, too, has it, Chris? When you look back, what do you think that some of the biggest changes are?

Eng: Yeah, it’s definitely undergone a huge evolution. When we started Veracode in 2006, application testing primarily was companies doing penetration tests, maybe once a year, against their most critical applications. And, if anything changed between those, you know, in that one year, you kinda only had a point-in-time assessment. You had a lot of applications, a lot of pieces of software, that were just never being tested at all. And, since then, companies have realized that, number one, they need to test more frequently. That’s the only way that they’re able to release software that is going to be secure and also be able to drive the speed that they want to release new features and new products. Right?

The other, I think, realization is that you can’t just focus on the most critical applications to the business because attackers don’t really care how they get in, right? If they find a weaker way to – an easier way to get in, through some weaker application that’s not maybe core to the business but is still connected to the same infrastructure, well, they’re gonna go after that. So there’s been a realization that it’s important to understand everything that you have and to actually build software testing and security testing into all stages of the life cycle, right? Fix early and it’ll be a lot cheaper than fixing later on.

And, you know, we were looking at some of our stats the other day – this isn’t in the report, but to do the first million application scan for our customers took 10 years; the second million scans took one year.

Shimel: Wow.

Eng: Right? So that huge rate of increase is just showing that, across the board, across all industries, company sizes, organizations are realizing that they have to scale their software security programs to cover all the bases. And they have to do it continuously, in order to not rack up security debt. So I think that would be the biggest thing that’s changed in how we approach the problem.

Shimel: I agree. I agree. But, Chris, really, our time’s limited. Let’s jump into this year’s report. I’ve had a quick look through it, the executive summary and some of the other stuff. Boil it down for our listeners. What do you think are the three biggest kinda metrics or facts that jump out here, that they should be aware of?

Eng: Yeah. Let me give you just a quick –

Shimel: Sure.

Eng: – review on – so, like I said, we do this every year. And we take about 12 months of data, so this is across all of the assessments that we do for all of our customers, and it’s anonymized down, of course, and then we look at trends and try and see what’s going on out there, in terms of application security. This data set is about 700,000 application assessments during a 12-month period, and the one big thing that we’ve been able to do this time that we weren’t able to do in the past is actually look at how long flaws are sticking around once they’re discovered. Right? How long is it taking organizations to fix these flaws?

And so, when we detect something, we’re able to kinda track it across multiple assessments, so let’s say we scan an application today, we find a bunch of flaws, we fix some of them and not others, and then we scan it again in a week. We’re able to identify that certain of those flaws, the ones that we detect the second time, are the same as they were the first time. And so that allows us to actually track the life cycle of each individual flaw until it’s fixed, right? And so we’re able to look at “What does that flaw persistence look like?” Kind of a survivability analysis.

And, if you look overall, just across all the flaws that we look at, the numbers are not great. It takes 21 days on average to close 25 percent of the findings, 121 days to get to the halfway point, and 472 days to get to the 75 percent point. So that’s a long time, right? That’s over a year, so it’s not a very rosy picture overall. And so we broke this down and, you know, once the report is out, people can kind of look at “What does that look like in terms of different severities, different industries? What kind of patterns do we see there?” But I think the most interesting one, and the one that’ll be most interesting to you, is around the effect of DevOps or DevSecOps on fix velocity.

Now we don’t have an easy way of saying, for any given application, “Is this a DevOps shop or not?” Right? We can’t – we don’t have that information, so we have to figure out whether or not we think they are, and the proxy that we’ve been using for that is scan frequency, right? If you’re doing CI/CD, you’ve got your scanning baked into your build process or you’ve got it, some way, baked into your automation. And so, if you’re doing a nightly build, for example, you’re doing a test every night. And so we looked at scan frequency to identify that – you know, we think that probably these applications that are being scanned 300-plus times a year, those are probably DevOps shops, right? And the ones that are scanning one to three times a year, probably not.

And so we’ve got this broken down into buckets. If you have this in front of you, you wanna jump over to page 39 – it’s Figure 43 – and this is what I really want to – this is sort of a – our hypothesis was like, “Yeah, I bet DevOps shops fix faster because they’re scanning more frequently and they don’t wanna rack up as much security debt.” And, in fact, it does show that. Right? We see this one line on the report that says, “Applications that are scanned 300 or more times a year are fixing – they’re getting to the halfway point of fixing in five days and they’re closing 75 percent of flaws within seven days.” Right? So that’s a huge amount better than those averages that I just described to you.

And we have this broken down by bucket, right? So you have the 300-plus scans per year, you have 51 to 299, all the way down to one to three scans per year, where it takes close to four years for them to get to the 75 percent close mark. So I think that’s actually – this is what we hoped to see. This is what we expected to see. But it’s nice to see the data prove out that, in fact, yes, when you scan often, when you scan early and you stay on top of the findings, this is actually a very doable thing, right? To fix flaws in a reasonable time frame.

Shimel: Absolutely. Two things there, Chris. No. 1, I would think hand in hand with the DevOps is automation.

Eng: Yeah.

Shimel: Right? I’m wondering if part of it is that, in DevOps-enabled cultures and organizations, organizational cultures, whatever – companies doing DevOps – are they automating the scan process and that’s why we’re seeing them doing 300-plus scans? Right? And then they’re deploying more and, if their MO, if their standard process is “Nothing gets deployed without first being scanned,” right, that’s where you start racking up 300-plus scans. Right? I mean, when you –

Eng: Oh, yeah. Yeah, we’re –

Shimel: – build that into your pipeline, right, you build that into your CD process, those scans get done.

Eng: Yeah, we’re assuming that these – you know, we’ve gotten – I think, at the maximum point, there’s one app that was scanned over 1,000 times and, certainly, that’s – I mean, I really hope that’s not a human uploading something or pressing –

[Crosstalk]

Shimel: Right, _____ – hitting the “Scan” button –

Eng: – a button every time, right?

Shimel: – every time. You would hope not, right?

Eng: Right. Right. I’m assuming that even the ones that are scanned 50 times a year, right, which I assume to be every week, I assume that those are also –

[Crosstalk]

Shimel: Are still better than once _____ –

Eng: – _____ _____ through a build pipeline. Right? And, any time you can – I mean, and that’s been a big focus for us, just in general, is “How do we remove any human effort required to do the testing? How do you make it easier and more transparent and just remove any barriers to doing that?” And so –

Shimel: No, heck, how do you – you gotta build it into your CI/CD pipeline. I mean, it has to be part of that. The same way you breathe air, right? If you stop breathing, you die; you don’t deploy software that’s not been tested and scanned. And –

Eng: Right. Right.

Shimel: You know, it sounds so simple, us talking about it, Chris, but here’s the fact, right? And not everyone listening to this in our audience has been in security as long as you have or even I have. And a lot of people see the reports, Chris, and they say, “Oh, my God, this is year nine,” and I forgot how many years Verizon is doing their report, and, every year, it’s hard to show progress in some things, right? We do show “Hey, if you scan more, you’re gonna have less vulnerabilities go out the door that aren’t fixed and that were at least – they don’t stay – you know, they get fixed faster.”

Eng: Yeah.

Shimel: But the fact is we’re still seeing – you look at the executive summary here, Chris, and it’s not a rosy picture, as you – I think those were your own words. And we still read about breaches every day and 30 million records here and 20 million here. You know, the non-security person says, “What are we gonna do? When does this fundamentally change?”

Eng: Yeah, I mean, things don’t get solved overnight, right? I mean, if companies have only realized a few years ago that they need to kinda get a handle on all the things that they have and start understanding what their risk posture is, and they’ve got 10, 20, 25 years’ worth of software, thousands of applications, it doesn’t happen overnight; it’s baby steps. Certainly, starting any new greenfield projects with a proper SDLC that’s identifying and fixing issues early is gonna prevent them from building up even more security debt.

But, yeah, a lot of these – the way I explain some of these things – for example, pass rates on OWASP Top 10 not getting a lot better or the prevalence of certain flaw categories, like cross-site scripting and SQL injection, staying relatively constant – is that some of the more mature apps that have been scanned for a while now, those are actually decreasing. If we sliced those separately, we would see the rate going down. But, when we look at it in aggregate, out of those 700,000 applications that are part of this data set, a lot of those are things that are just being scanned for the very first time ever. And so they’re gonna have a higher prevalence of some of these issues, that the more mature applications will have gotten rid of already. Right? And so they kind of balance each other out.

And we see this every time. In fact, we should probably start to report on some of those things separately – it’s kind of a difficult thing to do – but I think what’s happening is some of the newer applications are bringing those numbers up and that’s why we see the lines staying relatively flat. There’s a long way to go, but we do see – you know, and things like the DevOps remediation case I just described. I mean, we see little points of optimism, where you can see a clear correlation between a certain behavior and a certain outcome. And so we like to focus on those things, and, yeah, it’s gonna take a while for most companies to really start to chip away at the legacy applications and getting those locked down.

Shimel: Absolutely. Absolutely. Chris, we’re just about out of time. I should – we should put this out there: for people who are interested in really kinda digging in on the report, where can they get it from? Go to Veracode.com?

Eng: It’ll be on Veracode.com, starting on October 24th, and, yeah, they can download it there. There’s a huge amount in here. We break it down into different flaw categories. We look at different industries against each other. There’s even a little geographic breakdown and then, of course, like I mentioned, a huge amount of data around flaw persistence and how long it takes organizations to fix flaws, which, I mean, ultimately, is what’s important, right? Doesn’t matter how often you scan if you don’t fix stuff. Right? You don’t reduce your risk unless you fix stuff. So there’s a lot of great data on that, that we’ve never been able to report out before, so we’re really happy to get those out there.

Shimel: Absolutely. Well, Chris, you know what? I know I got a little hard on you about the – and it’s not your fault that the security industry – and it’s not the security industry ’cause, God knows, we wanna fix the issues and the problems that cause these breaches and things; it’s really just the state of software and where security lies as a priority in a lot of these organizations and managing their risk and so forth.

But, by the same token, Chris, you know what? First of all, thank you, thank you, thank you, for being involved enough to do this report every year, and, whether the metrics paint a rosy picture or a sad picture, nevertheless, it’s a picture that needs to be told, right? We need this kind of insight; we need the metrics to understand where we are and where we need to be. And so great job, once again, in putting this together. You know, I think it’s as important for non-security people to read these reports as it is for security people. Right? To really –

Eng: Yeah, we hope –

Shimel: To –

Eng: Yeah, we definitely hope people will get something out of it and, hopefully, kind of use that to think about how they are building their own programs, right – how they’re remediating, what do their numbers look like – and, hopefully, kind of informs how different organizations think about scaling up their programs. That’s what we’re hoping, anyway.

Shimel: Good. All right. Chris, let’s call it a wrap on this; it’s a Friday afternoon here. And, again, thanks for your insight on the report. Thanks for managing this report year in, year out and being involved with it and helping. And we’ll see you soon. We’re coming into conference season; I’m sure you’ll be busy presenting and getting more –

Eng: I’m sure, yeah. I’m sure we’ll be bumping into each other pretty soon.

Shimel: Absolutely. Chris Eng, VP of research at CA Technologies Veracode, our guest on this episode of DevOps Chat. This is Alan Shimel, everyone. Have a great day.

— Alan Shimel

October 24, 2018
Unlocking the Power of AIOps

AIOps is becoming quite the hot topic lately. It seems as though everyone is realizing that Ops is difficult. As we have to deal with more big data at greater velocity with more automation and complexity, there is no way humans alone can tame the beast. AIOps seems to be the answer.

I recently sat down with Dave Link, CEO and founder of ScienceLogic to discuss how to unlock the power of AIOps to empower IT ops. We video taped the conversation, along with some accompanying slides that help explain what the challenges are that ops faces and what are some of the ways to tackle this using AIOps.

I should mention that Dave and I are old friends, having worked together 20-plus years ago at a dotcom era company called Interliant. Since 2003 or so I have watched Dave build ScienceLogic into the powerhouse it is today. I couldn’t be more happy and proud of him.

ScienceLogic has been named by EMA as a top vendor in the AI/ML for IT Operations. Dave gives us a good background on ScienceLogic as well as a good background on the use cases and challenges that IT Ops faces that AIOps seems to be the answer for.

Dave also talks about the differences between AI and machine learning or ML. This seems to be an area of confusion today as well.

The video is about 30 minutes and excuse Dave and I reminiscing, but there is some really great information here.

Video on AIOps

— Alan Shimel

October 22, 2018
DevOps Chat: CHAOSSEARCH New Spin on Big Data Analysis

Analysis is the dark cloud overhanging big data — it’s difficult without the right tools. Elasticsearch by Elastic has become ubiquitous in helping organizations, but it can get unwieldy, as storage combining with compute is tricky. CHAOSSEARCH is an early stage startup designed to make searching massive amounts of data using elasticsearch and Amazon S3 easy.

Pete Cheslock, VP of Products at CHAOSSEARCH and a good friend of devopsy.kinsta.cloud, joined me in this DevOps Chat to discuss his latest company’s technology and how it might make big data searches less daunting. The key for big data search and analysis is separating storage from compute, using Amazon S3 and Elasticsearch.

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

Audio

Transcript

Alan Shimel: Hey everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat features a returning guest to DevOps Chat. He’s actually probably been on DevOps Chat a number of times, right from I think the very beginning of when we first launched devopsy.kinsta.cloud. He’s pretty well-known in the DevOp community and really needs no introduction from me. It’s Mr. Pete Cheslock. Pete, welcome to DevOps Chat.

Pete Cheslock: Hey, thanks a lot. Thanks for having me.

Shimel: Yep. Pete, always a pleasure to have you, man. You know, I remember speaking with you – actually it was probably before I even launched devopsy.kinsta.cloud, up in Boston. And you kind of gave me your views on what was then a very kind of just starting to blossom DevOps community and DevOps movement. And since that time obviously a lot of water under the bridge and many different hats that you’ve worn, Pete. Here to introduce today though with your latest position in helping a company grow, and that company is called CHAOSSEARCH, correct?

Cheslock: Yeah, that’s correct.

Shimel: And Pete, you’re VP of Products?

Cheslock: Yeah, yeah, VP Products, Products, VP of Products? I don’t know, it’s a working title. We’re still trying to figure out what the best way to –

Shimel: As long as they don’t call you a DevOps engineer, it’s all good. [Laughs]

Cheslock: Exactly.

Shimel: I hear ya. So Pete, well let’s start off with this. I’m going to assume a lot of people listening to this today don’t really know or are not familiar with CHAOSSEARCH, so why don’t we start with that? What’s CHAOSSEARCH?

Cheslock: Yeah, absolutely. And yeah, I think that’s definitely a good assumption. You know, we’re an early-stage startup. We’re just going through seed funding right now, so we’re just going through an A round of fundraising, so then we’re going to be coming out to the market in a few months here. But basically what CHAOSSEARCH is is they’re trying to make it easier to access and make query-able your data as it exists on object stores. So if you think of an object store like Amazon’s S3 service. And so they developed basically a technology that allows you to store data. They basically process your data from S3 and store it back into your bucket. So what’s really interesting is they don’t hold any of your date. They’re simply – you know, you give them like a read-only to your S3 data. They’ll read in that data and shove the compressed, processed data back into your bucket. And then from there they expose APIs to allow you to access it.

So for example, they’ll extend the S3 API to give you some really interesting capabilities of slicing and dicing your data. But the thing that they’ve exposed that’s most interesting, which got me excited about the company, is that they’ve exposed the elasticsearch APIs on top of your data on S3. And so it’s really compelling, because I spent a very long time as a really early user of elasticsearch, and it’s a great technology; it’s a great open source database. But it gets unwieldy over time. And so what really blew me away when I saw the product and what they’d built is that I can point open source log tools like Kibana to the CHAOSSEARCH APIs, accessing my own data on S3. No elasticsearch required. And so the kind of short pitch, we’re trying to make that long tail of data available to people, whether it’s log data or event data of some kind, where customers can run much smaller elasticsearch clusters of their log data or event data, and then they can essentially push the data up to S3. We’ll process it, and now they can get access to that data for weeks, months or even years.

Shimel: Yeah. And Pete, that really highlights sort of a soft-white underbelly or a dark corner around the whole big data issue. It’s great to have – I mean, big data and – big data is only as good as the analysis we can do with it, right? That we can perform on it. And with big data we could certainly get some really keen insights to show us relationships, trends, facts that we might otherwise miss. But the dirty little secret was, for big data, to really get the value out of it, generally you needed big money kind of search to perform that kind of analysis. Because the bigger your data got, the harder it was to actually manage it, search it, analyze it. And so CHAOSSEARCH seems like a real solution for those people who are literally drowning in data.

Cheslock: You’re exactly right. I worked at a company eight or nine years ago called Sonian, which – not a lot of people have heard of Sonian. They were one of the earliest users of Amazon’s S3 and EBS. At the time we were probably the top-three user of S3 and maybe the top-five user of EBS. What’s amazing about Sonian is the number of companies that actually came out of that place. Companies like CloudHealth, which just got acquired by VMware. Sensu was a technology that was built inside of there. Stackdriver was another one. And the reason all these startups came out of Sonian is because they were so early in the cloud space, they had to build out the technology to support it.

One of the other ones that kind of came out on the side, not really related to us, was elasticsearch. We were trying to index customer e-mail data, like an e-mail archiving product. And so we got connected with Shay from elasticsearch before he really started the company because we were so blown away by what he had built. And elasticsearch at the time made sense, right? Using Lucene to store indexes of customer e-mail data allowed the indexes to be much smaller than the sourced e-mail files. But then over time, over the last say eight years or so, elastic’s been around, there’s been this explosion of using elasticsearch for log data. And in many cases, like structured JSON that we’re shoving into elasticsearch. And due to the inverted index nature of Lucene, the data blow up inside of Lucene where you might actually store four or five times more in disc storage on elasticsearch.

So if you shove in a terabyte of JSON logs into your elasticsearch cluster, that could be three or four terabytes of Lucene indexes. And then you have to think about like, “Well, I want durability and reliability, so now I need to like run a replicant index.” So now you’re talking for every terabyte into elasticsearch you need like eight terabytes of physical disk. What was really amazing about what the founders and the early team here has created is the format, kind of solving for the Lucene problem. They’ve actually been able to reduce the size, yet still making the data query-able, using kind of the same APIs, which is what really blew me away, in that it’s now – you know, so many people have to make the choice. Do I keep my data for analysis, at a really high price of elasticsearch? Or, do I throw it away? And I think a lot of people just throw that data away, because they just can’t make it worthwhile in any sort of cost effective way.

Shimel: Right, not in an economic way. Pete, we’re far from a big data solution here at MediaOps, between our seven or eight websites, but I will tell you, just pure search, like an index search on devopsy.kinsta.cloud has become a struggle. Because a lot of the native WordPress search – you know, especially if it’s on server, is killing resources on your web server and so forth. So you want to do it sort of off-server search and it’s just a pain in the butt. Take my word for it. So this is great. You said the company’s launching in a few months though? Not that it’s launching – it’s looking for seed money now. Product will be in market. Where exactly is it now in terms of – is it in beta? Is it alpha?

Cheslock: So yeah, we’re probably going to be closing our A fundraising round over the next 30 days or something like that. The company actually started about two and a half years ago, and so they’ve been essentially building this technology out over the past couple of years and really trying to refine it as they were kind of were coming up with this like product market fit. Like what’s the market we’re going into? And as the founders really looked at the space, they realized that log and event management is where a lot of pain is right now. What’s interesting is when people start using the product, they realize that they can process any kind of data with this and query it. And that’s where there’s a lot of interest, where maybe it’s not just log and event data. Maybe it’s like some long tail of data that you want to get access to or to monetize for your customers.

But where we’re at right now, and what was exciting about me coming onboard is not only did my role change completely – I used to run Technical Operations for Threat Stack, which is a pretty successful cloud security company that’s still just crushing it. I changed my role over to become the Head of Product. So working with customers to understand their use cases and how they’re using tools like elasticsearch. So where we’re at right now is I’m basically looking for what we’re calling design partners, where – the best way to describe the product is in that beta phase, where we’re looking for people with really interesting datasets and maybe people who are on Amazon and have data on S3 or are using elasticsearch, and getting them into our proof of concept setup right now, where we can have them run queries, test the analysis, test how they might use it and really help us refine the final bits as we kind of _____ things up towards GA.

And then, once we go to GA, towards – I would say October timeframe I think is what we’re aiming for, it’s really to continue to refine these really specific use cases like, “I’ve got data on S3 and I want to process this data.” We’ve had some customers that want to push their elasticsearch indices up through the service, which is a really interesting idea, because those loosing indexes already have a defined schema. And so that way, instead of storing seven days of data in elasticsearch, maybe they just store one day and that’s in their hot cluster in elasticsearch on EC2 or something. And then days two through 365 are up on S3 and are available through the CHAOSSEARCH service. So yeah, that’s kind of what the next month or two looks like for me. You know, really trying to work with customers, people with interesting datasets. You know, people who have just way too much elasticsearch and they want less of it. You know, they want to kind of run less servers, spend less money – which I feel like is kind of everyone out there right now.

Shimel: Excellent. Very cool stuff. I mean, Pete, look, for you to get up and leave Threat Stack and come over here, obviously it had to be something really appealing and compelling, to bring you over there. Pete, it’s interesting. My background prior to devopsy.kinsta.cloud was founding and building companies, and one of the things I learned is it’s great to have these grand – come up with the idea of Docker for containers and change the way – you know, the basic platform that we use, right? For our apps and for IT. But those revolutionary kinds of things are really kind of few and far between, especially the ones that succeed. Really IT moves along in evolutionary kind of ways, where it’s a thing like this. It’s thing like with CHAOSSEARCH is doing, that makes it easier, better, faster, more economical to really get a hold of your big data and do the analysis and get a handle on it that you need to make it valuable. Right?

Cheslock: Yeah. Exactly right.

Shimel: And so, you know, this just feels that way to me – that this is a lot – some people may say, “Well, it’s not earthshattering.” But no, but it’s the logical step. It’s the glue that you need to – you know, big data is a big concept and it’s great and it’s going to revolutionize things when we get it. But you need the CHAOSSEARCH or sort of the glue to make these things happen, right?

Cheslock: Yeah, what’s amazing is, as I’ve talked to people running a lot of elasticsearch, a lot of data on S3, it’s a really easy sell, because I can go to them and get them away from running these huge clusters that – they may not even take a lot of queries too. That’s what’s interesting is maybe they’re only querying their data in an automated way the last hour or 24 hours. But then you start looking out seven days, a few weeks, maybe a few months; those queries are significantly less. And so you have to either build out like a tiered storage. But at the end of the day the storage and computer are coupled so tightly that your scalable units on Amazon or any cloud provider is a lot of disk and a lot of CPA all together. And what CHAOSSEARCH has done, it uncoupled storage and compute, where the storage is on S3, specifically your S3 account, and the compute is the CHAOSSEARCH service.

And so it’s a totally different way of thinking about, “How do I access my data? How do I make it query-able?” And now, because it costs so little – and we’re talking like go-to-market pricing a tenth of the price of running elasticsearch yourselves, and significantly less than a lot of the other kind of hosted management, log manager vendors. You know, it’s like now I can keep my data for month and a year and I can run machine learning models cost-effectively, because I can keep so much data. That’s the part that’s super interesting, is, how does this change data science and those companies that really want to have the long tail of data for ML/AI testing, and how does this change how they work their models, how they build it in? And we’re even trying to build in like tenser-flow integration into the application so that you can just access it from within without needing to have all this crazy data science experience.

Shimel: Excellent. It really is. Pete, you know, 15 minutes goes quick. We’re coming up on our thing here. You’re VP of Product. Where do you see this going six months, a year, two years out? It’s a long way to look, but where do you see yourself taking the product direction here?

Cheslock: Yeah, no, I always like to joke that the next six months are clear and in focus. Things get really fuzzy really quick after that. But the nice thing is I think we have a pretty clear plan going out of it. Through the end of the year, reaching GA, bringing some customers onboard that we can solve a problem for them. But really, early next year we’re going to start beta-ing a self-service kind of model, where people can come in and try it out. And probably doing even a freemium model, because since the data is in your S3 bucket and we’re just processing that data, cost is very low. So being able to provide someone a couple of gigs a day of data processing, it’s pretty easy for us. And then that way people can kind of get their feet wet and try it out and we can really start building a community around it.

And then from there, I think the sky’s the limit. You know, we’re looking at some time end of next year, the ability to run it within your own data centers. Right now we want to be kind of pure SaaS so that we can continue and build it out and improve it in our kind of very quick, iterative development cycle. But really it’s a data platform we’re building. I mean, we’re going after that log and event management space because it’s so painful for so many people and it costs a lot of money. But the long-term for us is, what other APIs could we expose on top of your data on S3? Elasticsearch seemed to make a lot of sense, given the market. We’ve extended S3 with some interesting features. But like what else is there? What are different ways people are trying to access different data? And so I think that will be a lot of fun to kind of chat with people, understand their pain and maybe actually bring them a nice solution to that pain.

Shimel: Yeah, absolutely. And I’m sure you’ll have a ball doing it, Pete. Anyway, we’re over time here. Pete Cheslock, newly minted VP Products, CHAOSSEARCH. Thanks for joining us on this episode of DevOps Chat, and we look forward to hearing more about CHAOSSEARCH and about your adventures, Pete.

Cheslock: Yeah, thanks a lot. Thanks for having me. This was a lot of fun.

Shimel: Always a pleasure. Pete Cheslock, CHAOSSEARCH. This is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat.

— Alan Shimel

October 19, 2018
DevOps Chat: disrupt:Ops Brings Security Closer to DevOps

Shifting security left during the software development process can be tough for companies because of the sheer number of operational things that go along with implementing security that must occur somehow in the realm of DevOps. It can be easy to lose control over their security processes without some sort of guardrails in place to help.

A brand new company is helping do just that. I’m excited to introduce disrupt:Ops, which bills itself as a guardrails platform to help companies include and enforce best practices across security and operations, bringing security into the DevOps process at the beginning. My friend Mike Rothman, disrupt:Ops co-founder and president, joins me in this DevOps Chat to discuss the vision of his company and how it hopes to help make security truly a part of DevOps.

You can read more about disrupt:Ops and their guardrail approach to cloud security and devsecops from another co-founder of the company, my friend Rich Mogull at https://devopsy.kinsta.cloud/building-great-cloud-security-guardrails

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

Audio

Transcript

Alan Shimel: Hey everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Breaking some big news today on DevOps Chat, the launch of a labor of love of some friends of mine. I’m happy to be joined by Mike Rothman, cofounder and president of disrupt:Ops. Mike, welcome.

Mike Rothman: Alan, it’s great to be here, thanks. It’s always fun to catch up with old friends.

Shimel: Yep, and old friends it is, Mike. We should let our audience know – maybe we shouldn’t let them know. But we are old friends. We go back a long time now, back to the beginning of blogging and security –

Rothman: That’s right.

Shimel: It’s got to be 2004, 2003 or something like that.

Rothman: Yeah, that’s right, that’s right. When I had dark hair. Actually I didn’t have dark hair back then, but you know, it’s –

Shimel: I had hair.

Rothman: You had hair. That’s right.

Shimel: I had hair. But you know what, Mike? I said it was a labor of love and everything else. Just in the way of background, why don’t you share with our audience your personal sort of journey in tech and, you know, work history.

Rothman: Well sure. I started out, God, in what feels like 100 years ago, as a mainframe programmer. Ended up doing some local area networking stuff. Kind of found my way to network security. Went into research for quite a while. Did a couple of companies and then went back to research and for the last 10 or 11 years at this point I’ve been partnered up with Rich Mogull and Adrian Lane at Securosis, doing a bunch of kind of information, security-centric research. And actually about a year and a half ago we spun out some technology that we had prototyped within Securosis in cloud management and cloud automation into our new company disrupt:Ops, and have been just making a lot of progress over the last year with that. And that’s what we’re announcing this week.

Shimel: Yep. So Mike, you’re being humble. When you say you did research, you were an analyst at Giga, were you not?

Rothman: META Group, yes. META Group, exactly.

Shimel: META Group. And then you were also – you had executive positions in several cyber – we didn’t call it cyber – infosec companies back then.

Rothman: It was. Yeah, you bet. So companies like TrueSecure and CypherTrust, you know, back early in the e-mail security days. I did a network monitoring company called EIQ. So yeah, I’ve been there, done that. Have the road rash and kind of the screw-ups under my belt to prove it. But you know, it’s interesting in terms of just how long and how small an industry security is for being actually a really big thing nowadays.

Shimel: Being so big, yeah. It really is. And Mike, again, for many people in our audience who come from DevOps or even from security – but they’re worldwide and they not be familiar with Securosis. You know, Rich Mogull comes over from Gartner. Adrian’s been CTO at major companies. You know, you guys are probably the leading, let’s call it independent security analyst research firm – you said 10 years-plus. Certainly in my time you guys laid the fundamental kind of – a lot of the fundamental backbone of what Cloud Security Alliance teaches and so forth.

Rothman: Yeah, that’s exactly right. So it was interesting. So I guess it was probably eight and a half years ago we partnered up with the Cloud Security Alliance and helped them build their curriculum for their CCSK certification. And that got us to be much deeper than your typical analyst in terms of having to play around with cloud, having to understand automation, having to build a number of the kind of scripts and – I’ll call it the inherent messiness of building out a stack in the cloud and really making it operational, because we were eating our own dog food. Our website, a lot of the stuff that we had prototyped was really demonstrative of the challenges that organizations face as they move a bunch of their stuff into the cloud, and really as they embrace a DevOps mindset of trying to be agile, trying to be innovative, trying to move towards more of a continuous type of deployment model. We really came across a number of the challenges these organizations have in terms of just really maintaining control, right? Once you have multiple DevOps teams doing things in multiple kind of accounts, you start to run into challenges relative to how you enforce best practices.

And that’s really one of the challenges that security people have with this whole DevOps revolution, which is, “Hey, this sounds great, but we’ve got a playbook, a set of practices and policies that we really require all of our environments to adhere to in order to protect that data.” And obviously the faster you move, the more agile and continuous you try to operate, the harder it is to enforce those best practices.

Shimel: More about that in a second. You touched on two things there that we’re going to dig into. Let me just finish laying my groundwork. Mike, besides you, Rich and Adrian, the Securosis gang, there are at least two other key people on the founding team of disrupt:Ops who also happen to be friends of ours for years –

Rothman: Yeah, that’s right.

Shimel: Give them their due. Why don’t you give them a shout out?

Rothman: You bet. So back when we spun the technology out of Securosis, we brought on two guys, very experienced guys in the security space. Our CEO is Jody Brazil. So Jody was a cofounder and long-time CEO of a company called FireMon, which I know you’ve done work with for a long time –

Shimel: Sure.

Rothman: So Jody kind of is really the driving force behind a lot of what we’re doing at disrupt:Ops. And our CTO is a guy named Brandy Peterson, another longtime security professional. He was actually the CTO of FishNet Security for 15 or 16 years.

Shimel: As was Jody before Brandy, right?

Rothman: Yeah. I met both of them around the same time.

Shimel: Yes, when I first met Jody, he was CTO and FishNet, and he said, “Who is this Jewish guy with the New York accent?” I went out to visit him in Kansas City to tell him why you shouldn’t use Qualys, and he should use StillSecure, and he made fun of my accent. [Laughs]. Good times. Anyway. But Mike, let’s turn back to a couple of things you were saying about kind of the genesis driving disrupt:Ops. You touched on one thing; you said, “multiple DevOps teams.” So this is something we see, and I call it almost second-generation DevOps. You know, when a company or an organization is first embarking on their DevOps journey and they do sort of a trail balloon, and they pick a project and they have a DevOps team – you know, and they may not call it DevOps. They have a team that’s practicing DevOps sort of principles on this one particular project. And oftentimes, wow, great success, because you are – you know, it’s an isolated environment, right? In some ways you’re not in the quote/unquote real world.

And then you say, “This is great. Let’s take it out. Let’s expand that beachhead. Let’s expand the bubble.” And all of a sudden – you know, larger organizations; small teams or smaller organizations not so much, but larger organizations – now you start having two, three, four, six different projects that are being run with a DevOps mindset and you have multiple instances of Jenkins and you have three different – this team’s using Puppet; that one’s using Chef. And serverless. And all of the complexities that we see in today’s modern software factory. And it’s chaos, right? And then at some point the CIO or VP or director of IT says, “Oh my God, this DevOps thing isn’t working so good. It’s all over the place.” Let alone the security guy’s screaming, you know, right out of the Phoenix Project, “No, no, no!”

Rothman: That’s right.

Shimel: And that’s a problem that we see with a lot of second-gen, if you will, DevOps installs, where it goes beyond the initial team to several teams.

Rothman: That’s right.

Shimel: That’s what you guys see.

Rothman: We do. And it’s interesting, because what you have are really kind of two paths at that point, in terms of how these teams start to behave when starting to be put under scrutiny in terms of, kind of again, their ability to enforce operational and security best practices. You know, one group kind of buries their head in the sand and continues to move forward and really don’t do much, right? They’re like, “Oh, it’s okay,” and you know, they’ll maybe run a vulnerability scan to kind of prove that they’re sort of within policy, but they really don’t have an operational environment that is built to work in concert with the rest of their factory. I love that term, right? That really does encompass a lot of how software is being built today. And then the other part ends up being folks starting to build their own scripts, right? They take maybe an open source-looking thing, they start to build a bunch of their own scripts and code around it, and then what they find is they’ve got a suitcase full of these scripts that they end up having to maintain, upgrade. They don’t have any means of reporting or any scheduling for how they enforce and run a lot of these scripts.

It’s really – you know, we call it automation, but it’s manual automation, which I get is a total oxymoron. But that’s really how it is. You know, you have a bunch of folks, they’re building these scripts out, they’re executing them manually or through very simple triggers, without any means of maintaining, upgrading or scheduling or reporting on what these really key aspects of their operational environment are doing. And it becomes, again, a big problem, where you have – it’s unwieldy because of just the sheer number of things that are happening in a modern DevOps environment with multiple teams. Then you compound it with a number of very tactical scripts that are built to surround the environment, if you’re doing anything. And then at some point somebody says, “Hold on a sec, folks. This is just not where we want to be. We really need to think about it more from an operational excellence perspective and make sure we’ve got an environment that we can enforce our best practices for security and operations.”

And that’s kind of when they get the sense that, “Well, I’m either going to have to make a significant investment in this and become like” – Rich calls them the unicorns of cloud land, right? You know, the Netflix and the Capital One and, you know, the folks who have whole teams of environments that are building tools to do this. Or they have to start looking for some kind of commercial option, because there really is no option, but you’ve got to do something. You can build it yourself or you can look to buy it. And candidly, until the last handful of months, there really wasn’t a realistic commercial offering to start implementing some of these capabilities.

Shimel: No, no. I think the bigger – you know, a lot of what you’re saying certainly obviously rings true. The other fundamental piece of this is, even if you are using one of these homegrown, cockamamie, you know Rube Goldberg kind of things –

Rothman: Yeah.

Shimel: – is it the security guys who are? You know what? Shame on me. It’s not the guys. Is it the security team who’s doing this, people? Is it the DevOps cross-functional team? Is it a little bit of both?

Rothman: Yeah, yeah.

Shimel: You know, how many of – look, here’s my basic, fundamental belief. You are not going to find a developer who raises his hand who says, “I want to write shitty code. I can’t wait to put something insecure out there.” No one says that. No one says that, right? They’ll tell you they’ve got time pressure, there’s pressure to release, pressure to release, they wish they could do more on security. And some of them, the enlightened ones, as you said, they’ll even try. They’ll run a vulnerability scan, because there are certainly open source kind of tools out there for them to mess with.

The problem is, they go to a lot of the security guys, and as you alluded to before, security guys say, “Well we have our rules and procedures here. This is a no.” Right? And they don’t want to hear no. They’ve got to go.

Rothman: You know, what’s interesting, Alan – I want to hit on a couple things that you alluded to there, because they’re important, right? The first is kind of where you start to see the agitation for better operational and security practices. And it’s not that it’s not the security folks. Obviously they’re always going to push for that. But it really is – you mentioned it, right? The DevOps teams that we’ve worked with, they’re very cognizant, they’re very serious stewards of kind of the corporate data, and they want to do the right thing. But in a lot of cases they don’t know what to do, right? So you have a whole bunch of folks who don’t know what they don’t know and they don’t want to go to the internal security team because of a lot of those things you were just alluding to. They’d say, “No, we can’t do that. We have all of these rules.” And in a lot of cases the security team has not updated their set of conditions, their set of policies –

Shimel: Exactly.

Rothman: – to work in a DevOps type of environment, so these folks really struggle. They talk to – again, on the consulting side of our house at disrupt:Ops, we do a lot of work with those teams in terms of helping them understand what cloud native architecture looks like and how to integrate cloud security into their environment, and really just to help them build a program in order to do that. So then you do that with one DevOps team, then you end up talking to another DevOps team and maybe the third DevOps team, and finally IT, at some point, they’re like, “Um, what are you telling our folks? They seem to like what you’re doing and they seem to be doing things in a more secure way. So can you help us?” And then IT starts to get religion. The security team starts to get a little bit of religion about what they have to evolve to. And it really is kind of that interesting transition where it has started kind of out in the DevOps community with, again, those enlightened ones going, “I don’t know what I don’t know. Let me get some help,” and then it kind of back-ending into security. That’s not always the case, but probably three quarters of the time, that tends to be the transition that we see.

And the other thing I want to hit is just about velocity, right? JA very forward-thinking DevOps leader that we’re working with, he said it the best. And he’s just like, “I’ve got 20 DevOps teams. I cannot slow these people down. They are doing stuff; they are making progress. The last thing I can do is put a bunch of onerous security requirements on what it is that they’re doing. They’ll ignore me, they’ll go around me and that’s counterproductive. I can’t do that. What I really need is to be able to build and enforce a set of guardrails around their environment.” Right? That term, “guardrails?” It just really kind of opened up and was a light bulb in our head when we were having this conversation. It’s not about stopping them from doing things. If anything, it’s about allowing them to go faster, yet making sure they don’t drive the car off the road, right?

And that’s really the metaphor that resonates relative to what we’re doing at D:Ops, and really just kind of where the environment is going, in that we have to be able to move faster. Slowing things down is not an option, yet you want to make sure that you are not putting corporate data at risk. You are not opening up significant new attack services just – because people are moving so quickly. Sometimes they make mistakes. Sometimes automation isn’t done in the perfect way. Sometimes humans get involved and certainly are fallible from that standpoint. But with a lot of the inherent, underlying automation orchestration that’s possible within the cloud and DevOps and continuous, you have options to enforce these best practices in a way that we couldn’t do in our traditional data center with our traditional waterfall types of development and operational motions.

Shimel: Absolutely. And you know, Mike – I mean, I’ve spoken about this a lot at various conferences and stuff. A lot of that has to do – you know, we use this term “shift left” in security and all that. A lot of it does have to do with getting to security earlier, faster. Yeah, we’re going to have to automate it. Yes, we can’t be the roadblock. But we can be the appendix after – when I say, “we,” I mean security. We can be the appendix after the delivery or after the deployment.

Rothman: I’ll raise you. I see your point and I’ll raise you one, right? I’m of the opinion that security isn’t a thing. Right? Security should be within everything.

Shimel: Yeah.

Rothman: And that’s really the mentality that we’ve been trying to push on the industry for a long time.

Shimel: Amen.

Rothman: And it’s one of these things where we really can’t afford to wait and be in a position where we’re trying to retrofit poorly architected systems that are moving faster than we’ve ever seen before and then say, “Oh hey, we’ve got to change it because of security,” or because of any other operational gap that we see there. Right? What we have to do is be building in a way that allows us to use architecture as security control, right? Isolation, segregation, multi-factor authentical, identity management – all of these things that are fundamental building-blocks of what we do in the cloud and DevOps can be utilized to build in a much more secure fashion. And it’s really about those kinds of practices that are going to make the biggest difference relative to what it is that we see and what it is that we deploy over the next couple of years.

Again, like I said, I don’t think security is a thing five to seven years from now. Because if it’s not embedded within everything that we deploy, we screwed up.

Shimel: Yep. You know, I heard – because I never come up with original ideas. I just listen. But I heard something awhile back – “Security needs to become synonymous with quality.” And we’ve had QA as a concept in software technology forever or for a long time. Security needs to be just built in, like as part of the quality control. Right? The same way shit or stuff gets tested, whether it be hardware or software or whatever. Security needs to be part of that quality.

Rothman: You bet. To use a software term? Right? Why is a functionality defect different than a security defect?

Shimel: Exactly.

Rothman: Right? And they should all be within the same thing. And again, that’s a lot of when you start talking about immutable, when you start talking about kind of building security testing into your pipeline, which again, is stuff I know that you guys at devopsy.kinsta.cloud write about quite a bit. Again, it’s really not any different than you managing and making sure that you hit your functionality kind of specs from the standpoint of just building code, right? Part of that factory. So yeah, the code has to work, but it also can and should be secure, and there really aren’t different operational motions to make that happen. And that’s what’s so exciting. For a guy who spent 25 years trying to retrofit and get people to think about security as part of their core structure and to treat it as really a business function, it’s really enlightening to be in a situation where you actually can implement a lot of those functions within the core processes that you use to develop the technology.

And again, are we there yet? Of course not. Is there a lot of education to be done? Without a doubt. But we at least have the option now, right? That’s the aspirational goal to what it is that we all do every day, which is to make sure that we’re pushing for the right types of decisions to be made as early in the process as we can, because we all know how much it costs to fix it later.

Shimel: Absolutely. Mike, I’ve got to tell you, listening to this conversation, I’m thrown back to, “NAC: is it a feature or stand-alone?”

Rothman: You’re dating both of us, man. Stop that out. Cut that out.

Shimel: It’s such a pleasure to talk a little theory here with you. But let’s turn for a second to real stuff. Not that what we’re talking about isn’t real. But I wanted to give our audience a little bit of a taste – so disrupt:Ops – great people, great big problem to tackle out there. Give us some specifics. What are you guys doing?

Rothman: Yeah, so what we’re doing is we’re basically building a cloud management platform to implement a lot of these ideas that we’ve been talking about for the last couple of minutes, Alan. Initially it’s a guardrails platform. So what we have is the ability to, in an AWS environment, enforce a set of best practices across security, operational and also cost management. So one of those things we don’t talk about too much is that developers don’t really like to shut their stuff down because, “No, it’s going to mess with something. I don’t have to. The CFO bitches but we don’t really care.” What we can do is also implement best practices in order for folks to clean up their room, right? We try to do that with our kids all of the time, too. You know, so we try to do that with our developers as well.

So really implementing a platform for security, operational and cost management guardrails, to again, immediately not just find the issues – there are a lot of tools, as you said. A lot of vulnerability scanners can kind of look at your cloud environment and tell you you have problems. The issue with that is that most operations people are overwhelmed with the number of other things they have to fix every day. Adding more stuff to their list doesn’t really help them. So disrupt:Ops is really focused not just on finding the issues, but also fixing them and enforcing those best practices. Let me give you an example of that. So let’s just say some person decides they want to open up a server to the internet because it’s just easier for them to do that. Well obviously that would be a pretty significant security problem. So as opposed to just taking that server offline, what you can do is you can basically change the security group to make sure that it’s only accessible via a known, good IP address range within your corporation. That’s a good example of a guardrail. Or making sure that you’ve got MFA turned on for every account that gets spun up by your magical Terraform environment that may not build that out as a core security requirement.

So again, there are 50 to 60 of these guardrails, in effect, that you can implement in your environment, to again, make sure that you are not just alerting when you get out of policy, but actually fixing the issues, in a lot of cases before you even know they’re issues, so that you’re not sitting there trying to pick up the pieces after half of your data is in Chechnya.

Shimel: Exactly. Or Romania.

Rothman: Or Romania. It’s somewhere.

Shimel: Mike, how is the offering packaged? Is it a SaaS kind of offering?

Rothman: Yeah, it is. What we found is since – you know, remember the days where people were like, “Oh, I don’t know about this cloud thing or SaaS. I’m not sure I’m comfortable with that”? Now it’s like, “Wait, you want me to install software in my environment? What? What’s wrong with you?”

Shimel: That would be kind of oxymoronic for a DevOps tool, but –

Rothman: That’s right. That’s right. So we deliver as a SaaS service. It’s actually a very cool kind of one-click provisioning process where, when you’re logged into your AWS account, you run basically a cloud formation script that really kind of gives us cross-account privileges to your environment. And again, we’re security guys, right? So at the end of the day, we are basically not even just assuming but enforcing least privilege. So we only have read-only access. When we need to make changes, we grant the privilege as we need it, then we revoke it. Because again, what we’re trying to do is make sure we enforce operational best practices; not add more attack service. So again, we’ve built the environment to be secure by design. We use all of our own dog food, to make sure that we are adhering to kind of common best practices. And again, we’re all 25-plus years security folks, so we do take that pretty seriously.

Shimel: Excellent. Mike, for people who maybe want to download – not download, excuse me – sign up for it or check it out more, where can they get more information?

Rothman: Yeah, disruptops.com. So by the time you hear this little interview, the site will be live. There’s a place you can sign up. You know, first we start with a demo and show you what it’s about and then you can sign up for early access. And again, we’re kind of expanding towards the end of this month, in October. We’re going to add a bunch more folks to the system with the goal of kind of being ready to actually sell the product by the end of the year.

Shimel: Fantastic, man. Well, I don’t have to tell you, Mike. I wish you, Rich, Adrian, Jody, Brandy and the rest of the team nothing but success. We’ll be checking in, I have a feeling, pretty often here, whether it be through Security Boulevard, devopsy.kinsta.cloud, Container Journal or what have you. And you know, fantastic. It’s good to have you back in the game.

Rothman: Yeah, no, I’m excited. Again, really it’s not just a big promise and not just a huge opportunity. You know, and what Rich, Adrian and I, and now Jody and Brandy have always done is – you know, we’re trying to do the right thing to evolve the practice. Right? And that’s what it’s about. It’s a big world and there’s a lot of opportunity. There’ll be a lot of folks talking about guardrails over the next year. And that’s great, right? Because what we want to do is get to a position where we can move faster but move more securely, and I a lot of cases, in the world that we grew up in, those were counter indicators. Right? You couldn’t move fast and be secure. You couldn’t do operational excellence and make sure that you’ve got a lot of these things enforced. And now you can, and that’s what’s really exciting to us. Again, we’re just excited to partner with you, as always, and again, just go out and solve some bring problems for a lot of organizations.

Shimel: Fantastic. All right. Mike Rothman, president and co-founder of disrupt:Ops, a hot new entrant in the DevSecOps space, with a great pedigree and a real reason for being our guest today on DevOps Chat. I hope you’ve enjoyed this. This is Alan Shimel for devopsy.kinsta.cloud. Until next time, everyone, have a great day. Bye-bye.

— Alan Shimel

October 17, 2018
DevOps Chat: Perforce Acquires Perfecto Mobile

Consolidation is in the air, as two well-known players in the DevOps space—Perforce and Perfecto Mobile—are joining forces. Perforce has announced its intent to acquire Perfecto Mobile for its mobile and web automation testing technology, which, when combined with Perforce’s existing portfolio, will better enable organizations to achieve continuous testing at scale. It’s a great combination and one I believe will be well-received in the industry.

Perforce CEO Mark Ties and Perfecto Mobile COE Eran Yaniv spoke with me about the acquisition and its potential impact on the testing space as a whole, and Perforce’s plans for more acquisitions down the road.

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

Alan Shimel: Hey, everyone. It’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat is breaking some big news. The news involves the merger – acquisitions and merger of Perforce and Perfecto Mobile, two pretty well-known brands in the DevOps space. News just came out this morning and we have with us the CEO of Perforce, Mark Ties, as well as the CEO of Perfecto, Eran Yaniv, and if I mispronounced anyone’s name I do apologize in advance. But gentlemen, welcome.

Eran Yaniv: Thank you.

Mark Ties: Thank you very much. Great to be here.

Shimel: Thank you. So guys, you know, I was lucky enough to sell a company or two in my time, and then one of the companies I helped found we did about 30 acquisitions in 36 months so it was almost one a month. It was a little crazy. But, you know, a wise man much older, wiser, and wealthier than myself told me that any time you can, you know, found a company and someone buys it, whether it be a merger, acquisition, whatever you want to call it, but you find a suitor who’s willing to pay significant money, it is a – it is something to be proud of, right? It’s an accomplishment. So congratulations to you, Eran. You know, any time you can CEO a company that has some sort of liquidity in that, it’s a good thing. So congratulations. And Mark –

Yaniv: Thank you very much.

Shimel: – on the other hand – thank – you’re welcome. Mark, on the other hand, any time you could, you know, take the helm of a company that’s out here and getting entrepreneurs to actually, you know, trust you with their baby, so to speak, and it shows a level of trust that you will do right by them and right by their customers, so congratulations to you as well.

Ties: Thank you.

Shimel: Let’s dive in a little bit though, Mark. What kind of drove this? What drove the acquisition here or the merger?

Ties: Since we acquired the management team at Perforce, acquired Perforce a couple years ago, and we’ve been on a journey here to create what we believe will be a strong DevOps player in numerous assets of the space, and as of recently we’ve been very focused on the testing environment witnessed by our earlier-in-the-year acquisition of PRQA and Static Code Analysis and now Perfecto, so Eran and I have been chatting for a number of months here and we’re just, you know, absolutely excited, ecstatic, that we’ve gotten the opportunity here to partner with his cofounder Yoram and himself and the rest of the Perfecto team to bring their capabilities in web and mobile testing into the Perforce family, so that’s really what drove it, is our focus on testing and then their industry-leading capabilities.

Shimel: Sure. Eran, what about you? You know, Perfecto Mobile – I mean I’ve had devopsy.kinsta.cloud now for four and a half years with publishing. Perfecto’s always been on the scene. We’ve had the pleasure of doing webinars and reports and conferences, sponsorships with Perfecto. What was the, you know, impetus to do this deal now?

Yaniv: Well we were kind of discussing this internally for a while now, and when we look at the market we believe because the market is evolving more and more towards implementing DevOps-related processes when there is a requirement with which we call internally a gorilla in the market. The decline of CAs and, you know, IBMs and the HPs of the world is actually opening up – has actually opened up quite a few opportunities and we thought that – we think that the development of a very strong leader in the DevOps market is something that is required, that the market is actually requiring. And so we, you know, were looking around to see what companies are out there that would make sense for us to merge with or acquire or get acquired; something that would create something of a bigger size and a bigger voice in this market.

And, you know, there were various options but we – you know, I really like this notion Perforce because I think nobody in the market really saw it coming, and for us it’s a very exciting opportunity because the offerings are complementing – even complementing status in terms of the install base, so the opportunity was there to actually make it happen and, you know, it aligns really nicely with what we were thinking about the market, so we went forward.

Shimel: Absolutely. Well, you know, if I may add my own armchair quarterback –

Yaniv: I’ve got to say one more – I’ve just got to say one more point that I think is very important, and that is the initial chemistry with the team at Perforce made it a very easy decision.

Shimel: You know, Eran, on that point I will tell you just this culture is important in DevOps in doing mergers and deals like this. The chemistry of the teams is as important or more important sometimes than even the numbers in the books, right? Because the merger doesn’t end on the day of the merger; it only begins. And, you know, it’s important that you have that in there. If I can offer my two cents as an armchair quarterback, I think what we’re seeing here is also the result of a larger trend in the DevOps space.

You spoke about CA, which is, you know, now getting acquired by Broadcom and there’s perhaps uncertainty there, the IBMs – you know, certainly while these companies played in the DevOps space they weren’t necessarily perceived leaders in DevOps, in the DevOps space and, you know, when you see a company like GitHub, which started out as a code repository, right – it did open source good – getting purchased for, you know, this $7.5 billion by Microsoft, it wasn’t just as a code repository, obviously. And, you know, just recently in the last two, three, four weeks companies like GitLab, you know, with $100 million raise, $1 billion-plus valuation, last week it was JFrog with a DevOps platform with $165 million raise, over $200 million raised – you would have to assume they’re also over $1 billion – it certainly seems like the time is ripe for size.

Size matters in DevOps, right? Size and scale matter. And so, Mark – go ahead.

Yaniv: I was going to say that we are seeing these things actually happening in the market. _____ is making all kinds of –

Shimel: Sure.

Yaniv: _____ primarily in the _____ area. The thing that I like about the Perforce Clearlake, if you will, in conversations with – and this is what I really like, is the fact that they are dead serious about what they are doing and their moves are very, very quick and they’re very nimble in their decisions and that’s something that makes a lot of sense and it also coincides with what DevOps is all about, right? So I think that’s a great addition.

Shimel: Absolutely. Mark, let’s hear from you. You know, what’s Perforce’s take on this? Are you in violent agreement or maybe something else to it?

Ties: I’m in violent agreement with the number of the comments that you’ve made. You know, the space – you know, the research that we’ve done around the space for the last three-plus years now is that this space and environment is going to consolidate, and as a result of that consolidation, you know, those players that can put together best-of-breed technology, that can bring the value that the customer’s ultimately desire or need will be – you know, they will be the players that will rise to the top, and we believe we’re doing that with our version control solution _____ Perforce with our _____ solution and now with web and mobile solutions with Perfecto along with the other technologies that we have. So I’m in violent agreement with that. You know, this won’t be the last acquisition that Perforce will do.

I mean we’ve done five now; I could see us easily, you know, doing five additional acquisitions and continuing to grow this business. So that’s one point I’m in violent agreement with. The other point is that, you know, to your earlier point about the people and the culture and Eran’s as well, you know, it’s hard but it’s easy to buy a company. It’s harder to make that company successful –

Shimel: Exactly.

Ties: – during the acquisition, and I think all of the personalities on both sides of the fence with the Perfecto team and with our team are focused on one thing, which is creating a great company that has great products, phenomenal customer support, and then ultimately new customers. So it’s just – this is a great marriage and, you know, I look forward to continuing to drive it with my team with Eran and with Yoram and the entire Perfecto team.

Shimel: Absolutely. On that point, let me ask what are the plans? Eran, will you be staying on? What will your role be? What about the rest of your executive team?

Ties: Yeah so, you know, again, we’re in the days – we’re in the early days here, but the hope on my end is that Eran and team stay around and Eran will be leading this business as an independent segment, subsidiary, whatever you’d like to call it of the Perforce family reporting directly into me, so that is the plan. Now we do have teams obviously from both sides of the house working on the formal integration and how we’ll bring the companies together over the days, weeks, and months to come. We’ve just signed the agreement here earlier this week and we hope to close it by the end of the month.

And, you know, we will take our time. We will be very diligent in what we’re doing here so that we do not disrupt either businesses, because right now both businesses have been very successful.

Shimel: Excellent. Mark, I’ve got a question for you. You know, with each of the kind of deals and money raises that I mentioned earlier, I’ve spoken one-on-one with the CEOs, and one of the things I’ve asked them is what is their vision for how their company – you know, where does their company fit into the larger DevOps? You know, so for instance, GitLab wants the first true end-to-end DevOps product line. Shlomi Ben Haim at JFrog, they want a true DevOps platform that handles all artifacts, anything related to artifacts.

Can you succinctly give us what is the vision – right? – for Perforce? What – you know, when you’ve done 5 more acquisitions, 10 more acquisitions, whatever it is, what’s the vision for what Perforce will become and what you’re striving for?

Ties: Yes. So there are some very grandiose visions out there, and you’ve mentioned a couple of them. Ours is very simple; we want to be the enterprise player at scale. I mean we provide a very strong solution to enterprise customers that are looking for speed, scalability, security – to name a few of the attributes of the products that they’re purchasing and look to acquire as their providers. So that’s what we’re looking to do, win every inch. All right? We’re not gonna win every market vertical, but the verticals that we choose to go down our plans are to do nothing but dominate them, and so that’s why we’re looking for industry leaders like the Perfecto solution, like the Perforce solution and the others that we’ve acquired, to make sure that we continue to demonstrate the need that our enterprise customers have.

Shimel: Fantastic.

Yaniv: And this – and if I may, investing in the vision that Mark articulated around the enterprise aligns extremely well with what we were thinking back in a narrow – if you will, in a narrow space, which is around the continuous testing. But in the notion of addressing the enterprise and the specific ____ that we would be strong at, would make the vision, the joint vision, something that is really great, and that made it also very, very easy for us to _____.

Shimel: Excellent, excellent. Well, gentlemen, let me wish you both success and congratulations. We’re about out of time here on this DevOps Chat, and I’m sure you’re both very busy. It is an exciting day. Maybe we can check back in a few months when the dust settles a little bit and see how things are going and where you’re headed from there, all right?

Ties: Great. More than happy to –

Yaniv: I’d be happy to.

Ties: – continue the conversation. Thank you.

Shimel: Okay. Mike Ties, CEO of Perforce, Eran Yaniv, CEO of Perfecto, Announcing the merger of their two companies, and as Perforce continues to scale in the DevOps space. Thanks for being this episode’s guest on DevOps chat, gentlemen. This is Alan Shimel for devopsy.kinsta.cloud and you’ve just listened to another DevOps Chat.

— Alan Shimel

October 12, 2018
DevOps Chat: All Day DevOps Preview

All Day DevOps, the virtual event featuring more than 100 sessions from practitioners around the world, is happening very soon. Now in its third year, this year’s event will take place Wednesday, Oct. 17, starting at 3 a.m. Eastern. But if you don’t feel like getting up, each 30-minute session will be available on demand as well.

In this DevOps Chat, All Day DevOps founders Derek Weeks and Mark Miller, both also from Sonatype, offer a preview of what’s in store during this year’s virtual event, which is free to attend.

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

Audio

Transcript

Alan Shimel: Hey, everyone. It’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Really happy to have two friends of mine join us on the chat today. We have none other – those crazy guys from All Day DevOps and Sonatype, Derek Weeks and Mark Miller. Mark, Derek, welcome to DevOps Chat.

Mark Miller: Thanks, Alan.

Derek Weeks: It’s good to be here. Always happy to chat with you.

Shimel: Yeah.

Miller: Thank you, Alan. Welcome to New York, welcome back home.

Shimel: Yeah, it’s good to be home. So Mark, you know, this is an audio only, people don’t know, but you have a Fighting Okra hat on, is that correct?

Miller: You know, some of my followers from around the United States are sending me hats and right now the Delta State Fighting Okras have sent me a hat so I’m gonna be giving them a good callout during All Day DevOps. Derek, you haven’t seen this one yet.

Weeks: No, I haven’t. That’s pretty cool-looking.

Shimel: All right, a shout out to the Fighting Okras.

[Laughter]

But Mark, you mentioned All Day DevOps. We’re getting close, right? What’s the date?

Miller: We’re next – we’re gonna be on Wednesday, October 17, and as we looked at this morning, as we looked at it, we’re over 19,000 registrations this morning. Once again, the community has gotten behind it. Derek, you’ve got a bigger hand on it, too. You’ve got some ideas about what’s going on with the viewing parties even, right?

Weeks: Yeah, I think the – you know, we’re at 19,000, I think we’re easily headed over 30,000 by the time we get to the conference, and I think part of that is what we’ve seen with the viewing parties this year. So, you know, it’s an interesting kind of evolution of the conference where we started this thing as, hey, let’s have this virtual conference so that everyone can attend wherever they sit, and then people said, “You know, I want to participate but have others in my company or my community participate as well, so we’re just gonna gather in a place to have this viewing party.” In the first year that we did it there might’ve been 10 because it wasn’t a formalized thing. Last year we kind of encouraged people to do it but didn’t have anything on the site that really mentioned it too much, and I think we had 35 viewing parties.

This year we have 115 viewing parties that have registered in 24 countries, and the interesting thing is not only has that changed the conference and how it evolves and how people share this education within groups but we’ve heard some amazing stories just come out of this community where organizations like RBC in Toronto, they’re planning for up to 1,400 people in RBC to attend their viewing party. State Farm in Dallas has 500 people that they’re planning in their viewing party. National –

Miller: They went up to over 800 this weekend.

Weeks: Yeah. National Australia Bank; you know, they’re planning, I think, 250 people in their viewing party. And when you think about the size of some DevOps conference that all three of us have been to, anyone having 500 people at a DevOps conference has a successful DevOps conference. The fact that one company, you know, is setting up a viewing party just for our conference that’s as large as some DevOps conferences out there it’s pretty interesting. But, you know, the same point – and this is a conversation I had with someone this morning in Munich, he said – you know, we’ll get into talking about Club 20 – but he said, “Hey, do we have 20 people registered yet because we want to get our company into Club 20,” and I hadn’t heard of this organization really before.

And I looked; they had 16 people. Now they actually have 20 so they’ll make the list. But I said, “I’m curious; how many people in your organization could attend All Day DevOps that, you know, are DevOps practitioners?” And he said, “You know, like I want to get on the Club 20 list, but I think we could get 100 people at our viewing party and in a perfect world we could have 1,000 people participate in All Day DevOps.” And that – you know, Mark, as we started this whole thing, that was really the aim, like how do you get to those 1,000 people and give them some free education?

Miller: Yeah. One of the topics that you just touched on – and you and I talked this morning too as we were putting together how our day was gonna go – Alan, when you think about it, can you imagine 20 people showing up at a live conference? I mean think about that. If you get four or five people at a live conference from one company you’re blowing out the budget, right, already. In this case, we can literally allow dozens and dozens of people from the same company to attend 120 sessions in a live conference. It’s a pretty phenomenal way to look at it.

Shimel: And, you know, so one way of looking at it, Mark, is wow, what would the cost be to fly in a dozen, two dozen, three dozen people to a physical conference? The other thing, you know, to make it a truly win-win is what are the benefits of a team that size sharing that common experience, right? It’s almost priceless, right? It’s like the MasterCard commercial: $45 for the conference ticket, $60 on Uber, $20 on lunch. Sharing it as a team? Priceless.

Miller: Yeah.

Shimel: And that to me is the real one plus one equals three of it.

Weeks: Yeah, I think – and that’s something that we see – you know, as we’ve seen the past two years that we’ve done this and I think we’ll see again in spades, is that we have the Slack channel set up during the conference for conversations, and last year during the 24 hours of the conference we saw 30,000 conversations on Slack, and that ability to exchange information, whether it’s with people on your own team and you have your internal Slack channel set up through your own company because, you know, you’re State Farm and that’s what you did and how you shared information, or you’re participating in the global channel, you know, I think it’s all about that kind of exchange of information and also the anonymous – somewhat anonymous level of that communication.

We all know it’s a lot easier to ask a question in a conference if no one can see you’re the person raising your hand or asking the question; you’re just one of many on a Slack channel saying, “Hey, I have this question,” and there’s – you know, it opens people up to sharing a little bit more or asking questions they might not otherwise get to ask.

Shimel: Absolutely, absolutely. Guys, I want to turn the conversation a bit if I can from numbers and viewing to content. Let’s talk – you know, people out listening to this, some of them may already be registered, some may not, some may not even know of All Day DevOps, right?

Weeks: Yeah.

Shimel: Mark, if they register – and registration’s free. You don’t have to be part of Club 20, you don’t have to have your whole company. If you’re just one person who’s digging DevOps you can register for free for All Day DevOps and sit in on 24 hours – up to 24 hours of DevOps, right? They don’t have to listen to all of it; you pick and choose what you want. But give us some of the highlights. What are some of the big hot topic speakers that you’re looking forward to?

Weeks: Mark, why don’t you go –

Miller: One of the things that you just – sure. One of the things that you just said is interesting to me, Alan. You said 24 hours of DevOps. Actually, when you do the math it’s more like 50 to 70 hours of DevOps because we have simultaneous channels happening. The things that I’m excited about seeing is, one, we have David who runs a CRE team and an SRE team at Google coming to talk about site reliability engineering. That’s a new topic for us this year, and to have Dave step in from Google, who is actually running that whole initiative for Google, it’s gonna be an exciting one for me. The other one that I’m – how do I say it?

I’m exciting that Cindy’s coming, Cindy Healy. She is the one that wrote some of the code that went on the Mars Pathfinder to send to Mars. Now that’s – the personal story behind how Cindy did that and how she became involved in it, what’s she’s doing now to encourage women in technology, that is a story that I really want people to be able to hear, so we’ve got her set up as a keynote. Derek, you’ve got some interesting things that you’re looking forward to, right?

Weeks: Yeah. You know, one is a conversation I just had last week with one of our keynote speakers, George Swan. He’s at Autodesk. Super interesting story of DevOps in the enterprise. So these guys knew, you know, the needed to transform the entire company – and I think they have about 200 products, 4,000 developers in their organization, and they needed to transition from an Agile organization to an organization that had DevOps practices top to bottom. At the same time that they were doing this they needed to transition into the cloud. They also needed to transition from a traditional license business to a subscription license business.

They had, like, four or five transformations going on at the same time – you know, become cloud-based infrastructure, transition to SaaS, transition to DevOps and some other things, and it was like, oh my gosh, one, this is a multiyear journey he’s gonna tell his story on, so it will be fascinating to kind of get lessons learned and also understand it’s not just hey, you know, transition to DevOps; it’s there are a lot of other things that are moving parts of our business that have to change, you know, along with this as the marketplace evolves for them and other participants. The other one that I’m really excited about, and a guy that I’ve got to see a couple of times at live conferences, is Navin Vembar. He’s the CTO over at GSA, the Government Services Organization.

They do all the main procurement for the U.S. government. But he is going to talk about how they transformed their organization into a DevOps practice and kind of looking at the maturity models that they use and kind of used as milestones for measuring their progress within their organization and also, you know, coming from an organization that loves silos, they love regulation, [laughs] they overly love governance sometimes, but to hear his journey, he’s a fascinating speaker and someone that I quote often, so always looking forward to hearing people like that join in.

Shimel: Sure.

Miller: Alan, the other thing is as Derek was talking I went over to the All Day devopsy.kinsta.cloud site and clicked the speaker link. We’ve got 124 speakers this year. We had so many good submissions that we actually went above our quote. We had set it at 100 and we’re at 124 right now. It’s hard to go and cherry pick out of those. What we want to make sure people understand is two things; No. 1 is we want to bring 124 practitioners to everybody’s desktop. We want you to be able to pick and choose what you’d like to hear.

No. 2, Derek and I guarantee to the community is there are no vendor pitches here. Alan, you’ve been with us long enough you know. We really hold to that creed, that what we want is practitioners, and when you come here I think that you can trust us to provide that to you.

Shimel: Absolutely. That’s another aspect I want to just highlight too, guys. You know, we – you both highlighted what – some of the ones you’re – some of the talks you’re looking forward to most. Well, Mark, there’s 124 as you mentioned. All Day DevOps is a global phenomenon, and though we may have GSA and we may have some U.S.-based practitioners, Mark, I’ve been around the world with you, right? You and I have traveled – [laughs] literally traveled the world, and DevOps is a worldwide thing, and I think the speaker lineup reflects that. Have you had any stats, like how many different countries are represented?

Miller: Yeah, Derek’s got that, but before he jumps in with the stats I got a story that you’ll recognize. You and I went to Singapore, Bangkok, Sydney and Melbourne about two months ago.

Shimel: Yep.

Miller: While we were having dinner with Rob England in Sydney, I went, “Man, you’ve got a great story, Rob. Why don’t you speak at All Day DevOps?” Meaning because of our travel, because of our ability to meet people in the community, it gives all of us the ability to say this guy’s got a story that deserves to be told, and I think that that’s one of the things when Derek and I were first putting this together we actually talked to – amongst ourselves and said what we want to do is give exposure to people that are doing DevOps that deserve more recognition for what they’re doing, and our global platform has allowed us to do that. Derek, how many countries are we dealing with now?

Weeks: I think, you know, we’re around 130 different countries participating.

[Laughter]

It’s amazing, you know, to see that list grow because some of these – you just imagine like who’s practicing DevOps, and in my head like maybe 22 countries and maybe if I stretched it like maybe 40, right? But to see participants from all over the place – you know, and I just did a quick look at the registrations in the top cities. So No. 1, Bangalore, second, London, Toronto is high on the list, Melbourne, Australia; Sydney, Australia, Atlanta, New York, Istanbul, Chicago, Singapore, Amsterdam, San Jose, Seattle, Santiago, Jakarta.

Shimel: That’s amazing.

Weeks: You know, in the top 20, right? So it’s really, you know, a global kind of phenomena that we’re seeing. You know, where is the DevOps kind of center of expertise? Where are these people around the world? It’s pretty interesting to see where they all come from.

Shimel: Agreed. You know, Mark, listening to you talk –

Miller: I don’t want to leave anybody out but when we –

Shimel: Go ahead. You go, Mark.

Miller: Go ahead, Alan, go ahead.

Shimel: No, no, you go.

Miller: Yeah, I just – I don’t want to leave anybody out, but there’s some names I’d like to give out a call to, is like Midu in India, who’s helped us so much with the community in India. Look at Bangalore; it’s No. 1 on the list. When you look at Michael Mann, you look at Mark Cluett in London; those are community people that have said this is something worthwhile and I want my community to know about it, and that’s kind of – I don’t know if heartwarming is the word, but it means that we have actually resonated with various communities, cross-cultural around the world, and that means a lot to me.

Weeks: Yeah, I just – you know, curious, I just looked at the list of what cities have 40 people registered – Alpharetta, Georgia – that’s near Atlanta – Johannesburg, South Africa, Istanbul, Dubai, Barcelona, Seoul, Sao Paolo, and McLean, Virginia, where I’m sitting.

Shimel: Seoul, I haven’t heard Seoul yet.

Weeks: Yeah. So fascinating, just that list of only cities with 40 is extremely diverse.

Miller: Wow.

Shimel: You know, that’s really – that’s the power of the internet and it also speaks, Mark, to the power of DevOps, is if it was all centered in San Francisco or London, great. All the cool kids, right, are doing it. But it’s not; it is – it’s diversified, decentralized. You couldn’t snuff it out if you tried. You know, Mark, listening to you talk though a little bit about we met this one here and this one there, I can’t help but think of you as sort of the Anthony Bourdain of DevOps, venturing into parts unknown.

Miller: You know, I’m a story guy. I gotta jump in there. When I was in Manila, we got Anthony Bourdain’s driver to take us around to all those places. It was fascinating.

Shimel: And I’ve been on those trips with you. You like to off the beaten path. But, you know, this is a PG-rated show and, you know…

[Laughter]

Weeks: I’m gonna give Mark a new title of the Anthony Bourdain of DevOps.

[Laughter]

Miller: I’ll take it, I’ll take it.

Shimel: Anyway, hey guys, we’re about out of time here, but I wanted to check in ’cause we are getting close. We would be remiss if we didn’t at least mention where can people go to register for All Day DevOps? Derek?

Weeks: AllDaydevopsy.kinsta.cloud. It’s that easy. It takes 15 seconds to register. You’ll get a link to the schedule once you register so you can start to build your own schedule for yourself and your organization. And like we always say, once you register yourself encourage your team to register so that everyone can watch together.

Miller: Alan, the last thing that I’d like them to look at on the site too, is once they register go to the viewing party page. With over 110 viewing parties there has to be something local, that’s relatively local, if you would like to participate with other people.

Shimel: Fantastic.

Weeks: You know, the other thing just really quick before we go is one way that we do this conference for free for everyone is we have a lot of sponsors, like devopsy.kinsta.cloud, Scaled Agile, Cisco, Puppet, Chef, GitLab, Sonatype, CloudBees and other organizations that help fund the conference to actually put this on and make this happen. We also have 245 community groups around the world that are helping us spread the word to say here’s free education for our members, and that’s really at the heart of this conference is the financial support to make it free for everyone and the community’s support to really spread the word to everyone that this is available to them.

Shimel: Excellent. Absolutely, Derek. These – as someone who’s done enough conferences, it really – it doesn’t happen without the sponsors, and a lot of people say, “Oh, the sponsors just want to spam me or contact me.” Yeah, you can talk about that all you want but they make the world go round on these things, right?

Weeks: Yeah.

Shimel: We can’t do it without them and don’t lose sight of that.

Weeks: Yeah. It doesn’t cost $10 million to run but it’s not free to run. [Laughs]

Shimel: Exactly. But we all know that. Anyway, guys, two of my good friends in the DevOps – well, not only in the DevOps space, in the world in general. Mark Miller, who I have traveled around the world with and eaten in some very –

Miller: Thank you, Alan, so much.

Shimel: – fun places – Anthony Bourdain there – and Derek Weeks.

Weeks: Thanks, Alan. Always a pleasure.

Shimel: Always a pleasure, man. I haven’t seen you in too long.

Weeks: Well –

Shimel: But hopefully we’ll see each other soon.

Weeks: Yeah.

Shimel: All Day DevOps coming to a computer near you Oct. 17, right?

Weeks: Yep.

Shimel: All day.

Miller: Starting at 3 a.m. New York Time, Alan.

Shimel: Excuse me?

Miller: Starting at 3 a.m. in New York. I’m sure you’ll be with us for the opening.

Shimel: Yes, I’ll be up bright and early at 3:00. But if you want to register, go to AllDaydevopsy.kinsta.cloud, guys. It’s free. Jump on it. It’s a great event. Have a great day, guys. Thanks for joining us. This is Alan Shimel for devopsy.kinsta.cloud and you just listened to another DevOps Chat.

— Alan Shimel

October 11, 2018
DevOps Chat: The New Security Breed with Veracode’s Mark Curphey

DevSecOps has changed the way developers approach security in their application development cycle. But it’s also been the source of confusion, as some developers grapple with understanding how DevSecOps is different from application security. Mark Curphey, VP of strategy at CA Veracode, is clued in to the differences, which he discusses in this DevOps Chat.

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

Alan Shimel: Hey, everyone. It’s Alan Shimel, devopsy.kinsta.cloud, Security Boulevard, and you’re here for another DevOps Chat. Today’s DevOps Chat is all about DevSecOps, AppSec, what’s happening on the front lines. I’m joined by an old friend of mine, Mark Curphey. Mark is currently VP of strategy at CA Veracode. Hey, Mark, welcome to DevOps Chat.

Mark Curphey: Thanks, Alan. Great to talk to you again.

Shimel: All right. So Mark, let’s start off with this. I know you’ve fairly recently joined Veracode. Give our audience a little bit of your background and how you came to be where you are.

Curphey: Yeah, sure. So misspent youth, went back to university late, did a master’s degree in information security, and wound up working for a bunch of banks in the city of London. Moved here to the states in 2000, then ran software security for Charles Schwab. So Microsoft were creating the SDLs. You know, sort of Gates had sent out the famous memo and I was doing the same for an online service basically at Charles Schwab. So that’s where I started. Then at OWASP, which some people sort of associate my name with, which is the Open Web Application Security Project.

And since then I’ve worked at Microsoft around the security tools team and then I think with MSDN, the Microsoft Developer Network. I more recently created a startup called SourceClear which was focused on helping developers use open source code safely in the modern DevOps world. We were acquired by Veracode about five months ago. So I’m now the VP of strategy at Veracode helping the Veracode platform and how we really sort of work with DevOps and the new way of doing things.

Shimel: Fair. Okay, so Mark, let’s start off with this though, and I think there’s some confusion out there with both security people as well as non-security people in terms of what’s the difference between AppSec and DevSecOps? Is one really just synonymous with the other? Is DevSecOps another name for AppSec? I don’t think it is. What do you think and how do you define the differences between them?

Curphey: Well, certainly every vendor’s got a DevSecOps product these days, right? So it’s easy why people are getting confused. I mean I think the reality is the way you have to do AppSec in a DevOps world is fundamentally different to the way we’ve done it before. It used to be about educating developers, writing policies that people had to read, human processes to do final check off, things like threat modeling, you know, all of these sort of things. They kind of worked okay in a waterfall world were kind of modified a bit to work in an agile world. But, you know, DevOps is changing the game completely. So we’re in a world of automation, and, you know, the modern ways that we have to secure it are fundamentally different. So for me DevSecOps is about how do you apply security in this modern, you know, DevOps world and that’s predominantly focused around, you know, automation. What can you automate and, you know, how can we put automation in those pipelines that are happening so that security happens inline as code is created and it’s moved through the pipelines?

Shimel: Fair enough. We talked pipelines. We talk left to right, Mark. You know, and Veracode is probably one of the leaders in this space when we talk about DevSecOps and shifting left and working. But I think what people want to know is really how does the security person or the security team work with the development team? It’s easy to say, but what does it really –

Curphey: Sure.

Shimel: What does it really mean?

Curphey: Yeah. I mean, look, I think there’s a new breed of security people which is exciting to see. Like the old world that used to be the development team and then there were the security team. There were kind of the two separate teams. The security team needed to sort of bless things before they went into production, but we get appointed a data center and whatever. These days what you see is it’s all about velocity.

So, you know, there are security people that are embedded into the security teams and they’re kind of acting like consultants and helping the dev team do security as and when it’s needed and make the right decisions without slowing things down. So instead of it sort of being this procedural thing where they were required to go through whatever a control grate, they’re just tired of the flow. That’s exciting to see because I think we’re seeing a paradigm shift of how that happens.

Shimel: Yep, I think we are seeing a paradigm shift in this. So here’s going to be a question you’re going to say, “Alan, you’re crazy,” but Mark, does it make a difference? Is it definitively improving our security here?

Curphey: Yeah. First, Alan, I’m never gonna call you crazy, but that’s good to know, I think.

Shimel: I figured you would.

Curphey: No, but look, I mean like, for sure, like think about like we all know what happened with Equifax, right? Like biggest data breach in history, result of open source that was insecure and hadn’t been updated. That problem is solvable and it’s solvable at scale in a pipeline. So what we were doing at SourceClear – I don’t want to turn into a product pitch in any sense, but we were basically trying to close the loop of this library is out of date, issue the pull request, figure out if it’s going to break things, and if so, update it. And the developers loved that, not because they’re fixing security but they’re fixing the dependency hell problem.

So we’ve not been able to do that before because, you know, we hadn’t been injected directly in the pipelines. So these are opportunities that really make a difference and companies that implement these tools like us and there are others around, totally can avoid the whole Equifax thing. It’s not a case of like no one got notified or no one knew. Like it happens automatically in the pipeline. So there are great opportunities to do things like that.

And I think moving forward we can also look at things like are people using dangerous APIs? Are they calling, you know, external services that we don’t want them to call? Like to a large extent the pipeline has become the new firewall and it’s a place where we can put controls, inspect the traffic, and decide what we want to allow and what we don’t want to allow which is a great place to be.

Shimel: I agree. I agree there. So Mark, I guess where I wanted to go next with this is a lot – again, I’m a man who lives with a foot in each world, right? I spend a lot of time with my security friends and colleagues that I’ve known for years and years and years, but as part of devopsy.kinsta.cloud I’m out speaking to developers an awful lot, right?

Curphey: Mm-hmm.

Shimel: And some of the questions that I hear from both sides is, okay, you can’t serve two masters, there can’t be two people in charge. How does the day-to-day of this flow? You know what I’m saying?

Curphey: Yeah, no, for sure. I mean look, the reality is in all organizations the digital transformation and everything else happens that it’s all about value creation and the value is created by developers. So they’ve been empowered to choose their tools. They’ve been empowered to figure out which process allows them to innovate faster and all those things. With that we’ve seen the rise of the cloud and everything else. So it can’t be an us or them scenario. It’s how do you support those developers on their mission to change things and create this digital transformation? So the old ways, you still see it but you still see the old school of security people saying no and stopping people; but those battles are not going to be won. It’s about how do we help people move forward at the right rate.

I mean I kind of equate it like someone was saying the other day, like similar to autonomous cars, like you’re not going to stop them. Like figure out how to make them work properly, safely, and securely. But if you don’t like it, you’re not going to stop that, have that technology happening and being created so you’ve got to embrace it. That I think is the philosophy that is going to win out the day.

Shimel: Fair enough. I don’t disagree with you there, Mark. Let’s talk a little bit about what you see near term and maybe a little bit longer term in developments here that, you know, our listeners, you know, could fundamentally change their day to day. Where do you think we’re heading?

Curphey: Yeah, sure. So, you know, I think machine learning and artificial intelligence and big data were sort of touted and, you know, the hype cycle kick off and, yeah, people didn’t always deliver on that. But there are exciting things happening in that which allow us at scale and at speed to do things that we couldn’t do before. So a good example of that is in the security world most of the vulnerabilities no longer exist in the CV system open source code. They just can’t keep up with the scale. We’re releasing thousands of libraries. In the DevOps world, developers find things, fix them, push them out. They don’t go back to monitor and publish these vulnerabilities, etc.

But the great news is, you know, there are big data systems, machine learning that can process that data and we can identify those things at scale. Those same kind of techniques have been applied by Google and the Android App Stores and things like that. So that application of like that modern tech I think has great opportunities for us to do things which we’ve not been able to do before, and you’ve certainly seen some of the big vulnerabilities that have been released have been a result of that stuff coming out.

Shimel: Got it. Got it. I just had my phone ringing there. I apologize. Mark, let’s, if I can and if you’re not too shy about it, I doubt you will be, let’s talk specifically a little bit about Veracode.

Curphey: Yes.

Shimel: You know, you’ve been there five months. What do you see? What gets you excited there in the morning?

Curphey: Yeah. We had loads of places to sort of land. We came to the conclusion that people wanted to have less tools than more. So they wanted to buy a suite. When you look around, what the Veracode guys had done is built sort of best-in-class SAST and it started working on software composition analysis. We had best-in-class software composition analysis. So it made sense from that perspective.

Also as you know, the heritage of the company, you know, it isn’t a fly-by-night company. It’s Chris Wysopal and Christien Rioux, right? These guys were in the loft, right? So that legendary around the place. So the company has this real DNA about it around security. So for me it’s kind of this exciting security DNA in the company embracing the way we build modern software. So that’s what attracted us to join forces. We’ve been extremely excited since. A lot of exciting things happening that for sure will start to come out of it at the other side no doubt.

Shimel: I agree with you. I actually have Chris on a panel we’re doing on DevSecOps next week. I’m really excited to have Chris as well as Dave Duncan from CA, I think is on the panel with us.

Curphey: Right. Right.

Shimel: So Mark, you know, running out of time here, but I wanted to talk a little bit more about, you know, you came into Veracode, as you said, about five months ago via the acquisition. There’s a lot of people out there seeing a lot of buying and selling, M&A kind of stuff going on in especially around DevSecOps and DevOps related companies. I mean obviously a rising tide lifts all boats and there’s consolidation going on, but is there anything else at play that you’re seeing that’s kind of driving this stuff?

Curphey: Well, I mean, you know, in the place that you look on the horizon is actually where the dev tools are going. So you know, if we look at companies like AWS, it’s not really just a hosting platform. It’s a full tool suite, right, of everything from machine learning libraries in the cloud to real-time databases and things. Google and Azure are building the same. As we start to think about like what is a next generation of developer look like, they’re likely to use an IDE and a browser. It’s not going to run on a desktop anymore. And you know, co-changes happen and everything happens up in the cloud. So I think there are a lot of exciting things happening there and how do you integrate security into that world for sure. So that’s a lot of the stuff that I’m focused on. Then you can get scaled I think.

Shimel: Got it. Got it. Mark, you know, I appreciate you talking to us today. I think we’re about out of time. But for people who want to get more information on what’s going on, veracode.com obviously, correct?

Curphey: Yeah, veracode.com is an excellent, well-trafficked blog with Wysopal and various other people and myself contributing to it which is great and we’re out speaking at conferences and talking about some of the both current work and sort of some of the futuristic stuff as well. So love to engage with the community and the industry for sure.

Shimel: Perfect. All right. Hey, Mark Curphey, VP of Strategy, CA Veracode. Thanks for being our guest in this episode of DevOps Chat and we look forward to having you on again soon.

Curphey: Yeah, great, Alan, thanks a lot. Great to reconnect and look forward to doing so the next time.

Shimel: Okay.

Curphey: Take care.

Shimel: This is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat.

— Alan Shimel

October 9, 2018
DevOps Chat: Jez Humble Discusses 2018 ‘State of DevOps Report’

DORA’s annual “State of DevOps Report” is something I look forward to every year. There is no other report out there that gives us a view and insight into the industry the way this one does. And I know I’m not alone in my beliefs. That’s why it’s always a treat to speak with one of the folks from DORA—DevOps Research and Assessment—about the “State of DevOps Report” and get some real takeaways.

In this DevOps Chat, Jez Humble, CTO and co-founder of DORA, and I talk about some of the findings in this year’s “Accelerate the State of DevOps Report”—a new name, but the same valuable information.

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

Alan Shimel: Hey, everyone. It’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat is one I look forward to every year and that’s the one where we speak about the latest “State of DevOps Report.” Helping me, or actually our guest and star for this year’s “State of DevOps Report” review, is none other than Jez Humble, co-founder, CTO for DORA, DevOps Research and Assessment and just all-around DevOps dude and great guy to talk to. Jez, welcome to DevOps Chat.

Jez Humble: Thanks so much for having me, Alan. Always a pleasure.

Shimel: Thank you. And Jez, you know, you guys, Nicole and you and Gene and the rest of the team have done another bang up job this year in the “State of DevOps Report.” It has a little bit of a different nomenclature this year. It’s actually – if I mess it up, correct me –”Accelerate the State of DevOps Report”?

Humble: Yeah, that’s right. It’s the “Accelerate State of DevOps Report” this year but continuing the same rigorous research as previous years and extending it with some exciting new findings this time.

Shimel: Yeah. And another thing I will mention, right, let’s get it out of the way early on, is that this year’s report diamond sponsor is Google Cloud, correct?

Humble: Yep, that’s right. We have 15 gold sponsors as well, but our main collaboration this year is with Google Cloud. That’s correct, thank you.

Shimel: Fantastic. All right, now that we’ve got the commercial out of the way, Jez, let’s dive in. So this is what, the fifth or sixth year you guys have worked on State of DevOps Report?

Humble: Yeah, so this is the fifth year that DORA has been involved in or been leading the research for this State of DevOps Report. That’s correct.

Shimel: And so, you know, when we look at it from that point of view, you know, with hindsight, it really is a massive amount of data there to dig into, but let’s concentrate on this year’s report, Jez. Let’s start with what do you think for our listeners, what do you think the biggest takeaway for them is?

Humble: So yes, as you say, this is the biggest research program of its kind looking into DevOps, what DevOps means, why it’s important, the factors that predict your ability to deliver with speed and stability. You’d think, you know, this is the fifth year that we’re doing this that we’d run out of things to talk about. That’s absolutely not the case. This is the biggest and most comprehensive one yet. I think a few big takeaways.

No. 1, again, we found that our measure of software delivery performance is still valid. That’s looking at speed and stability. We find again that the high performers are not trading off one against the other. They’re actually increasing both the speed and stability of the delivery process. We’ve extended that measure out also to look at availability as well. So availability is availability in production. It’s a measure of operational performance. Because we’re also looking at that, we now talk about software delivery and operational performance. So we’re covering the whole delivery life cycle from development right through to operations in production. Again, we find the high performers are not making trade-offs there. They’re achieving high levels of throughput and stability and availability as well.

We’ve also looked at the key technical practices that drive high performance, and we’ve expanded that this year to also look at monitoring and observability to look at the impacts of continuous testing, to look at database change management, and to look at shifting network security. We’ve also looked in more depth at culture. We’ve looked at the management practices that shape culture to improve performance outcomes. This year we’ve also looked at the role of leaders on influencing culture through giving their teams autonomy and building trust. We find that promoting a culture learning fostered through retrospectives learning reviews has an impact on culture. The highest performers are 1.5 times more likely to consistently hold retrospectives and use them to improve their work which is critical.

We also looked at cloud infrastructure. A lot of people are moving to the cloud. That’s very hot, and it’s seen huge adoption across many different industries, but what we found is that how you do it matters. Now the National Institute of Science and Technology has a definition of cloud infrastructure and they talk about five essential capabilities that you have to implement – things like on demand self-service whereby customers can unilaterally provision cloud resources. We find that high performers are 23 times more likely to be using those five essential characteristics that NIST talks about. So there’s lots of people who are using cloud but don’t actually have those capabilities implemented. That’s a problem. How you do this stuff matters. Just putting your stuff in the cloud and pretending it’s a data center doesn’t actually work. You need to actually use the capabilities the cloud provides as well.

We found that using open source software improves performance. And finally, again, we’ve shown that industry doesn’t matter. We find high performers among all different market groups, all different industries whether that’s financial services, health care, other highly regulated groups, as well as, you know, startups and small companies in the low performing groups. So anyone can do this stuff.

Shimel: Absolutely. [clears throat] You know, Jez, I find it not comforting but we hear you talk and you talk about, well, companies that are moving in the cloud and stuff. You know, I guess was it around maybe 2005 where all of a sudden the cloud really started kind of bursting on the scene and here we are 13 going on maybe 15 years and, you know, it’s almost like, well, when will we really see – are we in the midst of like the – it’s mainstream certainly, but have we seen – where are we in cloud migration and how this is impacting us? Like has the bulk of it already taken place or is the bulk of it in front of us?

Humble: Yeah. I mean that’s a great question, and I think we see the same trend with DevOps and with, you know, continuous delivery as well. People say they’re doing and the question is are they really doing it because everyone wants to do it and then say they’re done and what’s the next big thing? I mean if we look at our data, what we see is 17 percent of respondents are not using cloud at all and the rest which is 83 percent are using cloud including 40 percent using multiple cloud providers. But if we look at who’s actually doing it right, only a very small proportion of people who actually say they’re doing it in fact are. Twenty-two percent of our respondents said they met all those essential characteristics. So I would say that there’s some way to go. I mean it’s literally the Pareto principle, right? Eighty percent of people are doing it; only twenty-two percent are doing it right.

So I think there’s a long tail with all this stuff. Whether it’s DevOps adoption, whether it’s cloud adoption, we’re all learning as we go along. Change takes time. It’s hard. To do this stuff right you need – and this again is common across tech and DevOps – you need to change the way you do things. You need to change your practices. You need to change your processes. That’s hard and that’s the bit that takes the time. It’s complicated. People are very keen to adopt new technologies, you know, Kubernetes, Docker, Cloudstaff, and they adopt it; but changing their processes and practices, that’s the hard work; but it’s also the important work. We see that very clearly in our research.

Shimel: Yeah, yeah. And you’re right. I mean I’ve often thought that, you know, there’s a chicken and egg relationship between DevOps and many of the megatrends that we’ve seen pop up over the last decade including the cloud and ubiquitous connectivity and the move to mobile, you know, and application driven sort of IT world. I don’t know, you know, if any one of those things happens without any of the other things including DevOps, frankly, which makes this so important. So Jez, when we look at this year’s findings in historical perspective to previous years, any kind of anomalies, anything that jumps out that says, boy, this seems different than years before, this seems kind of not to be moving along that same track that we’ve seen in years before?

Humble: Yeah, great question. So a few things. Firstly, we’ve got a new high performance group, the elite performers. So in previous years, our cluster analysis has shown us that there’s three groups – high performers, medium performers, low performers. So when we did the cluster analysis this year, we found a couple of interesting trends. So firstly, we’ve got an elite performance group which shows that the industry continues to improve its software development and delivery practices.

And our high-performance group has grown in terms of the percentage of respondents which shows that high performance is attainable for many teams in the industry, not just reserved for an exclusive group of teams with unique characteristics. So high performers continue to deliver and operate software at the highest levels, but the bar for excellence has continued to evolve across the industry and this fourth group of performers, elite performers is still optimizing and getting better. That’s what we see in general. The best organizations are the ones that keep trying to get better and are never satisfied.

The other interesting trend we saw with the cluster analysis was we found that a small group, about 7 percent that we’ve called the misguided performers. So the misguided performers is interesting as well. So this is a group that’s basically optimizing for going slowly. They’re making safe choices but they pay a really expensive price. So they’re taking this very cautious approach, and they want to release infrequently, and they see that as an effective strategy and that extra time between deployments for testing and quality checks, but they report really long times to restore service when there’s outage like months and months of time to restore service which is a huge problem.

So our research shows that making large batch, infrequent changes introduces risk to the deployment process; failure is inevitable in complex systems; and when large failures do occur, these big batch changes can contribute additional complexity when attempting to both understand failures or when dealing with catastrophic or cascading failures through the system. Sorry, 5 percent of teams that are doing exactly this and seeing the consequences. So those are kind of some interesting things that we saw in this year’s data.

Shimel: Absolutely. So you know, Jez, certainly since the founding, the creation, the launch of DORA, the survey has taken on not a greater mission but it’s so intertwined with what DORA itself does, right, to a large degree. And I don’t know if our audience – I think they’ve all been reading this survey for years. They may have had heard of DORA. They know Nicole. They know you. They certainly know Gene. But lay it out. Connect the dots for us. How does the survey go sort of arm in arm or hand in hand, whatever the case may be, with DORA and its mission.

Humble: Yes. So our mission, as DORA, DevOps Research and Assessment, our mission is to help the industry create excellence in software delivery. We really want to help organizations get better. We have a product. Our product is an assessment tool that can help you see how you’re doing and see what the constraints are in terms of your ability to get better. There’s a bunch of assessment products out there. We really wanted to take a scientific approach to this. So four years of doing this previously with Puppet and now doing it with Google led by Nicole – Nicole was an academic. She was a tenure track professor. She has a long background in research from an academic point of view. She really has found a way to work out what matters in an academically rigorous way that’s scientific.

All this research we’ve been doing actually allows us to say, here’s how you measure performance, here’s how we can show it has an impact on the organizational outcomes you care about, here are the things that predict your ability to lever with speed and stability and that’s a combination of technical and cultural and process based capabilities. So we can say these things actually matter. So here are the things that matter. Here’s how you measure them. Here’s how they impact your software delivery performance, and here’s how that predicts the organizational performance. So it’s really about taking a scientific approach to measuring these things and improving them.

Actually this year we came out with a book, “Accelerate,” which talks about that research program and the results we found over the last four years of doing that program. So it’s all about taking a scientific research based approach to improving technical capabilities around delivering software.

Shimel: Absolutely. Absolutely. And Jez, believe it or not, we’re almost out of time already. As I mentioned, it does go quickly. But I want to do a little bit more on DORA for people who don’t get it. I know you’ve worked publically – I think it’s announced DORA’s worked with Capital One among other enterprises. Give our audience, you know, again, a little bit more about DORA’s mission and how you’re helping companies there.

Humble: Yeah. Well, I mean thanks very much for the opportunity to talk about this. We have a solid number of companies who are our customers from all kinds of industries including very large, highly regulated industries including finance and government who are interested in finding out how to get better. We basically apply our research that we’ve gathered over the last several years and help them understand what’s holding them beck, what their constraints are, and then how to actually improve that in a research databased way.

So it’s something that applies everywhere. It’s something that applies – and this is one of the great things about this research is that it shows that anyone can do this stuff. So this applies anywhere. You know, I’ve often heard people say, “You know, well, we can’t do that. This won’t work here. DevOps, whatever cloud, continuous delivery, it sounds great, won’t work here.” And we can really come in and say, “Well, actually, you know, that’s really not the case. Anybody can get better, and here’s how the data shows that people in all kinds of different industries of all different sizes can improve.” And again, we’ve been able to help companies actually find out where they are and find out their constraints and understand how to improve.

It’s been very helpful from that perspective, not just – and this is a great think about working at DORA that I love is that not only is it scientific and research based, it’s also pragmatic and practical and it has real impact on the ground with companies looking to improve their software and development capabilities. So it’s really a total pleasure and great fun being able to not just do the research but also apply it in practice. That’s a real privilege for me being in that position to be able to apply this in this way.

Shimel: Absolutely. Well, Jez, you know, continued success with DORA and I’m looking forward to – oh my god, I forgot to mention, Jez, if people want to download the report, where can they go get it?

Humble: Yes, thank you so much. That’s an excellent question to ask. So you can go to our website. DevOps-research.com. If you go to the research, it’s on the front page. It’s on our research page. The link to download the report from Google Cloud. You can also go to bit.ly/2018-devops-report. That will take you straight to the registration page so you can download the report. Also a reminder that we’ve discussed the last four years of our research and our research program in Accelerate, the book that we came out with earlier this year. But yeah, please go and look at the report. Obviously, we’ve only been able to touch the tip of the iceberg in this discussion. There’s loads of, if I say so myself, very interesting stuff there. So encourage you to go and download it and check it out.

Shimel: Absolutely. All right, Jez Humble, always a pleasure, my friend, to have you on our show. Thank you very much for doing the report. Continued success. Say hello to Dr. Nicole and Gene and the rest of the gang and we’ll have you back again soon on DevOps Chat.

Humble: Thanks so much, Alan. Always a pleasure. Thank you.

Shimel: My pleasure. This is Alan Shimel for devopsy.kinsta.cloud, DevOps Chat. You’ve just listened to another chat. Have a great day everyone.

— Alan Shimel

October 8, 2018