devopsy.kinsta.cloud

Tag: DevOps Chats

MediaOps Wins Two Gold Hermes Creative Awards for Video and Podcast
We are thrilled to announce that MediaOps is the recipient of two Hermes Creative Awards. TechStrong TV won the Gold Award in the video/informational category and DevOps Chats won the Gold Award for audio/podcast series.

The Hermes Creative Awards is an international competition for creative professionals involved in the concept, writing and design of traditional and emerging media. Hermes Creative Awards recognize outstanding work in the industry while promoting the philanthropic nature of marketing and communication professionals. Hermes Creative Awards are administered by the Association of Marketing and Communication Professionals (AMCP). Judges are industry professionals who look for companies and individuals whose talent exceeds a high standard of excellence and whose work serves as a benchmark for the industry.

Our main goal here at MediaOps is to create and produce high-quality, educational and informational content to our audience, covering IT industries and practices that are re-shaping the world of technology, including DevOps, cloud-native, cybersecurity and digital transformation. These awards are a testimony to all the hard work and dedication that goes into producing these programs. We are proud of our MediaOps team and honored to receive recognition for our work.

The two MediaOps broadcast programs recognized by the AMCP are:
- TechStrong TV: Gold Award winner in the video/informational category. TechStrong TV is a streamed broadcast featuring fresh video news and information three days a week and on-demand content from conferences and shows two days a week on the Digital Anarchist network. TechStrong TV features interviews with industry thought leaders, covering the latest news on DevOps, cybersecurity, cloud native and digital transformation.
- DevOps Chats: Gold Award winner in the audio/podcast series category. DevOps Chats is a “fireside chat” podcast featuring devopsy.kinsta.cloud and Security Boulevard Editor-in-Chief, Alan Shimel, discussing relevant topics with luminaries and thought leaders in the DevOps and security industries.
The MediaOps team would like to thank the Hermes Creative Awards for recognizing the content we publish. Most of all, we would like to thank you, our audience, for all the support you have given us throughout the years.

TechStrong TV is available on the web at Techstrong.tv, with on-demand segments available on DigitalAnarchist.com and the MediaOps community sites (devopsy.kinsta.cloud, Security Boulevard, Container Journal). TechStrong TV is also available on LinkedIn Live (devopsy.kinsta.cloud page), Facebook Live (devopsy.kinsta.cloud page), YouTube (DevOps TV channel), on the devopsy.kinsta.cloud mobile app for iOS and Android, and on TV via devopsy.kinsta.cloud app for OTT channels on Apple TV, Roku and Amazon Fire TV.

Episodes are available after broadcast on-demand at Digital Anarchist, the next-gen streaming service for tech communities, which offers in-depth coverage on DevOps, cybersecurity, cloud-native and digital transformation, adding high-quality content on a regular basis. DevOps Chats are published on SoundCloud and iTunes, and are also available on Digital Anarchist.
June 17, 2021
DevOps Chat: Maximizing the Benefits of DevSecOps

When discussing security in DevOps, we often focus on the security tools instead of the DevSecOps process itself. In this DevOps Chat, ZeroNorth CEO John Worrall takes us to the root of “why” DevSecOps, focusing on the business benefit, gain and measurement of what we seek to accomplish through DevSecOps. John advocates we concentrate on the process and data enabling us to assess risk, prioritize the most beneficial security work and for decision making to creating business value.

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

Transcript

Mitch Ashley: I have the pleasure of being joined by John Worrell, who is CEO of ZeroNorth. Welcome, John, good to be talking with you today.

John Worrell: Thank you, Mitch. Good to be here as well.

Ashley: And we’re talking about security and DevOps, DevSecOps. But before we get to that topic, would you tell us a little bit about yourself, let our audience know a little bit about ZeroNorth, too?

Worrell: Sure, I’d be happy to, Mitch. I’m John Worrell, CEO of ZeroNorth. We’re in the DevSecOps space, maybe with a different approach that, a lot of times people focus on tooling. We believe that you need to kinda build a process out first for DevSecOps to actually have business value, and I’d like to maybe talk through that with you, Mitch.

Ashley: That’d be excellent. I’m all about the business value, too. [Laughter] So, let’s talk about that. So, usually, when you say DevSecOps, it’s about shift left, how you need to get to the security people working with the software folks, how do you help developers write more secure code? You get to the tooling conversation.

So, I think you’re talking about—well, let’s stop for a minute and ask why are we doing all that stuff? Yes, let’s create better app security, but why do we need to make this a process that produces, maybe, some business value, measurable results, those kinda things?

Worrell: Yeah, you bet. That’s exactly right. We’re all for the tooling, we’re all for building the bridges between security and the Dev teams. But you have to have an objective in mind, and you have to have some help along the way. You have to have some data along the way that’s gonna actually get you there to pull all that together.

One of the best quotes I ever heard that got applied to this was channeling your inner Deming, which is, you know, if you can’t describe what you’re doing as a process, you don’t know what you’re doing, right, and there is a real lot of truth to that. If you step back and look at AppSec over the years, it’s been very tool-centric, very sporadic, anything but a process. When you look at DevOps, it’s a process, it’s repeatable, it’s scalable. It’s kind of a self-learning or positive flow of information with telemetry so you can get better and better at it over time just by learning from your past experiences.

And when you think about integrating security into Dev to drive DevSecOps, you have to think about it the same way, and I think that’s where it all starts. This is a process, this is not a tool selection, this is not just a scan or an integration, it’s that process that you need to build first, and then you can start building out your tooling, your technology underneath that.

Ashley: You have a really good point, and if I’m being over general here and generalizing this, as security professionals, we kind of think of, “Let’s buy boxes, let’s buy software, let’s put functions into the network, into software, and not into the software development process that will solve our security problem.”

But security is not just people attacking you, it’s also how you do your work and making sure you create a secure environment, you operate securely, write secure code. So, I think you’re spot on about the process and how you can do that consistently, referring back to Deming, right?

Worrell: Yep.

Ashley: You can’t manage what you can’t measure, your adaptation of that phrase. So, talk to us a little bit about how do you make that real? When you talk with people, how do you help them sort of elevate the conversation to that and then get on the right track?

Worrell: So, I think it starts out with that process conversation and whichever analogy you’d like to us for that. Think about it this way—the process, in our view, works like this. You’re gonna set some kind of a governance standard for your organization. You can’t have each Dev team setting their own or each business unit setting their own, you’re gonna wanna try to get global visibility so you can actually have effective global risk management. And we’ll start that as a kinda catch-all for the business objective—but in a sense, that really captures what we’re trying to do with DevSecOps. You need global risk management across your organization. That means you have to have some visibility into it, but you have to have a way to impact your current state to make it better, and you need a process to drive that in a continuous way.

It starts with setting some governance standards and saying, “Okay, what is our ideal objective for our top tier applications? What is our ideal objective or governance model we wanna put around our mid-tier?” or whatever the application categorization might be. Then you wanna make sure you’ve got a continuous process to build the data that’s gonna inform you, whether or not you’re actually meeting those objectives. You have to look at performance reporting so you can measure how you’re doing against that.

And then you have to be able to action that intelligence to say, yeah, that data is helpful to me for a number of reasons. Number one, I get visualization of risk, I can get prioritized remediation if I do this right so my developers can make intelligent business decisions about which vulnerabilities get fixed now before we progress the build and through the build. The third piece of that is, which teams need what kind of training on security coding, good security coding practices? Instead of trying to treat everybody the same, use this telemetry to say, “You know what? Team A is struggling with cross-site scripting. Let’s go do a lunch and learn with those guys and watch the immediate impact we’re gonna get from that” and then let the process continue and go all through. There’s a lot of technology in there, there’s a lot of things in there, but it starts with the process.

The next piece that’s really critical is the data that comes out of that, right?

Ashley: I was just gonna ask you about the data part of it. [Laughter]

Worrell: [Laughter] That data drives everything. It drives so much. You know, we had talked about this idea that you’ve got different tooling—well, sure you do. You want the best tool that you can get, you want best of breed. But trying to pull those tools or the data from those tools into some meaningful, actionable intelligence is a key step in the process, right? You wanna take different data points and put them together so you get a complete view of what the risk posture is for that particular target or entity or application you’re working with.

We talk about the analogy of the blind man and the elephant. You have four blind men all experiencing an elephant from different places, and they all can come up with a different understanding of what they’re really touching and trying to investigate. And it’s a perfect analogy for a multi-tool environment when you’re scanning across the pipeline that, if you just look at one experience or one tool, you’re not gonna get a complete view of what’s going on.

Imagine the difference of being able to just do static scanning and realize that you’ve got all these highs and criticals, but not compare that with your dynamic. So, a lot of those highs and criticals may not be exposed in my environment, right? I wanna pull those together.

I’m trying to understand, number one, where the risk is, but I’m also trying to optimize my developer productivity and making sure they’re not fixing a bunch of stuff that doesn’t need to get fixed, if I’ve got a compensated control in place or it’s just not exposed already. That’s not high on my list. I want to really focus in on what’s valuable.

So, that data can be used for making good business decisions on risk. It can be used for prioritizing remediation. That data can be used for, you know, call it the wall of fame, wall of shame. It’s how do you really measure and incent and reward your business units for meeting their risk management targets, right? Again, how do you help those that are lagging behind, how do you help them get better?

And that, to me, built into this process, is where you get real business value. You’re getting the faster delivery of software, you’re getting the better developer productivity out of this, you’re getting that risk management layer and visibility you need, but you’ve got it as a process, and you can measure week to week, month to month, quarter to quarter, how much better you’re getting at it. That, to me, is a real business solution.

Ashley: You know, you described a lot, so let’s unpack some of those things. The third piece of it usually is, you know, you talk about people process and technology people. What are the kinds of roles of people who are gonna be using that kind of information, that kind of data? Because we’re often talking about getting security information into the developer’s hands so they can fix things, but you’re also talking about, “Well, what should we fix? Let’s not waste our time on things that don’t matter, right? The environment secures against cross-site scripting, so let’s not worry a much about maybe that as something that can be exploited.” Who uses that information?

And then I guess the third part of it is, it’s about continuous improvement, that’s a cyclical process of, “Are we getting better? Are we getting value? Is there benefit to the work we’re putting in on this?”

Worrell: You bet. So, you’ve actually said a lot there, too, so, I’ll try to—

Ashley: I did. I’m just following your lead, John. [Laughter]

Worrell: Yeah. [Laughter] Good, we can confuse each other in this whole process.

So, you know, if we start with this idea of the continuous improvement, just kinda going backwards here, the whole goal is to have that process, which is a continual healing process, if you will, you’re always gonna get better. DevOps does that with telemetry about, “What is the productivity of my developers? What are my key metrics on how many story points I’m taking down, how many am I delivering, and am I getting better, sprint after sprint after sprint?” All great stuff—the same model plays out in security.

That ties back to one of your comments about the role of the CISO. You mentioned, you know, typically, security guys, via technology, they deploy it. And that works or a proactive control, which is what security’s been doing so much for. My days of running the product for RSA SecurID and working at CyberArk and any kind of blocking technology or control—it is. You buy it, you deploy it, you set it and forget it, for the most part, and it works, right?

By the same token, this isn’t really responding on the SOC side, either, right? This is not responding to an in process attack, this is a different approach to security. And I think the reason that’s important is, number one, businesses are demanding more business metrics, business telemetry out of their security programs, what am I getting for my investment? How do I know I’m investing in the right things? Am I spending in the right places? All of those things are really important, right?

And the role of the CISO, by definition, is evolving as well. And you can see the people that were running security teams 10 years ago are very different than the model who’s out there now. Many people have grown into that role. Other people have come from the business side of the house, and they’re not the technology experts that were good at configuring firewalls that were really trying to deliver business value to the organization. And if you’re gonna step from infrastructure into the world of application security, you need to be able to have value to the business, and this data is a great way to deliver value to the business.

Ashley: Really important point, because the CISO role is evolving, and oftentimes, it’s becoming a CIO/CISO kind of role, which means you’re getting into the application stack, not just the network stack. Not saying that they weren’t worried about the app stack, but now you’re getting much more into the nitty gritty of it. And are your security people software people? Well, not necessarily, but they are very accustomed to getting data and responding to that data, and in this case, maybe helping development teams, developers, others with understanding what the true severity, not what some scanning tool might say, right?

Worrell: You bet.

Ashley: Which is sort of our history with vulnerability management, [Laughter] to really help them understand, “Okay, great”—and then demonstrating to the business, to compliance, to whoever you may need to be reporting to, it could be customers as well, to say, “Here’s what we’re doing. Here’s the actions that resulted from investment in these tools, people, and processes.”

Worrell: And that customer angle is actually really important. And I hate to use the word SolarWinds, but I’ll use it. It’s just put, yet again, a big spotlight on software supply chain, software security, and how critical that is. And so many organizations now are asking of us, as well as our customers, “What is your software development process? Prove to me you’ve got one.” Right? Great use of this data.

When you think about your business line risk owners, the people that are actually responsible for data, they work for the GM or the SVP of that business unit, they’ve got the risk management challenge. They need this data to do their job well. If you take that data to the board, our data is being used as part of the quarterly board package to talk about how they are addressing and how they are improving the risk posture of the organization.

And then, I wanna go down, really, one level deeper. Because when you think about this, you know, integrating into the DevOps process means that it’s not necessarily just about the developer making that independent decision. Typically, there’s a product owner in there some place that’s gonna be making some decision about what’s gonna get done now versus what’s gonna get done later, right?

So, being able to feed that product owner with the data they need to help do the triage and make those decisions, that’s another great use case of this data we’re pulling together.

Ashley: You know, you mentioned a lot of roles, too, including the product person. In your experience with ZeroNorth—and I really appreciate your background in security, too, so we can relate about those days as well—what’s most often, when people come to ZeroNorth and say, “Hey, we need your help, here’s what we need your help with?” Is it the software team, is it the product team, is it the compliance group, is it the CISO/CIO? Usually, what’s that initial driver for engaging with you.

Worrell: Yeah, there’s probably two different ones we hear most commonly. One is, “Hey, I’ve got a somewhat mature program, I’m running two or three different tools. I can’t make heads or tails out of the data, or if I try to do it, it’s manual, I can only do it once a quarter or once a month, it’s just too labor intensive. So, I think I’m getting good, I’ve got a decent process right now for scanning, but I wanna start pulling that data together.”

The second use case is those that wanna start out on building what we would call a federated or a shared governance model, and it’s led by the security team, perhaps, but they know they’ve gotta bring in the business line owners into this process, or business line risk owners into the process. And they say, “Hey, can you help me get data out there so I’ve got a single source of vulnerability truth or my applications?” And I’m looking at the same data that they’re looking at, we’re all making decisions off that same set of data so we can build a governance model that makes sense.

The security guys wanna work in partnership with the business owners and the people that are actually doing the software development and risk owners in the business. But that relationship is gonna get built on having really good data and everyone using the same data. I think that’s another use case.

The third one, which is a variation of that, is people that are coming in and really saying, “Hey, listen, I need to go to full DevSecOps right away. I know that I can put this layer of reporting and analytics on top of my current tooling and that’s a great start, and I’m gonna build this over time.” It’s a fine strategy. Other people are coming in because they’re just getting started or they just have a business imperative to do it and they’re saying, “We’re going to DevSecOps right now, and we wanna do the pipeline integrations as well as the reporting and analytics that we’ve been talking about so that I do get that data in real time, I do have a consistent scanning process, it is automated, I don’t have to worry about the developer forgetting or not doing it, and I’m gonna get that data value out of this in that particular way.”

Ashley: Yeah, “Help me accelerate through the learning curve instead of making all those mistakes myself to get to DevSecOps, if you will.”

Worrell: You bet, you bet.

Ashley: That second example especially kind of is a multiplication of the first one, which is, you have Dev teams with all this data, maybe it’s the primary group—usually, it’s multiple, right? How do you pull it together into something? They can’t make sense of it. How do you do that across the enterprise to meet compliance requirements or even just your own internal assessment and reporting up the management chain maybe to the board.

Worrell: You bet. If you step back, the biggest concern we get out of just about everyone we talk to is a CISO or a Risk Manager saying, “Hey, help me, I’m flying blind. I don’t know what highs and criticals I’ve got in my production environment right now. I just don’t know. I don’t have visibility into it. And for me to get it, it takes too much effort, and once I get it, it’s outdated, because it’s 30 days old. I’m pushing code every day” or every week or whatever it might be.

And that is the primary motivator or so many people who just say, “Gimme that visibility, and that’s the starting point. And then at least I know what I’m dealing with and then I can start building out a program that’s gonna help me address that over time.”

Ashley: You know, you brought up SolarWinds, so I’ll bring up COVID. What have you seen happening over the last 12 to 18 months with the acceleration to the cloud, acceleration of digital transformation projects? Has it taken these same issues and just made them even more visible critical to address, or have new problems emerged?

Worrell: I think it’s more of an acceleration of the entire process. In general, COVID has driven people to be more comfortable or more reliant on relationships with their customers, with their partners, with their employees. And that means more software, by definition.

So, as digital transformation accelerates because of more online interaction and new business models that this opens up, it’s just really accelerated the pace and some of the maturity of people coming. The types of questions we’re getting from our prospects now are much more advanced than they were a year ago. And that just shows that the market is really getting smart about this and they’re kind of moving beyond the tool only approach to say, “Okay, how do I get some business value out of this that can really, really help us move our risk management program forward?

Ashley: That’s one of many indicators I see, kind of data points that are saying the technology groups, the software groups are getting out from under, looking at themselves and starting, trying to get aligned with the business and meet where the business is headed.

Worrell: And as a big consumer of software, as we all are in our lives today, I’m really happy to see that, right? I mean, that’s what I—I know it’s gonna take bringing the two together and working cooperatively in that federated or shared model to make this work, and I’m really happy to see that kind of a progress. Because, like you and everybody else, software just drives so much of our daily experience.

Ashley: It is. Can’t do much without it these days. Well, it’s been great talking with you, John. Where can folks learn more about ZeroNorth?

Worrell: Well, that’s easy, ZeroNorth.io. We’d be happy to talk to you. Take a look, see what we have, and if we can help you out or you wanna hear more about it, we’d love to chat with you. Thank you very much.

Ashley: Yeah, I think we’ve had a great conversation. Hopefully, that’ll spark some folks to elevate that conversation with you and the ZeroNorth team, so take care, we’ll talk to you again soon.

Worrell: Thank you, Mitch. I appreciate it.

Ashley: You bet.

April 21, 2021
DevOps Chats: CloudBees Remains at Top of DevOps Market

In this special DevOps Chats video edition, we speak with Sacha Labourey, CEO of CloudBees. From the very beginning of the DevOps movement, CloudBees has been one of the companies at the top of the DevOps market and, based on its latest business metrics, the company remains there.

Being the enterprise Jenkins company helped CloudBees early on to be a leader at the top of the DevOps market. But with Jenkins and Jenkins X handed over to the Continuous Delivery Foundation (CDF), CloudBees can no longer count on its Jenkins connection to stay on top.

Sacha, like any good CEO, did not allow CloudBees to rest on its laurels. An aggressive acquisition strategy including acquiring Electric Cloud, Rollout.io and others, has kept CloudBees on top. At the same time, Sacha has led the product and engineering teams as they roll out a new generation of DevOps products and services including the upcoming Software Delivery Management (SDM) and Software Delivery Automation (SDA).

In this video, Labourey lays out what the past year has seen for CloudBees and what the coming year could bring. Of course, with Covid19 everyone is sailing into unchartered waters. But Sacha has the course in mind for CloudBees to follow.

Have a listen to our conversation with Sacha to understand CloudBees’ plan to stay at the top of the DevOps market.

[video src="https://videos.files.wordpress.com/TNgFIQ9x/2020-03-19-interview-with-sacha-labourey-1_hd.mp4" /]

— Alan Shimel

April 1, 2020
DevOps Chat: Is the Software We Create More Secure? Veracode’s 10th Report

Application security is top of mind now more than ever. For more than a decade, Veracode examined increasing amounts of code as it passes through their source code vulnerability scanning service. During this period, automation is increasingly prevalent, making it easier to run scans more frequently and regularly. But has automation helped? Is the software we create more secure? We gain key insights about this in Veracode’s The State of Software Security Report X (10th edition).

Chris Eng, chief research officer at Veracode, joined us on DevOps Chat. We talked about many insights uncovered in the latest report, such as 50% of applications are accruing security debt over time, the regularity of scanning correlates to vulnerability fix times and that scanning frequency directly impacts security debt.

There is a wealth of information in the report, and you can get a jump on the key findings on this podcast episode with Chris.

Transcript

Mitch Ashley: Hi, everyone. This is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by Chris Eng, who is chief research officer at Veracode. And we are talking about their latest report, the Veracode State of Software Security. This is volume 10. Chris, welcome to DevOps Chat.

Chris Eng: Thanks, Mitch.

Ashley: Great to have you on. Why don’t we start out by having you tell us a little bit about yourself, what you do at Veracode, and for those that don’t know Veracode, just a little bit about Veracode?

Eng: So, as mentioned, I’m chief research officer here at Veracode. I’ve been here for 13 years now, and my teams are responsible, essentially, for building the knowledge that goes into our products.

So, we have a number of different products that help our customers identify vulnerabilities in their software. And my team essentially identify—well, what are the patterns that we’re looking for? What are the common mistakes that developers are going to make? What are the important things that we should scan for in each language? And specify to our engineering teams how we do that.

I also own product security for Veracode, so making sure that we deliver secure products to our customers. Our customers are basically anybody that builds, buys or deploys software. And so, we help them build programs around securing that software at scale, using a number of different technologies, including static analysis, dynamic analysis, software composition and so on.

So, we work with anybody that deals with software, which is pretty much everybody.

Ashley: [Laughter] Just about everybody these days with digital transformation, no doubt. Thank you very much for that background on yourself as well as Veracode.

Well, let’s start out with, you’ve been doing this report for 10 years, and your longevity with the company, you’ve been able to oversee and be part of that over that decade process. What kind of things have you learned since you started out? You know, kinda the size of how many applications and things that you’re scanning to what’s happening today and any trends that you’ve noticed from that?

Eng: Yeah, it’s been a great process to do this every year, primarily because we’re in this unique position where we actually can see what’s going out there in the industry and when we started doing this in volume one, we only had about 1,500 applications in the data set, and then fast forward to this year, we had 85,000 unique applications.

Ashley: Wow.

Eng: So, 50 times more than we had before. And I’m not aware of any other study that has quantitative information on software security that’s anywhere close to as big as this one.

So, in addition to the size of the data set getting bigger, we looked at fix times, and we found that those have roughly stayed the same, which is sort of a little bit depressing—but that being said, there’s a lot more software now than there was before. So, there’s a lot more to scan, there’s a lot more to secure, and so, you only have so much bandwidth to do this stuff.

So, we saw fix times stay roughly the same. We did see that, over that 10 year period, there are fewer apps that have no flaws. So, that’s more of a factor of our capabilities than anything else. We can detect more than we could before. But we did also see that there are fewer apps these days with no high severity flaws. So, customers are getting better at identifying and remediating high severity flaws.

We looked at a number of different angles, including compliance trends and things like that, but for the most part, I think that the fix times is kinda the interesting part, and we dug a lot more into that and explored some of the factors that lead into fix times.

Ashley: Well, if you just think about what’s changed over a decade, I mean, 10 years ago, we were thinking about SQL injection, cross site scripting—you know, those are the kind of app security flaws, at least a lot of what the focus was, things have changed drastically since then. [Laughter]

Eng: Yeah, we are still seeing the vast majority of the same flaw categories that we saw 10 years ago. And I don’t think anybody who does app sec on a daily basis would be too surprised by that.

Ashley: Mm-hmm.

Eng: These things are really easy to fix technically, but when there’s so much of it and it spans across such a huge application inventory, it does take a lot of effort to close these. So, we still see SQL injection at roughly the same rate that we saw it 10 years ago. Other categories, like cross site scripting, have actually gotten more prevalent.

And we’ve seen some go down. We’ve seen, like, buffer overflows and numeric errors reduce in prevalence. And part of that, I think, is due to the change in programming languages as well, right? There’s a lot of that that’s stuff that’s prevalent in native code like C++ and we’re seeing less, fewer applications being written in those languages today. So, I think that’s contributing more to the prevalence differences that we’re seeing.

Ashley: I wonder, too, if service oriented architectures, microservices, things that promote reuse of code maybe help some of those things. Maybe it won’t—we’ll see. [Laughter]

Eng: Yeah, it certainly code. I mean, any time there’s reuse, you know, you inherit the functionality, but you also inherit the risk, and that’s sort of the trends as we’ve seen people start using a lot more open source than before. Again, you get the functionality, but you also get the risk, and so you introduce new vulnerabilities to your applications that way.

So, certainly, with code reuse, like you mentioned, you could get that effect as well.

Ashley: Mm-hmm, potentially even infrastructure as code. There were some really great things that came out of the report. I’d love to have you talk about some of the applications incurring debt, how many folks are driving that down—you know, what kind of effects that had.

Eng: Yeah, we took a look at security debt for the first time in this report. And, you know, most people have a concept of technical debt—just, you know, things that get old and crusty in your software over time, maybe architecturally, or things that you meant to go back and fix but you never did, and security flaws kinda have the same tendency to build up over time.

If you think about it like financial debt, right, if you charge something on your credit card and then you only pay the minimum amount every month, you’re gonna be paying a lot, for a long time. And when you add that up, it’s gonna be a lot more than it would’ve just been to pay off your balance right when you accrued it, right?

And so, security debt, when we look at security debt from that angle, we look at, are applications kind of accumulating new security debt over time, or are they driving it down? And when we look at the number of flaws that are kinda left unfixed in an application, we kinda view that as the security debt, right?

And, you know, there’s only a certain amount of capacity, right? It’s very difficult for an application that, let’s say, has been accumulating security issues over many years to just say, like, “hey, we’re gonna pay that all down today,” right? You’d have to dedicated a lot of engineers to doing that, you’d have to really focus all your efforts to do that. And so, it’s not typically very practical to do that all at once, but it is important to kinda be measuring whether or not you’re fixing more than you find or finding more than you fix, because that’s kinda directional, right?

And so, we found that nearly half of the applications are finding more than they fix. And so, essentially, they’re accruing that debt, so they’re never gonna climb out from underneath that unless they start to reverse course there, right? Put more effort into fixing issues so that they, over time, reduce that debt and get to a point where—okay, now there’s nothing kinda outstanding, and you can then make a rule that says, you know, “we’re not gonna allow this application to be promoted into production or whatever if we accrue new findings.”

Ashley: Mm-hmm.

Eng: But that’s rare, right? So, barely anybody is there yet. And so, we looked at how different DevOps tendencies or methodologies, practices affect security debt. So, I think those are some of the findings that I’d like to talk about a little bit.

Ashley: Sure, let’s go to that, because I’m very curious about, as we shift left, right, we’re trying to get security in earlier—

Eng: Exactly.

Ashley: [Cross talk] earlier, all of those things, hopefully you fix it before it ever goes into a QA function or an automated testing.

Eng: Right, there’s all those studies to kind of show that it costs a lot less, right, when you fix it earlier. And that makes sense—if you’re fixing a flaw as a developer is writing the code, if you can sit there and tell them what they did wrong before they even check that code into the repository, it’s gonna be a lot cheaper than if you find it in a penetration test, let’s say, after the code has been deployed and then you’ve gotta go figure out the root cause and then you’ve gotta find a developer that understands that code and get it in their backlog. So, that’s kind of an accepted understanding that it costs more, the later you do it.

Ashley: That’s after you get done pointing fingers on whose code is it in or is it in the network or the servers or the—you know?

Eng: Exactly, exactly—then it’s kinda tracing it down. And so, we wanted to really say, like, does DevOps make a difference in how quickly we can fix things and how much security debt we accrue?

And so, sitting from where we are, remember customers submit their applications to us and DevOps is not just automation, it’s also culture and process and a lot of things that kind of feed into whether you’re doing DevOps or not. But from our vantage point, we can’t see culture, we can’t see process, we can’t see automation. We can’t see to what extent automation has been incorporated into an applications testing cycle, for example.

We use scan frequency as a proxy for whether an organization is using DevOps. So, by that, I mean, how many scans do they run per year on an application? And so, you have a lot of applications that are scanning literally once per year, right—36% once a year.

Ashley: Wow.

Eng: And if you think about how quickly software is changing and how many features are getting added every week or every month, once a year is—that’s not very good. On the other end of the spectrum, you have about 0.3% of apps that are scanning basically every day or more. So, you know that that’s probably being done by automation. You don’t have a person sitting there submitting the application, hopefully.

And so, if you look at—there’s some charts in the report that kind of show what that distribution is, but essentially, if you scan once per month compared to if you scan every day, your median time to remediation is significantly faster. So, 19 days median time to remediation for a flaw if you’re scanning daily, versus 68 days if you’re scanning monthly or less.

And so, we then kind of broke it down into different, even more buckets, right? So, we did kind of what does one to three scans per year look like, four to six, seven to 12 and so on. And it’s kinda hard to describe this just via audio, [Laughter] but if you pull out the report, you’ll see all these kind of like iceberg charts. And so, you’ll see, like, pink and blue, and there’s—the pink represents the debt. It’s kind of below the line and that kind of shows the number of findings per app that are outstanding.

And what you’ll see is that, for the apps that are scanned more frequently, less debt accumulates. Essentially, the teams were able to get after that debt faster, and while it doesn’t go away completely—again, because this is aggregating all of the apps we have—it accumulates less. And so, we see a direct correlation between that scan frequency and both the fixed time and the security debt accumulated.

Ashley: It certainly makes sense automating that. That’s gonna show up in your numbers around the 19 days to fix, scanning once a day. Is there a way to tell if it’s happening? Do you see scanning happening more frequently than on a daily basis? Is that helpful, or are there other things that help—again, help this shift left?

Eng: You know, I think once you get to a daily basis, you’re probably—I think there’s gonna be some diminishing returns after that. I mean, imagine you did a full scan every time somebody checked something in. You’d just be getting a lot of information—you wouldn’t be able to act on that quicker than, you know, I think the span of a day or a few hours. So, scanning every few minutes really wouldn’t buy you anything.

Ashley: Mm-hmm.

Eng: So, another thing that we looked at that we thought was interesting would be scan cadence. So, not so much how frequently were you scanning, but how regularly are you scanning? And so, you can imagine—and again, there’s this great diagram, it’s my favorite diagram in the report, actually, and it’s just a bunch of dots on a chart. But what it does is, it maps out that every dot represents a scan.

And so, if an application is scanning on a very steady basis, you would see evenly spaced dots across the course of the year, whereas if you were scanning in kind of a bursty fashion—so, basically, a lot of activity followed by no activity, then you would see a clustering of dots followed by just a bunch of white space.

And so, we actually calculated that cadence for every single app in the data set, and then we grouped them into buckets, again, so of the ones that were either scanning on a steady basis or a bursty basis or something in the middle which we called irregular—and irregular is basically just a bunch of mini-bursts, right?

Ashley: Mm-hmm.

Eng: So, what we wanted to answer was, how does that scan cadence affect security debt? Are you less likely to accumulate debt if you’re scanning steadily or in a bursty fashion, alright? Which one’s gonna be more effective at wiping that out?

Because you could see it going either way, right? You could set it, you could just—people could get used to seeing results and then they get to the point where they ignore them, maybe. Whereas bursty, you’re like, “okay, well, I’m paying a lot of attention to this. We’re gonna focus all our efforts on this” and then, you know, drive it down.

So, there was actually a question there. We didn’t know what we were going to see. But when we did break it out, we found out that when you do the bursty scanning, you have all that white space and you just put a flurry of activity over time, like, you’re just—that security debt that accumulates is just massive. You see this huge increase in the amount of pink, which represents the findings that are not addressed, whereas with the steady and even to some extent the irregular scanning, you see the security debt grow a little bit, but then start to decrease. And so, the curve is actually going in the right direction towards the end of the time frame that we’re able to chart out. And so, that was another good finding for us.

So, what we can do is, we can actually take those conclusions and advise our customers and, really, anybody that’s building software that, if you want to reduce security debt, the data suggests that you should scan frequently and that you should also scan in a steady basis. You shouldn’t ever let up, right? It has to become—and that makes sense, right? Anything that we make a habit of tends to just become part of the way that we do things. And so, it was nice to have some data that actually reflects what we think would be true actually does turn out to be true.

Ashley: It’s kinda like, brush your teeth daily, right, not the day before you go to the dentist. [Laughter]

Eng: Yeah, exactly—that’s not gonna do you much good.

Ashley: [Cross talk] [Laughter]. You know what also occurs to me is, this bursty style is, there’s really no predictability around how long a security flaw is gonna exist in your code, because you may find it and fix it now, but it may be—if it’s another three months or whatever before you scan again, who knows when it gets fixed? It could live out there for a long time.

Eng: Right. We actually did find—it’s funny that you mention that—that the highest probability for a flaw to get fixed was in the first month or so. And so, the longer you wait, the less likely a given flaw is to get fixed.

And so, essentially, developers are prioritizing kind of, like, last in, first out. They’re more likely to prioritize something to get fixed if it’s kind of fresh. And that’s not what we wanna see, right? We wanna see developers fix things that are more important. We wanna see them fix more severe items or items that are in applications that are more critical to the business or items that are more exploitable than others.

But when we measured all of those and we looked for patterns that would suggest that they are prioritizing in that way that’s sensible to a security practitioner, we found that that recency, like, how recently was it found was really the highest correlation in terms of whether something was going to get fixed.

Ashley: Mm-hmm.

Eng: And so, we have to do a better job of prioritization, not just understanding what a security person would do, but getting a developer to adopt those same priorities.

Ashley: You’re obviously not measuring the human psyche element of this, but I have to believe you’ve built up such a mountain of that debt, at some point, it gets too hard to grok, understand, fathom, and there’s probably even an abandonment rate that’s just like, “too big—let’s just deal with what’s on our plate right now, and here’s the scan results” and jump on it.

Eng: It does, and that’s not—that’s not uncommon to see customers adopt that type of strategy. That, the idea that—alright, well, I’m starting this program now, on day zero. I’m responsible for appsec now. And, you know, anything that happened before I got here? Well, that’s not my problem. Let’s just focus on not introducing new flaws—which is fine. Like, not introducing new flaws is great, but that doesn’t help you with anything in the past.

Ashley: Right.

Eng: And ultimately, it’s all risk to the application, right? You can get attacked any number of these ways. But we have seen—we’ve seen big customers try to take that approach and, you know, it’s not advisable. You have to chip away at that debt. Even though you can’t do it all at once, maybe you work in security sprints into your life cycle, you find a way to pay it down over time, and eventually, you get to where you wanna be. But you cannot just ignore it and say, “No new flaws going forward.” It’s not gonna get you where you want as far as the debt.

And it costs more to fix stuff later, too, right? The longer we wait—you know, imagine you’ve got a library to patch and that library is, you know, one year out of date or five years out of date. It’s gonna cost you a lot more in terms of effort to fix the one that’s five years out of date. Things will inevitably break, so the cost of fixing also increases over time.

Ashley: There are hundreds of findings, if not more, [Laughter] in this report. Not to pick out just one, but it stood out to me that there was one stat in there of C++ carries three to five times more unresolved flaws than .NET over the same period of time. So, this is to the point of, languages make a big difference, and why is that so?

Eng: Yeah, you know, we did break it down by language and just kinda took a look at how much security debt accrued into each one. And it’s not really to say that—okay, well, if you’re using C++, you should rewrite that in .NET or some other language. That’s not really practical for most people.

Ashley: Sure, yeah.

Eng: But what it does show is that certain languages are more likely to accumulate debt over time. And it’s important not to so much look at the raw number of flaws, because some languages just are inherently more secure against certain classes of flaws, right? It’s a lot harder to shoot yourself in the foot in certain languages than others.

Ashley: Mm-hmm.

Eng: But in looking at the shape of the curve, like, does security debt tend to increase for certain languages? That’s kind of—that’s something to look at and at least be aware of, if you have certain parts of your application inventory written in, you know, PHP, for example, you should be aware that those apps are probably gonna be more likely to accumulate debt than, say, the .NET ones.

Ashley: Mm-hmm.

Eng: And so, it’s something to take into account as you’re doing your planning.

Ashley: Okay. Very good. Well, we could talk about this for maybe days, [Laughter] this is so much information, here.

Eng: [Laughter]

Ashley: So, we don’t leave everyone with a mountain of, “oh, gosh, there’s so much in here to learn and understand,” are there two or three takeaways if you’re a developer, lead developer, development manager, architect sitting out there listening to this, going “okay, so what do I need to know?” What are the couple of takeaways you would suggest?

Eng: Yeah. You know, I’ll kinda reiterate some of the things that we talked about, but essentially, security automation, especially if we look at scan frequency, it is definitely lagging the adoption of DevOps in general, right? DevOps has kinda just taken off like a rocket ship and security automation, like I mentioned, only 5% of the apps were being scanned weekly or better. And so, there’s some catching up to do there.

The good news is that, when you actually do that, and when you actually do that frequent and steady testing, you will probably get to a point where you can start chipping away at security debt and eventually, over time, drive that down so that you can take a strategy of, you know, no new flaws and keep yourself at a clean pace.

And the last one, I think there’s conversation that needs to happen between security teams and developers in terms of prioritization. You know, I talked about how developers are not prioritizing in, really, a security appropriate manner, though recency is appearing to kind of outweigh every other factor. And so, there’s, I think, some improvement that most teams could make there where, even with the same amount of bandwidth to fix flaws, they could spend their time fixing things that are more important to be fixed as opposed to the ones that are just appearing most recently.

So, I think those are some of the takeaways, and like you said, there’s a lot in the report. It’s a pretty interesting read, and I would encourage people to go grab a copy and read through it.

Ashley: And very well done, if I do say so myself—very well put together, there, Chris. Where can folks get the report?

Eng: It’s on our website, so Veracode.com, and it should be on the front page there, and—yep, there’s about a 50 page PDF behind it.

Ashley: Okay, perfect. We’ll include a link in the description for this episode, too, so.

Eng: Excellent.

Ashley: Well, thank you so much. I appreciate you being on, Chris.

Eng: Yeah, my pleasure.

Ashley: It’s been great to have you. Again, thanking my guest today, Chris Eng, who is chief research officer at Veracode, and of course, thanking you, our listeners, for joining us today. We know your time is valuable and it’s a great topic—security is important and having this information, I think, is very valuable to all of us.

This is Mitch Ashley, with devopsy.kinsta.cloud, and you’ve listened to another DevOps Chat podcast. Be careful out there.

— Mitchell Ashley

January 13, 2020
DevOps Chats: 1-Click Vulnerability Scanning on GCP, With Qualys

Sometimes the best way to accomplish something is to choose a path requiring the least friction, or amount of change.

Qualys customers now have that path available to them in bring vulnerability scanning into Google Cloud Platform. Qualys’ recent announcement means a one-click configuration change enables vulnerability scans in GCP with the results appearing in both Qualys Cloud Center and GCP Security Command Center.

Join me on this DevOps Chats to explore this announcement with Sumedh Thakar, Qualys President and Chief Product Officer. We discuss Qualys’ and Google’s collaboration and how this benefits DevOps teams.

Transcript

Mitch Ashley: Hi, everyone. This is Mitch Ashley with devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. Today I’m joined by Sumedh Thakar who’s President and Chief Product Officer with Qualys. We’re talking about an important announcement that just happened with Qualys and with Google about security natively embedded within Google. Welcome to the podcast, Sumedh.

Sumedh Thakar: Hey, Mitch. Thank you for having me.

Ashley: Great to have you. Well, let’s start by just having you introduce yourself and, of course, as President and Chief Product Officer we can imagine what you might do at Qualys, but go ahead and tell us a little bit about what you do.

Thakar: Yes, I’m not sure you can imagine because I’ve been here for 16 years, so I’ve done a lot.

Ashley: Okay. [Laughs]

Thakar: Today, as President and Chief Product Officer, I’m responsible for product strategy and implementation of Qualys product and where we have come from where we were many years, mainly focused on just vulnerability assessment. So today I have the engineering product management support operations team as well as the sales team and that kind of gives a pretty unique perspective because of the engineering and the DevOps teams within Qualys. Also, part of the organization for me helps me to really get a very good understanding of today what are the needs for DevOps and what evolution we’re going through with the DevOps team internally within Qualys, and being a massive SaaS platform ourselves I think that that’s something that I’d really like to focus on when we develop security solutions for DevOps teams.

Ashley: Well, it does give you a very hands-on perspective, both _____ as well as living with DevOps in your own products internally. It’s great.

Thakar: Exactly.

Ashley: It’s good for you. Great role to have. Well, let’s dive into this announcement. So, security that’s natively embedded within Google – Google Cloud I think we’re talking about.

Thakar: Right.

Ashley: Tell us a little bit about what it is.

Thakar: Yeah, we’ve had a fantastic partnership with the Google team and, you know, I think as digital transformation, moving things into cloud container and DevOps have been really getting traction for us to _____ differently than what we have done in the past, which has always been after the fact, adding security solutions. So, today with DevOps and DevSecOps the opportunity to embed security upfront into the infrastructure in an automated way so that you can ensure that you’re not missing – you know, that’s always the biggest issue with security is, oh yeah, I did all of that, but then I missed that one thing because I didn’t know that existed.

So today, Google Cloud has a fantastic solution that really allows DevOps team, as they’re pushing code continuously into the cloud, to have the ability with this new Qualys integration to automatically have that capability of assessment of the security of that virtual machine embedded directly and done transparently so that the end user does not really have to go about installing agents and consoles and all of that. It’s done; completely embedded in the platform.

Ashley: Excellent. So interesting, and we’d love to dive into this some more, because you’re talking about not bolting things on after the fact. You know, this is the whole shift left idea within DevOps.

Thakar: Yes.

Ashley: So, I imagine with the Qualys cloud agent for Google that’s something that you’re embedding within the software platforms that developers test production environments you’re using.

Thakar: Yes.

Ashley: Is it that kind of a lifecycle?

Thakar: Yes, exactly. So, developers today use that solution to first of all ensure that in their – whether it’s Jenkins or whatever it is that they don’t even push solutions out to production that already have vulnerabilities, right? The unfortunate side effect of doing this bolting on after the fact is that the moment you spin up a new machine it already has so many vulnerabilities in the last two years, you spend all your time trying to patch them. So, this DevOps pipeline does give us the opportunity to ensure that first of all in your build process you already eliminate and patch your images so that you don’t go out with images that are already vulnerable, and _____ customers absolutely use the Qualys agent and scanning to really achieve that.

But then once it gets pushed out to product you also want to have a monitoring to ensure that somebody doesn’t go to an S3 bucket or to a Google storage unit to pull down a vulnerable version of some sort of a software in their virtual image and create new vulnerabilities, so you also need to have that monitoring. And so that native embedding ensures that once you have done your DevOps process and cleaned the image, as the image is being pushed into the production environment in the cloud, in Google cloud, it is going to have that monitoring capability already embedded transparently without having to do additional effort.

Ashley: Great. I imagine it’s not a heavy lift for developers to install this in the development test environment, right?

Thakar: Yeah, and that’s the beauty of it is everything is automated, right? So, once you write the scripting it’s not a process that requires you to run commands every time and do all of that. Once you push that into the CD process then it’s really transparent, because in this case the developers don’t even need to run any command to get the agent onboarded. It’s an option that they check in the Google security center and then every single image that spins up will have that sort of one-click integration and automatically embedded in there.

Ashley: Great. I imagine then you’re also tying back into integrating into the security consoles both within the Qualys environment and also within Google?

Thakar: Yes, absolutely. That’s a unique ability here, because you have multiple business units for organizations. Different teams have different accounts in Google and they are, of course, only looking at their own application or their own account. And so the second part of this announcement really is also the fact that those vulnerabilities and those issues that are detected are then pushed back into the security center from Google so that the individual owners of the accounts can see all of the vulnerabilities on all of the issues that they need to fix right there within their console and they can create playbooks and use the automation that is available to quickly fix those issues so that they don’t have to know go to another tool and go to another console and try to do all of that.

For the IT folks and the DevOps folks who are pushing these applications into the cloud, they just see their own individual view directly in Google, but then of course this information also is available in the Qualys console, which is a wider visibility into the overall risk posture because it will also include the security and vulnerability findings from other types of infrastructure that the customer also has, things like laptops and handheld devices and containers and other things as well. And so the security team will leverage the Qualys platform because then they get a holistic view of the entire outside vector. The individual team in Google will get their view within the Google console so that they can really focus on fixing what they need to fix.

Ashley: Really kind of empowers that idea of SecOps, right?

Thakar: Right.

Ashley: Better right upfront.

Thakar: Exactly.

Ashley: Now I imagine that the security engineers – you know, usually there’s some kind of a corporate security team maybe involved in operations, maybe not, but also would be super pleased about having this implemented earlier into the dev cycle and also that it’s pre-integrated already into the Qualys platform, Qualys monitoring as well as Google’s cloud monitoring.

Thakar: Right. And that’s really a very good point because that’s a big struggle for security teams, right, is that just getting – ensuring that the entire infrastructure is covered by the security solution is a challenge when you do it after the fact, because they may not even know that there’s a new instance that was pushed by the dev team overnight into the Google account, the security may not know. So, with this integration of course it ensures that no matter what gets pushed Qualys is always monitoring every single image that goes out. Now the security team is good for them because they don’t have to spend a lot of time as they have been doing so far trying to get the security solution implemented.

So instead of focusing on the findings of the security solution a lot of security teams just spend time trying to get that actually installed and making sure it’s up and running and it’s connecting and all of that. So, having the DevOps team actually do all of that work is fantastic because now the security team can only focus on what is important, which is your policy. So, they can be the one that says, “Well, this is a failure if you have a _____,” and they don’t have to worry about how the thing is installed or whatever it is. Qualys is then the third party that ensures that the policy that the security team has defined is actually tested and a pass or a fail is given to both sides of the house and then they each can go ahead and do what they need to do in terms of fixing and reporting those issues.

Ashley: Now, you described in the announcement sort of one-click integration. What does one-click mean? Can you visualize that for us, how that works?

Thakar: Yeah. So we say one-click because if you have ever deployed security solutions they are absolutely painful, you know, trying to get the multiple commands –

Ashley: Or like one month or one quarter. [Laughs]

Thakar: Yeah, it’s a thousand clicks and multiple consoles and whatever it is. So the one-click is really because when you go and look at that integration, once you kind of go in Google security center and define that Qualys account that you connect to, then after that it’s really just checking one box that says that include the Qualys agent in every single image and then you don’t have to do anything after that, like you don’t even have to run a separate command every time you initiate a new image because that is already taken care of in a very easy manner with the automation that is provided by Google.

Ashley: Wow. So it truly is a checkbox kind of process.

Thakar: Right.

Ashley: Just included.

Thakar: Exactly.

Ashley: Are there any other things that maybe you’re already doing or that are part of this announcement in terms of what you’re doing to monitor scan and report vulnerabilities in the Google cloud environment?

Thakar: Yeah. I mean we have a very strong partnership with them. We’re listed, of course, in the marketplace as well, and with this sort of integration it really provides sort of a security reference architecture where, you know, Google can now provide along with Qualys customers the ability to make it significantly easy by defining the architecture of how you want to secure your workload that you’re putting in Google and then have – not only define the right solutions that should be used but then also work with vendors like Qualys to get those directly implemented with a single click so you also remove the resistance at integration and really simply that overall process. And so that will enable existing Qualys customers as well as new customers who already are going through the digital transformation, they may have Qualys already on their on-prem infrastructure; now it makes it – it removes another hurdle for them to really move into Google cloud because they can get the same kind of reports and the same kind of analysis as they have been used to because their auditors are very comfortable and used to having the Qualys reports so now they can get the same reports and don’t have to go through an entire process to recertify another solution, so there’s a lot of these kind of benefits that go across the board, and just having that embedded I think really helps.

Ashley: Yeah. It certainly lowers the bar to entry –

Thakar: Right, right.

Ashley: – into the Google cloud if it’s already integrated into the Qualys and Google platforms. Let’s circle back to talking about what are some of the benefits to the DevOps teams getting the Qualys agent into their environment earlier? What kind of things do they learn in the dev cycle and the test cycle group normally they would’ve skipped and not found out till way later when they’re ready to go to production or in production?

Thakar: Yeah. So because the way the platform is structured with APIs, the biggest advantage, there is automation of – and that’s what DevOps is all about, right? How can I script? You know, you talk about infrastructure as a code. I talk about security as a code, right? Can you just code in to say – you know, like you do your infrastructure, can you say if vulnerability is greater than this than failed _____ or, you know, can you write that as a thing?

And with the way the Qualys platform is and being a cloud-based platform ourselves and with AP as available, that makes it extremely easy for the DevOps folks to really create directly these scripts that they can basically say, “In your pipeline I got a new image, bring that image up, Qualys agent gets already embedded, it does its analysis and the findings show back up in the console and now you can really code that thing with a human, never having to go in and verify and look at the scans or whatever it is, right?” The way the architecture of the Qualys platform and the agent is, is that agent is an extremely lightweight agent that is not focused on doing just vulnerability assessment.

It does inventory assessment. It does vulnerability, also configuration assessment. And so what happens is that single agent can be used to look at a larger picture of the security of the device and not just if the software is not updated, right? You can do everything from is unauthorized software being put on this build, is end-of-life software being put on this build, is there configuration that is incorrect even though you may have patch or all your vulnerabilities, and so on and so forth. With that sort of an integration, what happens is that once you have done that one task of getting that agent on the virtual machine you can now suddenly with just APIs do a lot more to get a broader view and make sure that that overall workload is heavily locked down, because now you really are ensuring that all the configurations are as per the golden images and all of the CIS benchmarks are followed and all the software is updated and unauthorized software is already eliminated from that whole thing. DevOps is all about how do I eliminate the manual work and how do I use automation and reduce the amount of work that I have to do, and that’s exactly what that architecture enables us to do.

Ashley: I think it’s an extremely good point; with all the automation, the increase in speed, the decrease in manual intervention or tasks that are being performed. It’s easy for something to slip in.

Thakar: Yeah.

Ashley: New opensource code we haven’t used before or something now has got a vulnerability that didn’t two hours ago and you’ll find out right away.

Thakar: And, you know, one of the things that we have seen is the DevOps push to go quickly into production and sort of was that initial thing of, “Oh, I want to bypass my operations team, I want to bypass my security team,” and the flipside of that is like now your code that goes directly to production and has an issue, that’s on you as a DevOps – like you cannot blame the security person because, you know, they are not really involved anymore. And so that also incentivizes the developers up front to ensure that they’re doing all the right things from a security perspective also so it’s not their microservice that goes out that has their name on it that gets compromised, right? Because then you can basically say, “I’ve coded everything, done everything on my side up front so that what I am pushing out to production using automation is not something that is already vulnerable.”

Ashley: Excellent. So, let’s talk about how do you get access to this with the release of this capability? Is it already native within Google cloud? You just connect to it and say, “Here – you know, I’m already a Qualys customer,” or do you have to go to Qualys to sign up for something or how do you get access to this?

Thakar: Yeah. So, we – and as Qualys we provide directly – if you go to Qualys.com there’s – you can sign up for a free trial if you’re not a Qualys customer and, you know, we’re a SaaS service so you immediately get credentials that you need to access the platform, but then it’s completely embedded in the Google cloud console, so when you got there and there’s the configuration settings you will be able to now pick Qualys as a vulnerability management capability that you would like to add and, you know, there’s a one-time configuration where you provide your Qualys agent information and from that point on, once you have that done, every single – you know, do that one-click checkbox, after that that embedding will happen automatically and Google cloud will be the one doing that for you. So within a few minutes you can be up and running with this integration and starting to see the results in a couple hours.

Ashley: Excellent. Is there any incremental cost for this or is it already included, just an added capability in the Qualys product?

Thakar: Yeah. So, it’s a cost that the license of vulnerability management that customers already have. They can basically just take that license or use that or they can come and purchase additional licenses to run additional infrastructure in Qualys, but it’s the same license that they would otherwise use that they can use – that they get from Qualys and they can use in Google Cloud as well.

Ashley: Yeah. Just the licenses they would need to manage a Google could environment anyway.

Thakar: Exactly.

Ashley: Okay. Excellent. Well, great. Fantastic news. Anything else we should know before we wrap up?

Thakar: No, I’m really – you know, as heading the product, I’m always curious to get feedback, and so I encourage as many of your listeners to go and sign up and, you know, send us feedback on how they feel it helps simplify, and if there’s opportunities for us to simplify the DevOps process even more with better integration we’ll be happy to hear that.

Ashley: Great. Well, let us know how it goes and we encourage our listeners, go check out Qualys. Qualys.com. And especially if you’re an existing customer, it sounds super easy to start to use this, and I know – I’ve been a Qualys customer and also worked with Qualys before as a partner and super easy to get set up and going, so I encourage folks to check that out. Well, thanks for joining us, Sumedh. Congratulations on the announcement.

Thakar: Thank you very much. Thanks, Mitch. Good talking to you.

Ashley: Nice to talk with you. I’d like to thank my guest, Sumedh Thakar, President and Chief Product Office of Qualys, and of course, thank you our listeners for joining us today. This is Mitch Ashley with devopsy.kinsta.cloud. Have a great day and be careful out there.

— Mitchell Ashley

December 17, 2019
DevOps Chats: Automic + CA + Broadcom, a Release Automation Journey

The life of an acquired company can be an exciting one full of unexpected twists and turns, and that’s been true of Automic software. Scott Willson, a repeat podcast guest and longstanding member of the DevOps community, joins us again on DevOps Chats. He describes his acquisition journey as being akin to a “barracuda, eaten by a great white shark, eaten by a whale.” Scott is product marketing director, Release Automation at CA Technologies, a Broadcom company (the new proper name for Automic + CA + Broadcom).

Scott shares what it’s like being a software DevOps company inside Broadcom, whose strong roots come from the chip manufacturing business. While software has its many differences from chips, of course, Scott shares how many of the DevOps principles and heritage from lean manufacturing have made the transition easier. There are valuable lessons here for all of us.

Amid all the change, Automic shifted its products to the freemium model. Automic Continuous Delivery Director is now free to use for up to 10 active releases. We talk about the upcoming releases, which includes machine learning. Join us as we bob and weave through the acquisition story into the world of continuous automated delivery.

Transcript

Mitch Ashley: Hi, everyone. This is Mitch Ashley with devopsy.kinsta.cloud and you’re listening to another DevOps Chats podcast. Today, I’m joined by Scott Willson, he’s product marketing manager, Release Automation at CA Technologies at Broadcom—that’s a mouthful. I think we’re gonna explore a little bit of that.

So, our topic today is really catching up with what’s been happening with the Automic product and CA’s, this part of the acquisition back into Broadcom and just kinda catch up with Scott. So, he’s been on the podcast before. Scott, welcome to DevOps Chats.

Scott Willson: Thank you, Mitch. Glad to be here.

Ashley: Appreciate you being here. Would you start just by introducing yourself for any of our audience that doesn’t know you, a little bit about what you do, and tell us a little bit about CA Technologies at Broadcom.

Willson: Yes, yes, so my name is Scott Willson—two Ls in Willson. I think many listeners may know me. I have been, in the past, an author with some of Gene Kim’s DevOps Forum papers, and I’ve been at the DevOps Enterprise Summit several times. I’ve been fairly active on blogs and all that stuff.

And where my kinda claim to fame was, I came from a company called Automic. That’s spelled Auto-mic for the phonetic spelling of it. My background is, just to throw this in here, too, my journey, as I always tell people, is I started from a development standpoint writing the code, migrated my career kinda doing the DevOps thing before anyone called it DevOps, like many others.

Ashley: Mm-hmm.

Willson: And yadda yadda yadda, here I am now with a software company speaking all things DevOps and trying to help people get better at releasing their software.

Ashley: You’ve certainly been a part of the community for some time now, so we appreciate all your contributions. Well, you’ve been through quite a journey. I know being acquired by CA and then CA being acquired by Broadcom—why don’t you kinda catch us up? Maybe tell us a little bit about that journey. I think you described it as an 18 month history going through that.

Willson: [Laughter]

Ashley: You know, we don’t have too long on the podcast, [Laughter] but if you can kinda give us a little bit of that path that you’ve been on.

Willson: Yeah, yeah. You know, I kinda looked at it like a, it was almost like a barracuda eating a great white who was eaten by a whale, right?

Ashley: [Laughter]

Willson: It was a really interesting, very quick journey. It was a couple years ago when I was with Automic Software. We were acquired by CA Technologies, and about a year or 18 months after that acquisition or so, Broadcom bought CA Technologies to the—not just our surprise, but of course, to the surprise of the entire market.

Ashley: Mm-hmm, yeah, it was.

Willson: There was a lot of press about it.

Ashley: It was a surprise.

Willson: And so, yeah, it was a very, very quick and interesting turnaround. We are now known as CA Technologies, a Broadcom company. As far as Automic goes, we are retaining the Automic brand, so you’ll see a lot of our old software and all that will have the Automic brand. And not just Automic, but our current leadership has really felt to really keep and embrace the brands that we’ve had. So, you know, Blaze—CT is still gonna be Blaze, and Rally is gonna be Rally, those type of things.

Ashley: Mm-hmm.

Willson: So, the brands are remaining, which I think is useful, because even though CA had remained Rally—I know I, anyways, always refer to it as Rally, because—

Ashley: I do, too, yep. [Laughter]

Willson: – right, because that’s what I always knew it as. [Laughter]

Ashley: Especially knowing them from the beginning, it’s hard not to call them Rally, but yes.

Willson: Right, exactly. So, Automic is still going to be Automic from a product brand positioning. And then from a company standpoint—yeah, we’re still CA, just a Broadcom company. Within Broadcom, our group is known as the Enterprise Software Division, so we are a distinct division within Broadcom.

Ashley: Mm-hmm.

Willson: And then, to add to that, to the little journey, what has been interesting to me is—I remember it was a year ago, the last Forum meeting I was going to or what many of us in the inside called those meetings, the Gene Kim’s Great Slumber Party.

Ashley: [Laughter]

Willson: Right? We kinda talked about being lean, and some of the people, I remember having discussions with and running papers, we just really got to talking about what it means to run lean and the lean manufacturing and the whole thing, right, that DevOps is based on and that The DevOps Handbook espouses and all these kinda things.

And after that, right, three months after that meeting it was announced Broadcom was gonna buy us and then they actually did, and here I am all this time later. And I bring that up because what was interesting to me, Mitch, is that Broadcom embodies this. They run lean.

Ashley: Mm-hmm.

Willson: And it’s been an interesting journey to go from the short time at CA, which ran big, to now being with Broadcom, which runs lean. And they run even leaner than what Automic did, which was in ISV, right? You know, Independent Software Venture.

Ashley: I was curious about that, because I know Broadcom, you know, I had worked with them as a chip supplier with companies like Broadcom ad Qualcomm and, you know, manufacturers of chips in telecommunications think about the world, they’re much more, you know, operational efficient. It’s all about fractions of pennies and the cost of their goods to maintain profitability, but that’s super high volume. So, it’s a different mentality than a software company.

Willson: It is, and there are some significant differences, I suppose, from the business or sales aspects. But from a production aspect, there really wasn’t a whole lot of difference. When you think about taking a product to market, right? Now, we were doing this with software, they’ve done it with chips, but Broadcom is an engineering excellence company. They really pride themselves on having the best of fill in the blank of engineering, whether it’s engineering processes, engineering whatever. In fact, what has been interesting post acquisition is that our engineering staff for the bulk of our products have actually increased. Broadcom is very keen on ensuring that the products we deliver are best in class.

Ashley: Mm-hmm.

Willson: And so, they realized a way to do that in the market is to make sure they’ve got the top minds developing and producing and shipping these products, right?

Ashley: That has to be refreshing to you—you and the team.

Willson: Oh, yeah. It was very interesting to see that that was the case. It’s been a unique acquisition as far as that goes, and to see that—no, they wanted to increase the head count of R&D. [Laughter] It’s important for them.

Ashley: Mm-hmm. What? [Laughter]

Willson: Exactly. Like—wait, what? They want the products to improve, to get better, and to continue to be viable and market leading. And so, they embody the lean processes to do all of this stuff. And so, it’s been—there’s a little bit of a learning curve, I think, on both sides to adapt to this new way, but here we are. You name the things that are automated—I mean, Broadcom automates just about anything and everything. The very stuff you read about, Gene Kim talks about in his book, saying—and even in Nicole Forsgren’s book, Accelerate, you know, automation is at the key of a lot of these things, and Broadcom embodies that.

Ashley: It is. It’s a much different kind of company. If you’re not a hardware person or haven’t worked at a chip company, what I said, it’s—fractions of a penny make a difference in cost, and that cost can be in materials, but it also can be in process. And when you multiply that by millions upon millions of chips that they may ship a particular line, that’s a lot of money. So, it makes a huge difference in the profitability of the company—

Willson: That’s right.

Ashley: – to be able to reinvest and give you more engineers to be part of your team.

Willson: That’s right. And so, software is a little different, right? It’s not the pennies like that. Obviously, with software, the margins are different, because you’re not dealing with a physical thing, a commodity, right? But the principles to be efficient like that are absolutely espoused by DevOps. And one of the things that this transformation internally has occurred—because we’re transforming ourselves from a software company, right? I think we’ve made some press releases talking about our BizOps platform, a holistic platform—

Ashley: Right.

Willson: – that we’re offering the market. No longer should you be thinking of us like the CA of old where you had a bunch of different siloed tools. Now, they’re all coming together in a holistic way to provide real business value and create a true, interesting platform for everybody.

Ashley: Mm-hmm.

Willson: But just this way of doing things lean like that and embracing the agile way of turning things around has been a cool thing to behold.

Ashley: That has to be really good, because I haven’t talked with somebody that’s had that experience—not that others haven’t, but to have that common lexicon frame of reference of thinking about producing software like a software factory just like a hardware based factory. You have a lot of synergies and commonalities there. Yeah, there’s differences, too, but instead of software being this mystery to hardware guys or vice versa, right, you can talk and work together and understand the efficiencies, improvements, speed, impact, quality—all the things that drives the manufacturing company also drives software.

Willson: That’s right. And what’s been exciting, too, with this opportunity to change—really, the Broadcom offer has provided us an opportunity to change things and to really force these integrations and synergies between what used to be separate divisions of CA but are now different teams and the interoperability that’s happening between them to deliver this BizOps platform is really exciting. It’s cool to see that now it’s like—look, we have all these things, but what’s the point, unless we’re focusing on business outcomes, right?

Ashley: Right.

Willson: We can actually drive a business outcome if there’s harmony and cohesiveness between all these things, and that’s very exciting. In fact, one of the other things along these same lines that was announced is the free tier program—I don’t know if you see the PR a couple weeks ago, Mitch—

Ashley: I did.

Willson: – but now, a lot of our products are offered for free.

Ashley: Yeah.

Willson: So, for example, a continuous delivery director, or Automic Continuous Delivery Director, if you go to CDDirector.io, you can just use it for free, up to 10 active releases. And Rally has some free tier as well. So, basically, we’re now offering the freemium versions of what we had, and—

Ashley: Have the products changed substantially to be able to do that? Are they less functional or are they time based or just volume, kinda getting folks to up to date?

Willson: It’s really just volume, right? Yeah. They haven’t really—well, a lot of them didn’t really need the change. A lot of the products that are offering this are the ones that are already SaaS based already. There will be more that are coming, of course, as things are being migrated to be SaaS based, and that effort is under way.

But an example of Automic Continuous Delivery Director, there’s not really a time limit. It’s 10—10 active releases. That’s a lot of releases.

Ashley: Mm-hmm.

Willson: And you can just use it, and use it at will for that. You wanna get more than that or grow it across the enterprise or make it the standard or something, same with the Rally and Blaze CT. Oh, well, yeah, then you can buy the licenses that let you use it more broadly, right?

Ashley: Mm-hmm. That’s a great model. I mean, I think we’ve sort of disproven the crippleware approach. Nobody likes that.

Willson: [Cross talk], yeah.

Ashley: Exactly, and being able to use it on enough of software production; you talked about 10. You’ve gotta be able to get a pretty good feel for what the product does that’s gonna do what you want it to do and start to integrate it into your tool chain workflow platform.

Willson: Right, and these are 10 active releases. In other words, 10 releases in parallel, right?

Ashley: Mm-hmm.

Willson: Well, that’s—like you said, you should really be able to get a feel for it.

Ashley: Yeah.

Willson: Being able to run that many releases in parallel to each other.

Ashley: Well, that’s awesome. That’s great to hear. I’m excited to hear about more of that coming from you, too.

Do you have a new release coming up, here?

Willson: Yeah. So, speaking along those lines, we have a new release for Automic Continuous Delivery Director. We’re pretty excited about this release. It is our first release that includes some ML capabilities and heuristics that are involved. Basically, what we were looking to do with this is, amongst other improvements and advances we made in the product, right, to help with continuous delivery, one of the things we looked at is that there’s significant bottleneck in continuous delivery, the methodology, which is QA or testing.

Ashley: Mm-hmm.

Willson: Now, as you probably know, Mitch, continuous testing is technically a subset or a component of continuous delivery.

Ashley: Right.

Willson: And I might argue that unless you’re doing continuous delivery, you are not doing continuous delivery.

Ashley: Right.

Willson: You need to be doing—

Ashley: You need to think of continuous delivery is plan, dev, test, deploy, operate, right?

Willson: That’s right, and you’re testing continuously, right? But the problem is, QA wasn’t really built to be agile themselves. So, they kinda became the bottleneck, not just from the way that they run, but you, as a QA person, right, testers, you build out all these tests. And so, you release this small change per DevOps per agile per continuous delivery, right? And it goes into QA and you run, you know, 1,000, 10,000 tests—and I’m not making these numbers up. Literally, a lot of our large enterprises have thousands and 10,000 tests.

Ashley: Oh, yeah. Totally.

Willson: Alright, so then, we’re in the waiting game, right? And maybe it takes however long for the test results to come back and then you get feedback to development. So, we found with our, a lot of our large customers, you know, the Global 2000, that this was a significant bottleneck. So, now what we do, what occurs, is that when you do that release and you’re a pipeline, right, you’re a release pipeline and it gets pushed to QA, one of the things that we do is, we look at several heuristics.

So, we come around and say, “Alright, well, what are all the tests? What is the historical responses or outputs of the tests?” Right? How many of them failed? Which tests are flaky? How many tests are new tests? We want to actually run these tests first. So, a flaky test, for example, it ought to run at the front, and if it fails—pfft, we’ll send that feedback immediately to development or to QA so that we’re identifying these things earlier, quicker, faster, rather than having to wait on the back end for this, right?

Ashley: Try to get to that 80/20, right? Get the things—

Willson: That’s right.

Ashley: – upfront that are gonna cause the most issues, find the most bugs.

Willson: Right. So, we’re looking at all the data and intelligently figuring out the tests for you. The other thing that we’ll do is that we’ll look at the code changes you’ve made and we will map those code changes. At least in the case of Java apps, we’ll be able to map the code change to specific test suites.

Ashley: Mm-hmm.

Willson: So, now, when you submit that one component change, you are actually getting identified just the test runs that affect or exercise that component. So, altogether, when you put it all together, Mitch, what occurs then—now, when a change gets pushed into your continuous delivery pipeline, when it hits QA, you’re in a position to not have to run all 10,000 tests. You’re in a position now to run the high risk tests, the tests that you have marked are critical and important, right? So, those are included, that’s taken into account, too. And the test that we know actually exercised the change that you put in.

So, you’re able to run what you have to run to ensure you have a high quality and also order them in such a way where there’s high likelihood of failure that Development is fed back that feedback earlier and faster. And so, we’re very excited about this release.

Ashley: That’s awesome.

Willson: Yeah.

Ashley: Boy, gone are the days, I can remember when I would judge the quality of the release by how severe the bugs are and if we haven’t found really big problems yet, we’re not through. There’s more to come. [Laughter] You know, that was the heuristic. [Laughter]

Willson: That’s right. Exactly. That was the heuristic.

Ashley: That’s right. We’re far from those days, aren’t we? [Laughter]

Willson: Well, you know, because one of the other constraints, if you think about agile and continuous delivery, right—small change and you make more frequent small changes and the “State of DevOps” report just came out, right, a week ago or this week, and it again is showing how this way, this approach is actually reducing the bugs and reducing ________ quality.

All those things are great. But that now means one of your biggest resource constraints is time. And what we’ve found with our customers, it was time in QA. So, by intelligently assigning the tests on a run with a particular change, we’re able to shorten that down. You’re not having to wait for all 10,000 tests, you’re just waiting for the five that matter to run against that little small change and—pfft, get it shipped out the door.

Ashley: Exactly, right. Be smart about testing, yeah.

Willson: That’s right—be smart about testing. Exactly right.

Ashley: Now, do you have a date when this is going public? Are you in beta now? Where are you at?

Willson: Yep. So, if you were an on prem user of the product, it is actually GA now. It actually was up on the download site yesterday and—

Ashley: Oh, nice.

Willson: – it can be downloaded and you can go through the upgrade process. If you’re on our SaaS platform, you know, October 2nd, it’ll just be online working and available for you in the beauty of SaaS, right?

Ashley: Nice. Well, great. That’s fantastic. Awesome. Well, congrats on the great release. I hope it works out very well and also the free tier brings some new customers, new people onto your platform and expand that as well.

We have a few minutes left. I know you’re gonna be at the DevOps Enterprise Summit, correct, in Las Vegas?

Willson: Yeah, exactly. So, we’ll have a big booth there at the DevOps Enterprise Summit, so certainly looking forward to seeing everybody wearing our Broadcom wear. We’re gonna—not to give away too much, but I think we’re gonna have some pretty cool giveaways at our booth at various times, so, you know, definitely come check us out.

Ashley: Come early, come often for the swag.

Willson: What—get the swag? [Laughter] That’s half of what you go for. Especially if you have kids, you know? I see some of these people, they’ve got bags full of this stuff, right?

Ashley: Mm-hmm.

Willson: And I’m like—yeah, you’ve got kids at home. [Laughter]

Ashley: You don’t wear a Small—you don’t wear a Small. What are you—what are you doing, there?

Willson: [Laughter] Exactly right. Exactly right. But we’ll have some things, a couple of the giveaways we’ll have I don’t think you wanna give to the kids, let’s just say that.

Ashley: Okay.

Willson: And if you’re going to the Gartner Symposium, we’re gonna be at the three upcoming Gartner Symposiums in Orlando, São Paulo, and Barcelona as well.

Ashley: Fantastic.

Willson: So, yeah.

Ashley: Well, good. We’re gonna have to check in every six months or so just so we know what swag wear, logo wear to look for you in.

Willson: [Laughter]

Ashley: This time it’s in Broadcom—I’m kidding you, of course. But almost—it’s almost true.

Willson: It’s almost true. Feels true. [Laughter]

Ashley: Scott, it’s been great having you on the podcast. Appreciate you being here.

Willson: Thank you so much, Mitch. Appreciate it and look forward to seeing you and Alan at the DevOps Enterprise Summit.

Ashley: Absolutely. Look forward to it as well, and great to catch up with you about everything happening. Well, I’d like to thank you. I’d like to thank Scott Willson, Product Marketing Manager—or sorry, Product Marketing Director of Release Automation at CA Technologies, a Broadcom company—I think I got that right—

Willson: You got it right.

Ashley: – for joining us on the podcast. [Laughter] And thank you—you, our listeners, for being here as well. This is Mitch Ashley with devopsy.kinsta.cloud. You’ve listened to another DevOps Chats podcast. Be careful out there.

— Mitchell Ashley

November 29, 2019
DevOps Chats: Enterprise Continuous Testing With a Shift-Right Mindset

Test automation and CI/CD are evolving very rapidly to achieve great speed and impactful results by DevOps teams and Agile organizations. Our DevOps Chats guest, Tricentis Chief Product Officer Wolfgang Platz, contributes his experiences to the state of the art with his newly released book, “Enterprise Continuous Testing.”

Automating software testing just for the sake of automation is “doing the mess for less.” What is the business value of each software element you are testing, and what is the right strategy for testing these software implemented functions? Automation certainly brings with it speed, but are we ultimately making incremental improvements to testing which doesn’t tap into the full power and benefits of automated software testing.

Our discussion with Wolfgang focuses on the need for expanding dev-testing with higher-level integration, system, and end-to-end user experience testing, which are often performed well by shared testing and operations teams. Now, think Shift Right. While Agile and dev teams often focus on the progression of creating new and exciting capabilities for the business and our customers, we still require that regression mindset that consistently validates unit tests, valuable business functionality, system integrity, performance, and operational needs.

Transcript

Mitch Ashley: Hi, everyone. This is Mitch Ashley with devopsy.kinsta.cloud and you’re listening to another DevOps Chats podcast. Today, I’m joined by Wolfgang Platz, who is Chief Product Officer and Founder at Tricentis. Our topic today is a new book that he has just released, “Enterprise Continuous Testing.” It’s a great topic, talking about agile and DevOps and how we transform testing within that environment. So, Wolfgang—welcome to DevOps Chats.

Wolfgang Platz: Thanks, Mitch. Appreciate it. Thanks, everybody for listening to this podcast. I’m actually on it to be with you and have the chance to introduce a bit of what Tricentis is about and what this book is about, and thanks for having me.

Ashley: Absolutely. Well, let’s jump right—and we’re honored to have you. Thanks for joining us. Why don’t you jump into, just tell us a little bit about yourself, maybe why you founded Tricentis, and then we can get into the book.

Platz: [Laughter] Actually, that’s a great question. If you look us up on the Internet, you’re gonna see our official founding date, which is 2008, but the journey actually and the story, the history starts a bit earlier.

I founded Tricentis as a services company first in 1997, and bringing some software QA services to the world, but I had to acknowledge, frankly, that all the tooling out there just wasn’t sufficient when it came to test automation. When you do test automation, I always call it, you run into kind of a honeymoon phenomenon. Meaning, you record your first test cases and everything looks bright, but when you try to replay them and when you want to have them up and running even when changes happen, then you fail and things break.

So, the only way out was to come up with my own tool there, and that was the birth date of our software product offering. Then, in 2008, it was mature enough to switch into a product company, and from there on, it has been a fantastic journey upwards. Now, we are, as you may know, placed as a leader in Gartner’s magic quadrants now for the fourth time in a row, so.

Ashley: Mm-hmm. Congratulations, yeah.

Platz: We are about to take it all over, that’s great.

Ashley: Well, fantastic. You know, it’s a familiar model that’s kinda transitioning, pivoting from that services into a product company—and congrats on that successful transition. It’s not always a successful one. [Laughter]

Platz: Yeah, that’s true.

Ashley: So, if you started in 2008, that was probably around the area of agile. DevOps wasn’t really kinda taking off quite yet. I think that’s about when it kinda started. So, you were already, I’m sure, thinking about how teams are starting to work differently in agile methodology, maybe kinda leaning, starting towards a lean kind of an approach.

Platz: Absolutely.

Ashley: Yeah, interesting. Well, tell us about why did you write this book. I know continuous testing, CI/CD—all of that stuff is certainly at the heart and center of DevOps and everything kinda starts there. Automated testing is, of course, a key part of that. So, certainly there is a need for this topic. Why did you decide to write a book?

Platz: So, what I had to acknowledge in talking to customers and coming up with this product was, software testing is treated in a lot of organizations like a stepchild. And I mean, everybody is aware of the relevance of development, don’t get me wrong, and everybody is aware of the good things that IT can bring to use.

But software testing is kind of living in the shadows, and that was one experience. And when I then talked to customers, I found out that their ask and their intuitive need is always kinda the same. They see that software testing is here, they to some degree accept that there is a need for software testing, but all of a sudden, they say, “Well, I mean, it’s a lot of effort, so we wanna have this automated.”

Ashley: Mm-hmm.

Platz: And the first reaction to dealing with software testing in a more professional way is, “Let’s automate that thing.” And automation is a super element aspect of an improved software testing, don’t get me wrong. However, bringing large enterprise customers up to speed on software testing is actually more like a transformation journey. It is a change agenda you need to go through.

Because it’s not just about automation. A friend of mine said automation is just doing the mess for less, right?

Ashley: Mm-hmm.

Platz: But there is so much more potential in optimizing software testing when you have a more comprehensive look at it, when you have a clear understanding what is the business value of each and every functionality you wanna cover with tests. What is the concrete need for test cases in order to address the business risk that may be within certain functionality, and then what is the right strategy of executing these tests? Are you gonna run them through user interfaces? Are you gonna run them through APIs? Are you gonna run them with the use of decoupling, which service virtualization enables you to?

Only if you have that comprehensive perspective, then you can make continuous testing really work. Otherwise, it’s just gonna be little things, little improvements that certainly help, but don’t untap the full power of a better software testing world, and that is why I’ve been coming up with this book. I think it is overdue to make people aware—“Wait a minute, it’s not just jumping about onto the automation train. This is not gonna be the full story.” And you’re gonna leave a lot of stuff behind if you just think that way. Does that make sense, Mitch?

Ashley: It totally does, and I think if I kinda pull a couple things out of what you described, one is—automation is part of it, but continuous is also another aspect of changing the kinda whole paradigm of how you think about testing. Because I remember it wasn’t that long ago where you had a QA team and a development team.

Platz: Correct.

Ashley: And of course, that created automatic tension because the QA team tried to find every problem and what has to be fixed before it gets released and change control meetings and all that kinda stuff. It was highly manual, even if some of the testing was scripted. But now, in this world of continuous integration, continuous testing that’s automated you know, it’s less an argument between teams and people and that kinda friction and more about how do we make sure we’re automating the right things? How do we make sure that we escalate when problems need to be fixed, when builds break and tests fail and make sure that we’re testing the right kind of functionality?

So, it’s engaged the developers—and tell me if you agree with this—it’s really engaged the developers much more heavily in the creation and embracing that testing rather than being a separate function someone else does. True?

Platz: Yeah, absolutely. I mean, you pointed it out already, Mitch. In former days, it was like Dev, Test, and Ops providing different teams to software development life cycle. And what has happened, though, is that these big, we call them test centers of excellence where you would have a large number of manual testers, usually concentrated with some management capability, a little bit of automation maybe, even.

This piece, these large TCOEs, these test centers of excellence actually, they have either vanished or they are—or everybody’s questioning themselves if they should keep going with this model. And fully right so. Because what we now see with the need for speed in development is that the cooperation between Dev and Test needs to be so much closer, needs to be so much more fluent.

So, what we see is that these test centers of excellence are torn apart. And what we call out there as a recommendation is that you, if you have a very slim, so to say, team, a best practice team or we call it digital TCOE, that on one hand has this tight connection between Dev and Test, but on the other hand, provides some guidance on how to do testing in the best way.

Ashley: Mm-hmm.

Platz: And we see a lot of companies switching into Dev Testers where you have this hybrid form of developers and testers established directly within the agile teams.

Ashley: Mm-hmm.

Platz: And I think that’s certainly the right way to do. However, on the other hand, we wanna be very much aware that complex system landscapes require higher levels of integration testing and some flavor of an E2E user acceptance test, which tends now to be forgotten when people go into an agile and DevOps practice.

So, I think—yes, we see the TCOEs erode. They got into Dev testers, which makes a lot of sense, but please, guys, be aware that there is a need for higher levels of testing which has not vanished overnight, and someone needs to take care of that. What we see is that these needs tend to shift more towards the operations team towards a kind of shared services team now in large enterprises, but it is a, what I would say contra streaming, like the shift left pushing testers into development. We now see kind of a shift right movement also, which makes sure that some higher levels of test are still covered in these shared services organizations.

Ashley: Yeah, it’s interesting you pointed that out that way, because you know, you do hear a little bit about shift right and you think about the world that we’re operating and it’s much more complex, because we’re operating in cloud environments, maybe doing cloud native, maybe not, but we’re working maybe in multiclouds, private data centers, private clouds, et cetera.

All these combinations of environments—and, you know, some apps might be in one place, some might be in multiple. There’s a lot of permutations of that environment that an Operations team is going to say, “How do I know this stuff is gonna work, and when it breaks, how do I know you’re gonna be able to fix it quickly? Diagnose it, test it, and apply the fix quickly.

Platz: Absolutely.

Ashley: And that automation is also the automation of—yes, unit and functional tests, but also getting into being able to do some performance regression testing, those kinda, that may be specific to that environment, maybe even specific to an iteration release or kinda backing up and reapplying changes or backing out changes.

So, it’s in this complex environment that relying on manual processes seems like almost an impossible task. You have to have automation, you have to have a philosophy about doing testing. I hate to wax on here. Maybe I’m singing your song here, [Laughter] but that seems to be the environment we live in and that we have to figure out the best ways to do it. Am I on track here?

Platz: No, no—that’s cool. And I’m glad that you mentioned regression, because what we have to acknowledge is that the entire mindset of agile development, per definition, is progression rather than regression. And that is good, because agile development is about pushing out new releases, pushing out new capabilities, new features, new functionality faster than ever.

But what that mindset means is that all the agile Dev teams and the Dev testers that are within the agile teams, they also have this progressive mindset. It means that yes, if you work with them, they will accept the need for unit tests, and some of them will create great unit tests. We have seen this within our customer base. But at a certain point of time, when this is shifting towards regression, then you might find out that having unit tests set up once is one thing, but keeping unit tests up and running is a different game. And what we see is that as soon as you shift from progression into regression, you need to have people with a different mindset that really accept regression as the key aspect of their software testing behavior. If you don’t do that, you, time over time, are gonna run into issues in complex system landscapes.

And we see that, actually, I call it the evaporation of unit tests over time, which we have done a great survey with some Swiss banks, and we found out that having unit tests set up is something you rather easily can do. But over time, with more releases, you’re gonna see that their coverage, their potential, their power is eroding. And people are then referring more to the higher levels of integration to also catch these kinds of errors going forward, which makes a lot of sense.

But I just want to make you aware—don’t see agile development and Dev testers as the sole instance of your software testing. If you do that, you’re gonna run into issues in a complex, multi-system landscape with a high extent of regression with a heavy backbone with a true enterprise system landscape.

Ashley: So, Wolfgang are you saying that—you know, we used to say that you had to have separate QA teams, so it was people who didn’t create the software that could more fully test it and not kinda, you know, testing your own software is hard because you assume things.

Are you saying that, even in this automated world, continuous testing world, we still need folks who have that sort of systemic thoroughness QA kind of approach to testing, even though we’re automating it, don’t strictly rely on developers to create a self-created unit and system kinda test. Is that what you’re saying?

Platz: Exactly. That’s what I wanna get to.

Ashley: Good. Well, tell us a little bit about your book. You know, there are a lot of ways to approach a technical book about a technical subject. Is this a prescriptive how to? Is this kind of a strategy guide to lay out how you put together a full program of continuous enterprise testing in agile and DevOps? Tell us a little bit about the approach of how you went about this book.

Platz: The intent of the book is to provide a comprehensive overview of what you need to think about when you go for continuous testing. As I pointed out at the very beginning of our conversation is that just going for an automation of your software tests is not gonna be the solution. You need to have a way more comprehensive look onto the subject.

And so, what the book really is gonna do, it’s gonna introduce the perspective of a value-slash-risk based testing to you, which is the foundation. Before we wanna do a software test, we wanna make sure that it’s worthwhile doing the test, right? If this is just a functionality with very, very minor relevance to the business, you might be good with just one test case, you know what I mean?

Ashley: Mm-hmm.

Platz: However, if it’s an absolutely mission critical capability of your software, then you want to make sure that all the different flavors of use cases and all the different procedures that may be within this specific use case are really covered, otherwise it’s, from a risk perspective, not bearable.

So, having a clear understanding about the business risks-slash-the business value that is associated with each and every functionality that your software provides is the foundation. If you understand that clearly, you will be able to present kind of a map, your map of where you wanna put your dollars into. And guess what? This map is not gonna be just for your budget allocation, but it’s also gonna be relevant for your reporting, because your reporting should go towards business risk covered and not just for counting test cases.

And guess what? Your management is gonna love it. All of a sudden, they see that somebody has a plan on how budget is allocated in the software testing space. So, it’s real cool stuff.

As soon as you know that, you wanna make sure you have the right test cases at hand. We’re gonna give you an overview about different techniques of how to create the most meaningful test cases—meaningful in terms of what is the extent of additional business risks that I can cover with the specific test case, right? And when we have done that, we’re gonna make you aware that there’s different approaches to go towards automation. You can go through a user interface, you can go through an API. When you go through this, make sure you decouple systems so that you always know exactly what is the cause of a failure.

Ashley: Mm-hmm.

Platz: And when you have come up with that, you wanna make sure that you keep your test data stable, meaning that the system always has a reliable set on basic data at hand so that you’re not gonna be surprised by failures of tests which are just a matter of inconsistent or incorrect test data.

So, all these things are gonna be introduced in the book. Of course, not into the very, very level of detail, but I think at least in a way that you know what it is about and you have a good basis from where you can start digging further into stuff. But ideally, you take the book and you walk home with it and say, “Uh huh. Now I understand what it is all about.” And I’m not gonna just go out there and jump on the next open source framework for test automation and say, “This is gonna be the holy grail of my whole journey,” you know? It depends on what you wanna achieve.

Ashley: It’s about kinda creating a systemic, prescriptive framework for how to do this kind of work, because testing is, it sounds like such an understandable word, but it’s also so overloaded, because, as you talked about, there’s lots of ways to test, whether it’s through the API, the interface, there’s security testing, there’s black box testing, and you brought up the whole topic if test data. It’s hard to acquire in the first place and you have to main that, you know, evolve it with the functionality and the application—

Platz: Oh, yeah.

Ashley: – part of the regression, also. It’s really a very complex topic, and you get into performance testing, load testing, sort of chaos monkey-style resilience testing, all kinds of things that can happen. And then behind the scenes, now that we’re automating so much, we have this data that’s super valuable that we can communicate to the business. We plugged in code in here and it made it into production, and here’s how we know it was thoroughly tested and made sure that it’s gonna be reliable when we get it out in production.

Platz: Yes, and this is actually where the journey is gonna go looking forward. What we’re gonna see happening is that more and more tracing information, logging information from production will be fed back into the testing loop, right?

Ashley: Mm-hmm.

Platz: I’ve pointed out the business risk courage. I mean, how do you get to a clear understanding of business risk? You get through that by knowing how often systems are used and what is the potential damage. These things—and nowadays, if you have a proper logging out there—can be obtained from production logs. And these production logs can be fed into, back into the loop by now influencing your test awareness on specific functionality from the very beginning, from the development perspective already, into the higher levels of testing.

So, what we’re gonna see is that data, the use of data, even with some artificial intelligence involved, is gonna be a tremendous source for driving the further efficiency of the testing cycle. So, we’re gonna see, actually, the ideas of the value based testing in conjunction with having the right test cases at hand being even more optimized and speeded up by this data loop that we’re gonna get into the future.

Ashley: Mm-hmm. So, your book is available, I assume, through normal channels like, you know, an Amazon and other places like that?

Platz: Yes, correct. Just type it in, “continuous testing,” and you may wanna put my name in there also, and then you’re gonna be good to go.

Ashley: Awesome. Excellent. Well, congratulations on the launch of the book. That’s exciting. I appreciate all the work. I haven’t written a book, but I’ve talked to many people that have, and I know it is a painstaking love of passion for the topic that kind of sees you through to the end and getting the book published. And I know you had some help with Cynthia Dunlop, so shout out to her for helping you on the book.

Platz: Yes, yes, yes. It actually, that was a dramatic understatement, Mitch. Cynthia has not been of just some help. I would say she is the true author of the book. I was the one laying out the concepts, and it was stunningly how little time I had to provide to give all the basic information for her to come up with it. All the kudos actually need to go to Cynthia. I’m super excited to have my name on the book, but I feel a bit ashamed because it should be her name more prominent than mine, frankly.

Ashley: Well, it sounds like both are well deserved, and your appreciation is certainly transparent to Cynthia.

Platz:[Laughter] I hope so.

Ashley: And, you know, we never go alone, right? We never get there alone, so it’s through working with other that always—it gets all of us there together, so. Well, congratulations on the book and thanks for being on DevOps Chat with us today.

Platz: It was my pleasure. Thanks, Mitch.

Ashley: It was my honor to have you. I’d like to thank Wolfgang Platz, who is Chief Product Officer and Founder at Tricentis, and of course, wishing him the best of luck with the book. Thanks to you, all of our listeners, for joining us today. This is Mitch Ashley with devopsy.kinsta.cloud. Have a great day and be careful out there.

— Mitchell Ashley

November 22, 2019
DevOps Chats: InfluxDB Cloud 2.0 Managed Service for Time Series Data

We can’t seem to generate enough data. And as they say, you haven’t seen anything yet! Cloud-based managed services are a natural solution to ingest, store and access large amounts of data from a variety of sources across private and cloud locations. An enterprise solution hosted in the cloud is good, but a developer-friendly, API-based solution with non-enterprise usage-based pricing reaches an even broader audience.

Enter InfluxDB Cloud 2.0. The name just about says it all. InfluxData VP Products Tim Hall joins DevOps Chats to discuss the company’s new cloud-based time-series database offering.

InfluxDB Cloud 2.0 represents that shift to a cloud-based, developer-friendly offering with much greater accessibility. We discuss the use cases; the free and usage-based pricing; the new FLUX language for querying, analytics and data processing; common APIs; and that TICK stack. TICK stands for Telegraf, InfluxDB, Choronograf and Kapacitor. It is a feature-rich conversation, so join us.

Also, check out InfluxData’s Oct. 16th webinar; Optimizing Time Series Performance in the Real World.

Transcript

Mitch Ashley: Hi, everyone. This is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by Tim Hall, Vice President, Products, at InfluxData, and our topic is their new offering, InfluxDB Cloud 2.0. Tim, welcome to DevOps Chat.

Tim Hall: Hey, Mitch. Thanks for having me.

Ashley: Excellent. Great to have you on the podcast. Would you start by telling us a little bit about yourself, what you do at InfluxData and maybe for somebody who doesn’t know InfluxData does, give us a little bit about Influx.

Hall: Sure. So, I’m the Head of Products here at Influx. I joined almost three years ago. I’ve got a background in big data open source technologies. I spent some time at Hortonworks running the Product Management Team there. They’re focused on the Hadoop space. Prior to that, I spent time at Product Management at Oracle addition HP, mostly in the monitoring and data integration spaces.

So, Influx is a great opportunity to join a small company at the time. We’ve grown to almost 160 people now over the past 3 years, and it was sort of at the convergence of all the things I’d done in my career, from monitoring technologies to integration to big data. And so, it was great to be invited by Evan Kaplan, our CEO, and Paul Dix, our Founder, to join the team and see what I could do to help build a great product.

Ashley: Fantastic. And tell us just briefly—InfluxData, what do you do?

Hall: So, InfluxData is focused on providing a platform for time series data, which is about anything with a time stamp. Time series can be broken into two categories—regular series, which are things that you sample. Think of it like sticking a coffee cup in the river and pouring it into a bucket, and we’re the bucket, and you do that on a frequent basis—every 30 seconds, every minute, every 5 minutes, but it’s regular. It’s a regular time interval. And irregular series are also supported by Influx, which are things like events or logs, things that happen at any point in time that could be somebody doing key card access to a building, putting their ATM card into an ATM machine—those sorts of things. Those are all events.

And so, we handle both of those two things and we have lots of folks using us, both in the open source community, on prem, or wherever they decide to play the software and now our cloud offering as well across a wide range of use cases, everything from DevOps monitoring use cases and building and assembling platforms for observability across to IoT use cases, both for consumer and industrial products.

Ashley: Well, in a world where we just can’t seem to generate enough data, it sounds like you all are well positioned in the market. [Laughter]

Hall: There’s more coming every day, right? So—

Ashley: Yeah, it’s not getting less.

Hall: Yeah, what do you do with it is really the question. And I think, again, we’re focused on providing a platform for developers. And our goal is really to drive developer happiness. And our motivation is trying to allow developers to solve problems quickly from the time of install to problem being solved. We call that the time to awesome. We want that to be as short as possible, and that’s not always the case with a lot of technologies out there. You’re fiddling with dependencies and other things and Influx comes out of the box with no dependencies and install it, get it running very, very quickly and get going and get your problems solved.

Ashley: I do really appreciate your focus on the developer community. Actually, we—I just did a webinar a few weeks back with Tom Crow, your Community Manager, and he did an excellent job, by the way, of talking about how he worked with the developer community.

So, let’s jump to InfluxDB Cloud 2.0. Is this your first SaaS online offering, is that correct?

Hall: It actually isn’t, Mitch, but I’m glad you asked. So, previously, we’ve had InfluxDB Cloud 1.0, which was really taking our enterprise edition and providing a managed service on top.

And the challenge we had with that is, we’ve seen good adoption and nice traction. We’ve had a large number of customers purchase and buy it, but the challenge is that it was a little on the expensive side, and it existed as a dedicated instance of our enterprise software that we ran and managed for them, but it was constrained on specific resources. And so, you would buy a plan, pay for it, and then if you continued to grow and use it, then you would have to upgrade, typically by contacting support, and we could do that in a matter of seconds, but it really required a lot more high level interactivity than maybe you might get from the vast majority of cloud services that you could think of, more consuming like a utility.

And so, our focus with InfluxDB Cloud 2.0 was to deliver the first completely serverless time series platforms, deliver that elasticity for our customers to just adopt and go.

Ashley: So, truly a cloud service, not just an application in the cloud, if you will.

Hall: That’s right, that’s right. And all the capabilities we’re exposing in a multi-tenanted fashion, which means we’re obviously testing and validating across a large group of folks all at the same time, and keeping that platform up and available for everybody is our goal.

Ashley: And I know you’re doing more than just storage in the cloud. You have visualization, UI—other capabilities? You wanna talk a little bit about that?

Hall: Yeah, that’s right. So, you know, there’s sort of three parts to this story, right? Part number one is, you need to be able to feed the data in, and you need to be able to do that with velocity, and we need to store and land that data and we need to do that quickly and make it available for query and access and all the way through to visualization.

And so, we have all those parts of the story together. The most recent addition also includes the ability to create monitoring checks that allow you to create queries against the data that you’ve stored and decide if they, let’s say, exceed a certain threshold or create a change of state in some way, shape, or form. And then from there, you can create a notification that can be sent to you through a variety of channels including HTTP POST, Slack—which is available in our free tier—and then, obviously, PagerDuty, which is a super popular mechanism for alerting your DevOps teams.

Ashley: Mm-hmm. And I think, in addition to kind of integration level type functionality, you’ve also updated the API to InfluxDB in the cloud, correct?

Hall: That’s right. Actually, one of the goals is, you know, through the 1.0 line of the TICK stack, T, I, C, and K, which many DevOps people might be familiar with, there were four parts—Telegraf, InfluxData (the database itself), Chronograf (which is our visualization tool) and Kapacitor (which was our anomaly detection).

And we’ve really taken the I, C, and K portions of that stack and integrated them all together in our InfluxDB 2.0 offering. This is both open source as well as cloud. And what we wanted to do was bring together the language, first and foremost, that you use to interact with data, both from a query and a task perspective, and we’ve done that through a new language you’ve introduced called Flux—not surprising, the name of the company is Influx. So, Flux is the new language we’ve introduced. And then we’ve obviously kept Telegraf, which is our data collection agent that can be distributed and used to send data in.

Now, one of the other things about T, I, C, and K is, each one of those elements had its own API. And so, if you worked with one, it didn’t necessarily translate to the other. So, we’ve unified and have created a common API as part of InfluxDB 2.0 that allows you to do everything from drive the creation of dashboard sales and dashboards themselves all the way through to submitting queries, checks, notification rules, et cetera, all behind a common API.

And that API is consistent across the open source and the cloud editions. That allows [Cross talk]—yeah, sorry, that allows developers to essentially write an application, either against the cloud or against open source. And if they need to swap it around for any reason—for example, if your journey starts with the open source and you’re like, “Okay, now I need the scale and elasticity offered by InfluxDB Cloud 2.0,” they don’t have to make any changes to their application code. They can just change the end point and point out our cloud.

Ashley: Very interesting. You know, we’re building applications that are API centric much more today versus let’s expose the application through an API. Did that change how you redesigned the API the way you’ve integrated all these components and does just kind of InfluxDB in the cloud more or less use its own APIs because it works together across these functions?

Hall: It does. We’re actually consumers of our own APIs. And frankly, that’s been our philosophy for a while. The challenge had been previously that it was fragmented across the four components of the TICK stack and we’ve really tried to unify that and think about, again, delighting developers and giving a consistent API experience across them all.

Ashley: One of the things you mentioned, too, about—and thanks for that information about TICK stack. I’ve got another question about that in a moment. But back to your 1.0 offering versus 2.0—have you changed kinda the pricing model, done anything to make that more accessible to either developers or enterprises

Hall: Yeah, completely. In InfluxDB Cloud 2.0, it’s a completely usage based pricing model. We’re also starting developers off with a free tier, and so that free tier is rate limited, but you have access to most of the features and capabilities. We’ve obviously held off some of those things behind the paywall, but generally speaking, it’s now all pay as you go and we’ve got that pricing model published and up on the website as well as in the documentation that describes exactly how much you pay for reads, rights, storages, and so on, and you only pay for what you use.

And that’s really the goal of providing that serverless offering. People wanna use it as a utility and, you know, compare and contrast with what we did with the managed service in the 1.0 line, you know, they were paying for things they weren’t using, right? It was a fixed price offering and so, you know, that’s why it looked a little more expensive. So, I think now, we’re, I think, price optimized for developers to grow as they’re successful.

Ashley: And one of the things that probably in any developers mind listening to this podcast is thinking about developers definitely don’t like crippleware. So, you’re focused around data retention limitations, rate, that kind of thing. I’m sure you’ve heard that from your developer community about how to properly construct a free tier offering that’s still very usable to them.

Hall: Yep, yep. I think we’ve got a pretty good mindset around that. On the data retention side, we’re currently allowing the storage of data for at least 3 days at 72 hours. That can be a lot of data in the world of time series. And the ingest rates are also, I would say, fairly reasonable exposed. Just to give you an insight, I actually am using the free tier myself. I haven’t arm wrestled by Product Manager to give me access to all of the features and capabilities, although I suppose that’s possible, but I wanted to see what I could do.

Ashley: Mm-hmm.

Hall: And so, one of the things I happened to do with my son recently is, we built a gaming PC for him. And, you know, one of the most expensive components, the two most expensive components in the machine are the graphics card and the CPU.

Ashley: Mm-hmm, yep. I would’ve said the same thing. [Laughter] Do the same project with my sons, but yes.

Hall: That’s right. And so, one of the challenges, of course, is that I wanted to make sure that we installed the CPU correctly and I was worried about it overheating. And so, we’ve got a nice, big, you know, heat sink on there. But I enabled the, what’s called the sensor’s plug in within Telegraf to basically give me access to the CPU temperature data. And I’m taking that and I’m actually sending it to Influx Cloud. And then what I’m doing is, I’ve created a check to check on the temperature and I’ve created warning and critical threshold levels, and then I send the notifications to myself in Slack.

And so, generally speaking, it’s worked quite well, Mitch, but there’s been an interesting side use case and benefit that I’ve found, which is, my son comes home and decides not to do his homework.

Ashley: [Laughter] Yep. I was just wondering.

Hall: [Laughter] So, now I have a very uniquely tuned child monitoring service that allows me to recognize when he is gaming when he should be doing his homework. And he still hasn’t figured out how I’m doing it, so I’m definitely not sending him this podcast.

Ashley: You’re too sneaky, dad. Parental controls and he doesn’t even know it. [Laughter] Too funny.

Well, I’d like to touch back on the TICK stack, because I know you’ve been very active with providing open source software through the Telegraf and InfluxDB, Chronograf, Kapacitor. What’s the plan, then? You said you’ve kinda done a lot to the open source or to the code and built that into this cloud offering. What’s the plan with the open source going forward?

Hall: Yeah, thanks for asking. I mean, one of the core values of our company is that we are strong believers in open source. And, as part of that, we’ve been working on the 2.0 offering for more than a year, and it’s gone through a series of alpha editions, and I think we’re currently up to alpha 18, which matches the features and capabilities that we have available as a GA instance for InfluxDB Cloud 2.0. And we may have some community members out there scratching their head, saying, “Um, so, what gives? How come this hasn’t gone GA?”

And I wanna be really, really clear, because we have such a large community that we value their feedback, but I also value not giving them something that’s broken and something that’s not ready for prime time. And so, we’ve been very careful about labeling the 2.0 code line in our GitHub repository as alpha code as we work to complete the features and capabilities that we want to have within the 2.0 line.

And so, the key things that are coming up for us next, there are sort of three things. Number one is, we’re moving towards sort of the feature completeness for Flux, our new language. We’re learning a lot of things about running Flux within the cloud environment and getting feedback from community members on that and there’s probably a handful of things that we’d like to finish there before we’re gonna call that sort of release one of Flux.

Second is, we really need to create migration tooling, and there’s two things that we’re doing in that regard. Obviously, folks that want to land and store their data for longer periods of time will want to move their data from InfluxDB 1 to InfluxDB 2. And we’ve created sort of a new model inside of InfluxDB 2, which includes the notion of a bucket, which is where you place your data, and how to secure that bucket. And so, there are some migration tools that are required to bulk move that data across.

And then last is, I mentioned, we’ve introduced a new primary language for working with data inside of InfluxDB 2, and it unifies the ability to both query that data for dashboard creation and report generation and these other use cases that people might build on top, but it also is the same language that’s used for tasks and sort of creating batch operations.

And that was certainly not the case between InfluxDB and Kapacitor, let’s say. Kapacitor used something called TICK Script and Influx was using InfluxQL. And InfluxQL is a SQL like language and it was an easy onramp for gaining access to the data within InfluxDB. And we’re certainly not abandoning that, but what we’re doing is we’re going to create the ability for you to use InfluxQL, but behind the scenes and on the fly, we will transpile that into something that’s executable by the Flux engine, and then return the results to the customer. And this should allow for existing dashboards and queries just to work natively and seamlessly with InfluxDB 2.0 and obviously InfluxDB Cloud 2.0 when we offer it there. And when we reach that point, then we will declare beta, which means we’ll have feature completeness which include those migration tools and then that’s the time for the community really to start piling in and trying it out, and then we’ll be focusing more on performance and sort of user experience changes between the beta declaration and when we declare 2.0 GA.

But in the meantime, we’ll continue to add features to the cloud edition, they will show up in the open source through our alpha cadence. But I would say that those three big things, you know, the migration tooling, InfluxQL support, and just completing Flux as a generally available language in version one is where we’re focused.

Ashley: Okay, very good. Well, certainly a well thought out strategy and you’ve done a lot of work that we’d look forward to seeing in the open source path as well.

You mentioned buckets, remind me to ask—what types of clouds are you offering the Cloud 2.0 service in?

Hall: Yeah, great question, Mitch. So, currently, we’re available in AWS and there’s two regions we’re available in—U.S. West 2, which is up in Oregon, and we just started the beta process in Europe, which is available in Frankfort, and it’s currently using the same code, but we just haven’t turned on the ability for folks in Europe to pay us yet. But we’ll run that beta probably for four to six weeks in Europe before announcing GA there.

In addition, we announced at Google Next earlier this year that we would be available on GCP. And so, our intent is to continue to drive forward. Most likely, that will appear in the U.S. East region, just to sort of fill out a geographic strategy, but we’re very excited about working with the team at Google. Some of my former colleagues from Oracle are now there, which is fun to reconnect with them.

Ashley: Mm-hmm.

Hall: And we’ll see that land hopefully by year end, and then we’ve been spending time with Azure on the Microsoft team, and so, I would look for that in Europe and Cuba.

Ashley: Okay. Very good. I’m really tying back to the very beginning when you told us about your background—I’m really interested in what do you see are the differences in the approach with InfluxData takes with the developer community being such a focus for the company versus a more traditional database company like you worked at at Oracle? Not that they don’t have developer products, they do, but clearly, this is the center of the universe for you. What are some of the things that you’ve learned or maybe differences in the approach you’re taking now?

Hall: I’d say it’s a mix, Mitch. Like, there are definitely some things in the Oracle landscape that were powerful and can apply to the open source community.

So, for example, feature flag items—so, don’t ship a new version of the database with all your latest and greatest and coolest features turned on by default. That really prevents people from moving rapidly from, you know, from older editions to newer editions. So, we try to keep those things turned off and provide highlights to folks and release notes about how to activate them and turn them on. And it is a double-edged sword, because people who are new that come in, you’d like them to use the latest and greatest and best technology and we do try to highlight that. But we also want people to move and eliminate that sort of long tail of support as quickly as possible.

So, a very smooth process. And this sort of came from Oracle—yeah, feature flag those new things, definitely highlight it so they can take advantage. But let the developers—they’re smart. They’ll take advantage of those new features if you just tell them where they live and how to turn them on.

Ashley: Mm-hmm.

Hall: On the flip side, on the community side, you know, listen to the community feedback. And I would say that’s one thing that’s been top of mind, if not totally obvious is, you know, the motivation behind introducing Flux as a new query language was not done lightly. But it really is in response to all of the outstanding query related questions and issues that were opened by our community members. They could not move certain workloads, they couldn’t do certain kinds of functions, they needed more flexibility with the language. And so, Flux is the genesis of listening to all that feedback.

You know, unfortunately, some of those issues have definitely stood out in the community for, you know, now going on two or three years. In some cases, I finally feel like we’re at the point where we can deliver on those requests from our community members.

Ashley: Very good. I feel like we’ve covered a lot of ground on our podcast today, certainly giving our listeners a great feel for what’s unique and new and also how to get started with Cloud 2.0 InfluxDB. I imagine on your website, there’s a pretty easy place to get started?

Hall: Yeah, absolutely. I think it’s the primary call to action on the website today. If you go to InfluxData.com, it’ll pop up and say, “Get started with Cloud 2.0 immediately.” Also, you can get the open source by going to our Downloads page, or you can find us on GitHub.

Ashley: Excellent. Well, Tom—Tim, [Laughter] I knew I would do that—Tim, thank you for being on the podcast today.

Hall: [Laughter] You’re welcome, Mitch.

Ashley: Okay. I owe you one. [Laughter] I’d like to thank my guest, Tim Hall, Vice President, Products, at InfluxData for joining us today—and, of course, thank you, our listeners, for joining us as well. This is Mitch Ashley with devopsy.kinsta.cloud. You’ve listened to another DevOps Chat podcast. Be careful out there.

— Mitchell Ashley

November 20, 2019