Tag: TechStrong TV

  • MediaOps Wins Two Gold Hermes Creative Awards for Video and Podcast

    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.

  • Data Needs and Challenges with CData

    Data Needs and Challenges with CData

    The data businesses and applications need are everywhere and access through a multitude of technical interfaces, including APIs, database queries, data layers like ODBC, cloud services and SaaS applications (to name a few).

    In this episode of TechStrong TV, Jerod Johnson, technical evangelist at CData, joins Mitch Ashley to discuss the challenges of meeting the data needs applications require to support digital and transformation initiatives.

    The video is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Mitch Ashley: I’m joined today by Jerod Johnson. Jerrod is technology evangelist with CData. Jerod, good to be talking to you today.

    Jerod Johnson: Yeah, no, it’s my pleasure to be here.

    Ashley: Well, as an old ex-DBA, data is always kind of a passion of mine, interest of mine, so I’m anxious to hear more about CData. Would you introduce yourself and tell us a little bit about what CData does?

    Johnson: Yeah, sure. So, like you introduced me, my name is Jerod Johnson, I’m a Technology Evangelist for CData Software. I’ll start with CData. So, we call ourselves a leading provider of data connectivity solutions. In short, what that means is, we make it easier for every user in an organization to connect to their data, which lets them focus on the job of finding value from that data or building applications on top of that data instead of having to focus on the integration, instead of tasking IT teams to build connectors or pipes or flows, whatever the case is, in order to work with the data that they need to drive business.

    Ashley: Mm-hmm. You are number two on my list of what are the reasons people come to IT when they’re building apps.

    Johnson: Yeah.

    Ashley: And that is, security, data, and other apps.

    Johnson: Yeah. [Laughter] 

    Ashley: So, always need data. Well, tell us a little bit about yourself. I’m curious—how did you become a technology evangelist? How did you—

    Johnson: Yeah, so, I actually spent six years teaching before I got into software. So, my education background was in teaching and computer science, and spent six years in a classroom teaching math and computer science, and just decided that we needed a change, for myself and my family.

    So, I started at CData, I was actually a member of the support team, which meant I was answering e-mails and helping solve customer problems. And then I moved into engineering, and spent some time there, but it really became obvious that there was a need in the company for somebody with a skill set that I had, being able to speak to people, being able to present information, even write technical documents. 

    And so, I was pulled into the marketing team, and I’ve been doing that since 2016 for the company. So, writing technical documents, giving talks at trade shows when those used to happen, through webinars.

    Ashley: When we were [Cross talk], right? Hopefully soon, hopefully soon.

    Johnson: Yeah.

    Ashley: Interesting. You’re not the first person I’ve talked to who’s come out of an education background and moved into technology and, in your case, moving into an evangelist role. That whole skill of being able to explain sometimes very complex concepts, sometimes not so complex, but you may not necessarily have the context or the background for a certain thing that you need to learn or understand—

    Johnson: Sure.

    Ashley: Or even explain to non-technical folks, right? So, a great thing to have, especially in the DevRel world that we all live in now of really focusing on how we work with service and kinda think like a developer.

    Johnson: Sure.

    Ashley: Because that’s the people who are using it, whether they’re business developers or people inside IT. Let’s talk about sort of the data challenges, and I’m curious, maybe you’ve seen some things over the last kinda year plus, too, with the acceleration of digital transformation projects.

    Johnson: Yeah.

    Ashley: It seems that one of the challenges always is data sprawl—it’s everywhere, and every application is creating data, consuming data, sometimes creating data exhaust that’s unused or somebody else might be able to use it. It’s no small feat just to find where it is, more or less find out how you can get to it and use it.

    Johnson: Yeah, no, absolutely. I think there have been studies done, I think programmable web is probably the best place to look if you’re looking for a list of APIs. And I think that they have 22,000 public APIs listed at this point.

    Ashley: Wow.

    Johnson: So, I mean, and each of those APIs, you know, there’s data behind it. So, you have that kind of explosion, the API explosion. On top of that, you’ve got private APIs and then databases, data warehouses, these traditional stores. So, data is everywhere.

    One of the things that we’ve found is that, as data explodes, as businesses transform digitally, you get the opportunity to pick the best service for your needs. So, you know, you’ve picked your CRM application because it meets your needs the best. You’ve picked your ERP solution because it meets your needs the best.

    The consequence of that is that your data is now spread everywhere. So, your CRM data is somewhere, your ERP data is somewhere, your warehousing data is somewhere else. And so, there’s this, as you said, this data sprawl where data is everywhere.

    And what we do is, we make it all look the same. So, we like to say that CData lets you see the world as a database. So, we’ve created technologies that allow users to connect to their data, no matter where it is, as if they were connecting to a database. And so, I’ll drop some buzz words, some acronyms here—so, JDBC, ODBC, ADO.NET, these are all database connectivity standards that we’ve produced that now can connect to things that are not databases.

    And so, you know, what that does is, it really democratizes data access. Now, anybody can get to data, from any of the tools or applications that they’re using. So, whether you’re looking at an IT team or a DBA or something like a citizen analyst or a data scientist, it doesn’t matter. As soon as your data looks like a database, anybody can work with it.

    Ashley: Mm-hmm. That’s interesting you say that citizen data scientist—it’s not just developers. Of course, developers are very familiar with ODBC and other connectivity layers for data access, which are fantastic for developers, but you have to have some pretty specific development skills to be able to [Cross talk] this thing.

    Johnson: Sure.

    Ashley:  A lot of this data is sitting on a Dropbox file server in some cloud application, you know, we signed up for a CRM system—well, guess what, I need to connect that with my workflow for when an order comes in. And, you know, as good as Zapier and things like that are for doing kinda nice integrations for automation, that’s not even gonna cut close to solving these kinda problems.

    And you mentioned, too, making it look like a database. I’m curious, from my experience, it’s how you get to it and making that understandable.

    Johnson: Sure.

    Ashley: But it’s also understanding the data and what it means and how it’s represented, because a customer is not necessarily defining the attributes similar in a CRM that they might be in an order system, there may be some variations in just the format of how we capture that data.

    Johnson: Yeah. Yeah, so, you know, what we do is, everything that we make sits on top of the API. So, your API is gonna have endpoints, and those endpoints are gonna expose fields for entities.

    So, let’s take a customer, for example. When you hit a customer using one of our drivers—hit the customer, well, now, it’s a table, it was an API endpoint. What we’ve done is, we’ve kinda tabularized that data model. So, now, every customer is a row in a database table and then each of the fields for that customer becomes a column.

    And then, you know, what we do from there is basically free you to map the data from one system to another as you need, in the tool that you’re using. So, we don’t force a model on you, we’re not trying to create one universal picture of a customer across your organization. We’re gonna let your business specialists do that part. We just make it easier to see, and because it looks like a database, the schema, the metadata, however you define it is really self-describing. 

    Ashley:  Mm-hmm.

    Johnson: You know, if you can talk to a database, you can point your tool. So, let’s say you’re looking at something like Tableau. When you point it to a database, it’s gonna show you all of the tables that are available and then all of the columns that are available for each of those tables.

    Well, we do the same thing, but for something that isn’t a database. So, it could be a NoSQL store like MongoDB or Couchbase or even Amazon S3. It could be a SaaS application like NetSuite, or even Dynamic CRM. So, whatever it is, you get that full tabular model where you can see exactly what’s there and then you can decide how best to work with that data.

    Ashley:  I mean, think about the advantage of, if you don’t have, necessarily, all the programming skills you might want, to go get that data, just not having to use an ABI, but use the driver instead.

    Johnson: Right.

    Ashley: And so, just get that to me in a table form that I can—now, I can compare how one customer is _____ and one, I’m just making that example, to another customer set of attributes and other applications.

    Johnson: Yeah.

    Ashley: Sometimes it’s hard enough just defining who is—what a customer is. [Laughter] 

    Johnson: Sure.

    Ashley: I remember that modeling. But now, you can see what the data is without writing a whole bunch of software and translation and trying APIs and learning specifics about this particular service or this cloud application or whatever it might be.

    Johnson: Right. Yeah, yeah. And that’s one of the things that we really offer is, we free you from that integration problem. We free your developers, we free up IT resources. So, APIs are constantly changing. I don’t know if you’re familiar with the Facebook API, but I think they give a new version, like, every three minutes. I think it’s realistically like every three weeks, but it feels like three minutes when you’re a developer.

    Ashley:  I try not to be familiar with the Facebook API. [Laughter] 

    Johnson: Yeah, which—that’s fair. [Laughter] But with our drivers, our engineers are the ones that are keeping up with those changes. So, every quarter, we release a new product, and that includes all of the API changes that have happened on the back end. So, the only thing you have to do is literally install a new driver into your system. There are no changes—no breaking changes to the API, we merge everything as much as we can. And it really, as I said in the beginning, it lets your business experts focus on your business, whatever that is.

    Ashley: Mm-hmm. I’m curious, too, is it primarily developers that are using CData and the drivers that you have? How many folks may be from a non-super technical environment, maybe some maybe a little technical skills and might use CData?

    Johnson: Yeah, so, that’s a good question. I think it’s a pretty solid blend. So, you know, one customer story might be a mom and pop shop, they wanna be able to look at their QuickBooks data in Excel, they wanna be able to work with it, print it out, edit it, even, and update it that way. They don’t like the QuickBooks UI, they’re familiar with Excel, and so they simply install our Excel add-in, and now they’re connecting directly to QuickBooks from Excel, with full read and write capabilities.

    We can get more complicated than that with customer stories. We have one customer who was dealing with that data sprawl, the data silos where their data is everywhere, and they needed a solution that allowed them to replicate all of their data into the data warehouse that they were already using for BI and analytics. And so, we have a tool, CData Sync, that allows them to do that. So, connectivity—solving the connectivity problem and solving the replication problem, so they get automated, incremental replication of all of their business data into one place for BI and analytics.

    And then, you know, I touched on this before, but we solved that BI and analytics problem in other ways. So, you know, you have data scientists that are familiar with, that really love their reporting tools, whether that’s Tableau or Power BI or any other tool on the market. They don’t wanna have to change tools just to be able to connect to the data. And with our connectors, that’s exactly what they get to do. They get to stay in the tool that they’re already using.

    Ashley: Mm-hmm.

    Johnson: But when it comes to developers, this is where we kind of get into our most complex customers. Ultimately, the customer is an organization that’s building a data-centric tool or a platform, and their developers, you know, they’re the ones responsible for maintaining the connections to data from those tools and platforms. So, you know, you’re building the best BI tool on the planet but if it only connects to SQL server, is it really the best? So, we’ve had companies come to us and use our drivers to build products. And what it really frees up there is one-off API integration.

    So, if you’re building a tool and you’re connecting directly to the API from your tool, integrating against Salesforce looks one way, integrating against NetSuite looks another way. Integrating against Google BigQuery looks a completely different way. But as soon as you use our drivers, it all looks the same. If you can develop a tool that can talk to a database, you can develop a tool that can talk to anything.

    Ashley: And one of the situations I’ve run across several times is through M&A, when you start bringing companies together through acquisitions and of course—

    Johnson: Right.

    Ashley: – you know, you need information, you need data to operate. I mean, just imagine combining a sales organization across two or multiple companies together and ones in Salesforce and one’s in HubSpot and one’s in homegrown whatever.

    Johnson: Sure.

    Ashley: And, you know, getting that data quickly, you don’t wanna have to go through a whole conversion and, “Okay, now everybody’s in Salesforce” or whatever your tool of choice.

    Johnson: Right.

    Ashley:  Maybe that’s where you go, but you may live six months, two years, where you need data out of multiple systems to see your pipeline, see the sales bundle, see, you know, how we’re closing the deal and what’s the conversion rate and all those kinda things for. And tools like CData are extremely valuable in getting to data very quickly to get value out of that [Cross talk].

    Johnson: Right, yeah. I mean, that’s, legitimately, our own personal story. So, when we first started as a business, we had a homegrown CRM, and then we started incorporating HubSpot. And now, you know, as we grow, as we get bigger, those systems don’t work for us anymore, and so now, we’re using Salesforce. And we’re in a place right now where we are concurrently using all three, and actually using our own technology internally to build reports, to do analytics, and then, as part of that process, to migrate data from one system to another—so, moving our data from our internal CRM into HubSpot and then into Salesforce.

    So, because the drivers are standard based, because they make things look like a database, it’s incredibly empowering for IT teams and DBAs to work with the data and to either consolidate it or migrate it, or leave it where it is, but build up connections to it in a way that lets the other data experts, the C suite, whoever needs to see the data, see it quickly and easily.

    Ashley: That’s a good point. We don’t always wanna take on the work of combining things, migrating things. If you can leave data in place, that makes sense to do.

    Johnson: Yeah.

    Ashley:  Boy, what an asset, because now you can get to it, but—okay, just manage it the way you were. And it’s great that you could relate to that example that I brought up where we didn’t coordinate that, at all.

    Johnson: Yeah.

    Ashley: I’m curious, how about the security? What comes with data, security is always super important to access control, things like that. Where in the stack does that fall, and how does CData play in those roles?

    Johnson: Yeah, so, we will leverage whatever security is available from the API. So, you know, as one example, Salesforce users have different permissions, whether that’s permissions to access different entities, permissions to only read entities, to write entities, whatever the case is. 

    So, when you connect to Salesforce using any of our connectors, you choose the user that you wanna connect through and then everything that they can do, you can now do through our connector. Anything that they couldn’t do before, you can’t do. And then we support the full gamut of authentication protocols. So, if an API supports OWASP, we’ll support it. If an API supports other authentication schemes, even—so, like, your Microsoft based products, on premise, we do NTLM. If you’re looking at Kerberos authentication, we can manage single sign-on—just whatever is available there, we allow.

    And then the protocols that the API uses for security—so, SSL, the encryption, all of that is supported as well, so.

    Ashley: I think an advantage you have, since you’re not pulling the data out of those systems and storing it somewhere else, it’s still data that’s living there—

    Johnson: Right.

    Ashley: – all the security systems, the access controls permissions, policies, et cetera, are still within those applications, however they’re managed, either standalone or collectively across those. So, you’re not having to devise some new data permission scheme from that, right?

    Johnson: Right, right.

    Ashley: That’s gotta be a huge plus.

    Johnson: Yeah.

    Ashley: Cool. What do you see as—while we have some time left, here—I’m interested in what you see as sort of emerging applications. You know, we’ve seen a lot of acceleration with digital transformation.

    Johnson: Yeah.

    Ashley: Digital engagement with customers, automation—there’s many more things happening, and of course, those both need data and create data.

    Johnson: Yeah. So, you know, I think one of the things that we’ve seen of late is just this migration to the cloud, where everything is in the cloud, your data’s in the cloud, you’re doing BI in the cloud. So, through products like Tableau Online or the Power BI service, instead of Power BI Desktop, Google Data Studio, AWS QuickSight, whatever the case is, you know, you’re working with data from a cloud platform now instead of something on premise.

    So, what we’ve created is, we have a cloud platform that creates a cloud to cloud connection. A lot of the tools that exist today, you know, even if you wanna go from a cloud platform to a cloud data store, you’re still required to put a gateway on premise somewhere. You know, this is the case with a lot of the Power BI connectivity. And, you know, if that doesn’t—why would you go down from the cloud, to on prem, back up to the cloud in order to work with your cloud data? And so, that’s—the CData Connect Cloud Platform is what it’s called, but it allows live, real time cloud to cloud connectivity. 

    And so, you know, that’s one of the, kinda the emerging trends that we’ve seen is people wanting to just do everything in the cloud. And it makes sense, especially—you know, I think about this past year, right? Everybody’s working remote, you know, you don’t have an on premise server sitting somewhere that can run your platform, you have to move it to the cloud so that everybody that’s working from home can access it, and that’s just one example of this cloud migration that we’ve seen.

    Ashley: Nothing like a pandemic—I say that knowing the human tragedy side of it, all due respect, but—

    Johnson: Yes.

    Ashley:  – to really force some very aggressive changes in our business and how we operate and some really interesting things. Is there a particular area of, you mentioned cloud and more usage of cloud services—what’s sort of the next frontier, if you will, that CData is tackling of how to make this data problem easier?

    Johnson: Yeah, so, I think—you know, we’re thinking about that cloud integration problem and trying to look for ways to help that. But you know, an area that we’ve started pushing into recently is kinda low code developers. So, I had mentioned you have your IT teams and your full stack developers that are used to working with data, that are used to writing code. But something else that we’ve seen crop up is this low code application development—whether that’s in a cloud platform or an on premise platform. And it’s great. You can build a workflow or an app using a drag and drop menu. These platforms tend to be intuitive. And now, your citizen analysts can build a workflow to combine data to get what they need into their BI tool.

    The problem that we’ve seen there is connectivity to data from these platforms, and so, that’s kind of an area that we’ve been pushing in an integration kind of marketing side is reaching out and trying to connect with low code and shoring up our integration with these platforms.

    Ashley: Yeah, and by the way, that happens to be an area of research that we’re working on with CData, and we’ll talk a little bit more about that here coming up in a few weeks—some really good, interesting findings from that research.

    And that was really interesting to Accelerated Strategies, the analyst firm that I run, because there is so much interesting in low code/no code right now.

    Johnson: Yeah.

    Ashley: And of course, it’s so broad of what that means. It could mean a spreadsheet to somebody, you know, as well as low code or platform, you know, there’s a number of platforms for creating applications and accessing data through a CData kinda combined platform. So, it’s really interesting, to me, of kinda who is using low code technologies to create applications.

    And I think the world used to view it, or maybe currently views it as, those are the business users, non-technical. That’s certainly a population, but it’s more and more coming into IT is what I’m seeing.

    Johnson: Yeah, that’s cool. I mean, as somebody who was a developer, was a support engineer, it’s fascinating for me to get my hands on a low code platform and figure out, you know—well, what exactly can I do with this?

    Ashley: Mm-hmm. Yeah, it’s interesting technology. Another way to solve problems, another technology, right, to build the applications.

    Johnson: Right.

    Ashley: How about the mobile side of this? With so many more mobile apps, we’re almost in an era, maybe we’re in the era of, “I’d like fries with that, I’d like a mobile app with that.”

    Johnson: Sure.

    Ashley: Or maybe it is mobile first. Does that change the dynamics of some of the data needs or challenges?

    Johnson: So, I think once you start looking at mobile applications, you’re looking for lightweight applications, right? You can’t—I mean, phones are impressive now, right? Like, I think about the amount of data that I can store on my phone versus the first smartphone that I got, you know, the amount of space that I have for apps. But at the same time, you know, embedding a software library or a driver or whatever the case is into your app, it doesn’t always make sense. Especially if you’re building an app that supposed to be able to connect to hundreds of different data sources.

    Ashley: Mm-hmm.

    Johnson: You know, are you gonna install 100 different 7 megabyte drivers with your app? Like, is that really the best way to go? And that’s another place where our cloud platform makes sense. So, you can be on your mobile app, you can connect—you can build an application that connects to a cloud platform that then allows users to connect to data from anywhere.

    Ashley: Mm-hmm.

    Johnson: So, you know, using the same technology that we have, it’s just consolidated into one single platform. So, you hit that platform and now, you know, you can pull in Salesforce data, you can write back to HubSpot, you can dump a report as CSV into AWS S3, all through one platform.

    Ashley: And you know, so many of those apps aren’t necessarily greenfield apps, right? All that data, maybe even the transactions processing, much of it is happening in other apps, other cloud locations.

    Johnson: Right.

    Ashley: So, when you’re building a mobile app, you know, you’re not inventing everything from the bottom up, right?

    Johnson: Right.

    Ashley: You’re merging a lot of existing resources—functionality as well as data. So, it seems like no better—what better of a kind of application where making it easier to get the data? Because, you know, mobile developers don’t like writing database access code, right? They like building interfaces and doing cool interactions and useful interactions with customers.

    Johnson: Right, right.

    Ashley: So, when you can let them focus on that and really create great experiences with that data, that’s a win/win for everybody, it seems like.

    Johnson: Yeah, no, I agree.

    Ashley: Well, cool. I really enjoyed talking with you, and where can folks find out about CData? What kinds of abilities do they have to check you out, from free accounts or sandboxing or things like that?

    Johnson: Yeah. So, CData.com is our website, and you’ll find all the information that you need there. For any of our installable products, we offer 30-day free trials, and they’re fully functional trials. You know, we’re not rate limiting, we’re not doing anything like that. And then with our trials, you get access to our support team, which we’ve been called world class, we have testimonials on our website if you really wanna dig into those.

    Ashley: Comes from a man who was on the support team, so.

    Johnson: That’s right. [Laughter] 

    Ashley:[Laughter] No, I’m sure it’s really great.

    Johnson: And then, you know, for the Cloud Platform, I think we offer a two-week trial, and so, you can kinda kick the tires on that as well. So, CData.com/drivers is where you wanna go if you’re interested in an installable driver. CData.com/connect is where you can go if you’re interested in that Connect platform, that Cloud Platform for connectivity. And then, you know, you can find us on LinkedIn, you can find us on Twitter, we’re @CDataSoftware. You can find us on Facebook. A lot of our posting there is upcoming events or recent articles or other news announcements, so.

    Ashley: Yeah, and I have checked out your drivers, and you know, an analogy like a Swiss Army knife falls apart very quickly, because you have so many technologies, so many platforms that you interface with—it’s about 50 Swiss Army knives. [Laughter] 

    Johnson: Yeah. So, I’m just gonna plug this—so, I think we’re 250 plus different data sources across 11 technologies. So, somebody out there is doing the math right now in their head to figure out how many SKUs we’re sitting on right now.

    Ashley:  The number of permutations—well, good. It’s really been good talking with you, and I look forward to having you all on again and talking some more, I think, about the low code/no code space and some things that are happening there, so we’ll look forward to that.

    Johnson: Yeah. Alright, yeah. Thanks, Mitch, it’s been my pleasure.

    Ashley: Great. Jerod Johnson, who’s Technology Evangelist with CData.

  • ADOC: Assessing DevOps Culture

    ADOC: Assessing DevOps Culture

    The Assessment of DevOps Capabilities (ADOC) is crowdsourced, vendor-neutral and designed for individuals, teams and organizations who want to baseline their current DevOps state, identify the next target state, gain insights into how to improve their organization and team capabilities and measure and accelerate continuous improvement during their DevOps journey.

    The assessment models five DevOps dimensions – the human aspects, process and frameworks, functional composition, intelligent automation and technology ecosystems – to help you gauge your DevOps maturity and identify areas for improvement. In this TechStrongTV interview, Alan Shimel talks with Garima Bajpai, Louise Cermak and Brendan O’Reilly about reshaping culture to get the most out of any DevOps journey. The video is below, followed by a complete transcript.

    Announcer: This is Digital Anarchist.

    Alan Shimel: Hi, everyone. Thanks for joining us on another segment here for TechStrong TV. This is a special segment panel for TechStrong that I’m gonna be conducting, here. I’m happy to have you join us. I’m also really happy to have three interesting people join us. Let me introduce you to them. And if I mispronounce people’s names, I apologize; we do the best we can here on TechStrong TV, right?

    But we’re gonna start with Garima, is it Bajpai? Fair? Good? Okay. Garima, why don’t you introduce yourself?

    Garima Bajpai: Thank you, Alan. I’m Garima Bajpai from Ottawa, Canada. I am the Founder for the DevOps Community of practice here in Canada, which has three chapters, Toronto, Edmonton, and Ottawa. I’m also the organizer for the DevOps Summit which happens in Canada November 8th and 9th, and I am Ambassador with DevOps Institute, as well as an Ambassador with the CD Foundation. So, today, we are going to have a very interesting dialogue on DevOps assessments. So, I can’t wait to get started, right?

    Shimel: Yeah, thank you, thank you. Thank you for all you’re doing for the DevOps community. Next up, let me introduce you to Brendan O’Reilly. Brendan, welcome—a little bit about yourself?

    Brendan O’Reilly: Sure. So, my company is called Daysha DevOps. We’ve been working with the DevOps Institute now for about five or six years, predominantly delivering their training. And I myself am a consultant, and like the other speakers here today, really looking forward and excited about what’s happening with ADOC, because I see a big opportunity for our customers to get deeper into their DevOps journeys, to progress those journeys.

    Shimel: Fantastic, and thank you. And then last, but certainly not least is, we have Louise Cermak—Louise, did I get that right?

    Louise Cermak: Almost, yeah.

    Shimel: Well, say it right, because you’re entitled to have your name said right, it’s my fault. So, please, how do we pronounce your name?

    Cermak: Thanks, Alan, it’s “Chermock.”

    Shimel: “Chermock,” okay.

    Cermak: Yeah, so, I’m Louise Cermak. I’m a Principal Consultant with Catapult CX. We build software ourselves, and we also consult in agile and DevOps and have been doing so for sort of 10, 15 years. And we’re excited for ADOC, because actually, having the combination of being engineers as well, we can really understand the capability and how to apply it.

    Shimel: Absolutely. Well, all three of you, thanks for joining us. So, a couple of you have mentioned ADOC, right, and this is something that our friends at the DevOps Institute announced, I guess it was last week or the week before now. And ADOC, for our audience who may not be familiar, stands for Assessment of DevOps Capabilities. And this is a new assessment model that the folks at DevOps Institute have been working on.

    Look, you know, I know they’ve been working on it for over a year already. It’s been primarily driven by Helen Beal, who is a—Helen is a very well-known DevOps person in the community, but she’s also the Founder of the DevOps Institute Ambassadors, and has been a DevOps consultant herself for many, many years, as long as I’m doing devopsy.kinsta.cloud.

    And then Helen was really helped with this by Eveline Oehrlich, who’s a DevOps Research Director at DevOps Institute, a former Forrester VP. And then I also know that she’s been helped a lot with people like the three of you, who are real world DevOps consultants who are helping organizations every single day with their DevOps transformations and capabilities.

    So, before we jump into ADOC, though, let’s take it up a notch and talk about DevOps assessments in general, right? Are they—why are they important? Why are they important, and if anyone wants to give us sort of a brief history of evolution or time around these assessments and how they’re used, let’s say, by consultants and/or end user organizations.

    Garima, I know you have a lot of experience, so if you don’t mind, I’m gonna ask you to kick it off, and then have the rest of the panel chime in.

    Bajpai: Right, and I actually term DevOps transformations as a journey towards remaking culture. So, it has been largely a complex journey, because of two factors, actually. The first factor is that the complexity brings along with, you know, a lot of focus on how you can upskill people, how can you actually transform your knowledge based and skill set to a journey which is basically based on experimentation, on learning, and learning from failures, right?

    And the second aspect is that there is no such literature available. You know, there is a lot of talk about DevOps transformation, but the literature is in the making. So, there is limited academic support as well as support from a best practices perspective how to do this transformation, right? So, these assessments come very—it is very crucial, because it will help you assess where you are, and every organization will have unique challenges, right?

    So, it is important to assess where you are in your journey and what you can do. You know, it’s not like a traditional transformation journey of three to five years where you are relying on a lot of targets ________ models which were already defined. It’s continuously evolving, right? So, you will have to have a view on what you can do today and how you can incrementally, in short cycles, transform.

    So, what happens in this process is that, you know, assessment becomes more crucial and essential, because there are discrete efforts. There are efforts in short cycles, and this assessment and measurement will help you course correct, will help you understand where you are heading to in your journey and what is needed as next steps to ensure that you incrementally build value, right?

    So, that’s why, I think, these assessments are extremely important. We will talk along this conversation how ADOC can actually help you on this journey as well as what are the major impediments and challenges organizations have and what should they look out for.

    Shimel: Fair.

    Cermak: I think, over the last few years where we’ve been helping organizations, what we’ve noticed is that many of them are trying to do their own assessments, and I’ve been into so many organizations where people have got Excel spreadsheets and they’re trying to measure how they’re performing.

    Because, you know, Garima’s right—there’s a lot of learning and experimentation. A lot of it is self-learning, which is what we encourage, right, from a DevOps culture perspective. But people wanna know that they’re going in the right direction, so they start with their own spreadsheets, fill them in, try and measure their capabilities. And a tool like ADOC helps organizations have a much more structured way of doing that, and obviously, it’s more scalable than an Excel spreadsheet, but people wanna know that they’re doing the right things.

    Shimel: Agreed.

    O’Reilly: Just a little bit about the history, perhaps Alan—you know, ADOC is brand new, but there was a progenitor in the form of DORA, if you recall.

    Shimel: Sure, sure.

    O’Reilly: Yeah, so, that was with Jez Humble and Nicole Forsgren. So, when they produced their State of DevOps report, it was a means by which organizations could form views about what good looked like, so you have your release and then so on.

    And it definitely raised people’s curiosity about—can we do this, can we measure? And of course, one of the principles with any DevOps transformation is to be data-driven. And so, the 180-odd questions that are included in the enterprise edition are very much about trying to capture and turn subjective opinion into something quantitative, a good first guess. And I think DORA has been successful, it’s now part of the Google organization, I believe, but this is a nice independent offer from the DevOps Institute.

    We’re really looking forward, here at Daysha, to taking that to our clients. I see some really interesting use cases. Some of the people that I’m talking to right now are just starting in a CTO role, and they want to baseline what they’re doing.

    Shimel: Absolutely.

    O’Reilly: So, they can look—you know, six months from now, they can say, “How much have we done?” They wanna get an understanding of what have they got in-house right now and then look at it again to see if they’ve been effective in those changes that Garima was—really well-made point by Garima—nice, short, sharp, Plan Do Check Act type changes that are gonna take place over the next six months.

    Shimel: I mean, for me [Cross talk]—

    Bajpai: Right, I mean, I also want to focus on two specific aspects of ADOC, which stands out. So, a lot of people have actually understood that you cannot remake culture without people-centricity, right? So, that’s a given. And we also understand that emerging technology can be a tool in your toolbox when you’re trying to kind of transition from X state to Y state. And a lot of focus has been placed on processes and frameworks.

    What ADOC has been standing out for me is, they have actually reflected to other different things, which are equally essential. The first thing is functional silos. And if you look at large enterprises, what they struggle with, like, what has been in the past is that we have large, functional organizations and units with their own business goals and objectives. And when these people are trying to [Audio skips] towards ________-centricity, towards DevOps capabilities. That’s a large challenge, because you know, it’s not easy to actually break down the functional silos, burn all the ships so that there is no, you know, way back. It has to be carefully done so that we have a possibility of course correction. That’s the first important point.

    The second important point which stands out for me is automation. And when I look at automation, I see that data driven approach towards DevOps and how that will ensure that we automate good processes, we automate the capabilities which are creating value, not only end to end, but also within the practices, right? So, that’s—those two things, I think, put together with people, technology, and process would actually make a kind of, a full house for, you know, doing this assessment in one way rather than looking at it in pockets.

    Shimel: Agreed. In my mind, you know, Brendan, you mentioned the DORA folks, and of course, Nicole has moved on from Google, she’s over at GitHub, and I don’t know if Jez is even with Google anymore, frankly. But really, with DORA, it wasn’t necessarily a consultant’s tool, though consultants used it.

    I think one of the interesting things with ADOC and what I know about how it came about is, it really was designed for consultants to use as part of their consulting practice to help you collectively help your clients get a baseline, a roadmap to show where you’re strong, where you’re weak and going forward so that that consultant can be more helpful, more impactful and, frankly, more efficient, which translates to less dollars, right, that clients waste in kind of circling around to figure out where the ground zero is.

    So, I would just point out that, now, that’s one use of ADOC is as a consultant’s tool. There’s also the community version for individual organizations and large enterprises can do it on their own, they don’t necessarily need a consultant. But it really was designed with that in mind, and I think it’s gonna be interesting to see, you know, DevOps especially, it was one of the knocks on DevOps, right? And I’m devopsy.kinsta.cloud, I’ve heard this from day one—it’s squishy, there’s no manifesto, like in agile. There’s no real definition. It’s, how do you put your finger on it? You know, it seems like a unicorn or a mythical beast or something.

    Well, with ADOC, a lesson I learned early in my career in technology was, everything can be measured, and we measure everything, right? And ADOC kinda gives us a little bit of that certainty, at least as opposed to where you are in DevOps. I’m wondering, have you guys actually had a chance yet to try ADOC out with real world clients and what some of the results or findings were?

    Cermak: Yeah, we’re doing that right now with a client and we found that it was much easier to prioritize the activities that they needed to do, so we could align the activities with their roadmap and make sur that they were incrementing in the right direction to address some of the challenges that they had with their own customers.

    So, we took a very customer-based approach to prioritization of the activities, and they could really see a difference in the way they were able to engage the customer, deliver the features much faster, get the features agreed properly and through improving their continuous delivery pipeline, for example, and their lead time to change would improve and stability and reliability. So, we were able to prioritize exactly the things that were important right then to them with their customer base.

    Shimel: That’s great. Anybody else?

    O’Reilly: Well, just to echo, I personally haven’t had experience with the product just yet, but I have had that experience of walking the corridors with a spreadsheet, meeting people, capturing data—yeah, and that’s a really slow, inefficient way to capture a picture that evolves very, very quickly. So, I’m excited to do it this way, which is just way more efficient and lower cost to the client.

    And I think in terms of the consulting add-on, it’s that experience of having been through several transformations that allows us to analyze the results once they’re produced. And then, exactly like Louis has pointed out—prioritize, right? So, what changes can we make that will fit in with the natural rhythm of this company if they’ve got, if they’re not yet delivering on a regular basis? So, that kinda stuff I think is where the consulting value add is.

    Shimel: Interesting.

    Cermak: And the other thing that’s quite nice is, you can get the marginal gains as well, because you don’t have to tackle everything at once. You can improve one metric and then go and do the next one and the next one and continually improve, which I think the teams that we’re working with have really appreciated that, because they can see an uptick quite quickly, they get motivated, they wanna change more, they want to get better, and they keep going and keep going and getting those marginal gains.

    Bajpai: Right, and this is actually an extremely good point, because it gives us a perspective and this is something which I actually have experienced myself. I went to experience ADOC myself and, you know, I wanted to bring my team in as well. But what has happened in this journey, I have realized that organizations have overestimated the potential of short-term gains. And when I say that, often, people do not realize that whatever transition or transformation from a DevOps perspective they are doing, they are looking at short-term gains and probably losing out on the long-term potential of, you know, larger, creating larger value, long-term value, right?

    So, this is also a reflection that when you take this kind of an assessment, you would potentially have two aspects—what you can do in short-term, and what you achieve through several initiatives put together incrementally and how that outcome would look like in long-term, right? So, that is where these assessments would become very crucial for organizations, at especially big organizations.

    Shimel: Agreed, agreed. With all three of you being involved in consulting, I’m gonna ask you to take off your consultant hats for a second and for end users, end user organizations out here watching this, is ADOC of use to them without a consultant?

    Cermak: Oh, definitely, yeah. You know, we do build software, and we use those metrics ourselves, and we’re constantly monitoring those dials and—okay, we do some consulting around this stuff as well, but actually, we’ve got customers that we need to deliver to, and for us, being on top of all of that all the time is really helpful.

    So, anyone taking the assessment would be able to identify changes that they could make in their own engineering. That’s straightforward. It’s really set out very easily to understand.

    Shimel: Very good.

    O’Reilly: Alan—

    Shimel: Go ahead, Brendan.

    O’Reilly: Yeah, so, there’s a friend of mine who’s a lawyer, and pretty much any time I ask him a question, the answer is, “It depends.” [Laughter] So, in answer to your question about whether end using organizations can benefit from this or that consultant, I would say it depends. It depends on the mindset in the organization, the appetite for learning, the appetite for change, and so forth.

    But for sure, even just to kind of get started and to understand where they’re at, there’s huge value here without a consultant just to get a picture of where you’re at.

    Shimel: Agreed. And I think that’s part of this, too, and I think that’s also where there’s the—I forget if they call it the enterprise edition, which is the full, I forget how many questions there are already, hundreds of questions, versus the community edition, which I think is just, like, 30 questions or something like that. But even the community edition, you know, I think brings value to an end user organization who may just want to—you know, let me stick a flag in the ground as a marker and then see where we go from there.

    Guys, we’re about out of time, but I want to thank you, all three of you, for joining us. I should mention that if you’re interested in ADOC, right, Assessment of DevOps Capabilities, you can find out a lot more about it at the DevOps Institute site, which is DevOpsInstitute.com, and I know that there’s licenses for consultants, end user organizations. We’ve also launched the membership association, so as a member of the association, I think you get some use of it as well.

    But for now—Louis, Brendan, Garima—thank you so much for joining us on TechStrong TV. Good luck, and keep us posted with ADOC.

    Cermak: Thanks, Alan—pleasure.

    Bajpai: Thank you.

    O’Reilly: Thanks, Alan.

    Shimel: Thank you. Alright, we’re gonna take a break and we’ll be right back with our next guest.

    [End of Audio]

  • The Evolution of the Assessment of DevOps Capabilities (ADOC)

    The Evolution of the Assessment of DevOps Capabilities (ADOC)

    The Assessment of DevOps Capabilities (ADOC) is crowdsourced, vendor-neutral and designed for individuals, teams and organizations who want to baseline their current DevOps state, identify the next target state, gain insights into how to improve their organization and team capabilities and measure and accelerate continuous improvement during their DevOps journey.

    The assessment models five DevOps dimensions – the human aspects, process and frameworks, functional composition, intelligent automation and technology ecosystems – to help you gauge your DevOps maturity and identify areas for improvement. In this TechStrongTV interview, chief content officer Charlene O’Hanlon talks with Feisal Mohammed, Niladri Choudhuri and Don White about the evolution of the ADOC and how it can assist organizations at any stage on their DevOps journey. The video is below, followed by a complete transcript.

    Announcer: This is Digital Anarchist.

    Charlene O’Hanlon: Hey, everybody. Thanks so much for joining us today. This is Charlene O’Hanlon, I’m the Chief Content Officer at MediaOps, and I am very, very excited to be having a conversation with three very, very smart people from the DevOps Institute Ambassadors. We have Feisal Mohammed, Niladri Choudhuri, and Don White. Gentlemen, thank you so much for joining me today. I’m very, very excited to have a conversation with you all about the new assessment of DevOps capabilities.

    But first, I wonder if we can start by having you guys introduce yourselves. Please tell us your name, your title, your company, and what you think we all should know about you.

    Feisal Mohammed: I’ll start first—Charlene, is that okay?

    O’Hanlon: That’s perfect.

    Mohammed: Alright. Good morning, everyone, and good afternoon, good evening, where you are listening in. First of all, thank you for having me here, it’s a tremendous honor to speak today. My name is Feisal, I am with Sapience Consulting, I’m the Principal Consultant at Sapience Consulting, which is a consultancy and training firm that is headquartered in Singapore, but we deliver our services regionally in Southeast Asia and in Asia, per se. We’ve been in business since 2008 and our core expertise is actually in the area of service management, governance, risk, compliance, security management, and of course, in the last five or six years, the natural evolution of DevOps.

    And I’m proud and happy to be here. I’m a DevOps Institute Ambassador. I am leading the practice when it comes to DevOps for Sapience Consulting.

    O’Hanlon: Alright, great. Thank you, Feisal. Niladri, tell us a little bit about yourself.

    Niladri Choudhuri: Thanks, Charlene. I’m Niladri Choudhuri, CEO of Xellentro, India and Singapore. I’m also the Chief Organizer for the largest DevOps event that happens out of Asia, and coordinated the DevOps India Summit. And quite excited to be part of this panel because the ADOC, the Assessment DevOps Assessment Capability is going to be a great one, and we will further talk about it.

    O’Hanlon: Alright, great. Thank you, Niladri. And Don, please tell us about yourself.

    Don White: Well, I’m honored to be in the presence of some pretty brilliant folks that have been in the DevOps community for a long time. I really appreciate, Charlene, you inviting me. I come in to DevOps from a 15-year career in the software quality assurance space, and started with extreme programming and it evolved into the lean agile space, and then eventually got into DevOps.

    Worked with many small startups, got them transitioned into lean agile ways of working, extreme programming ways of working, and that led me into coaching and being a DevOps Dojo Sensei for the Fortune 1 company in the world. That catapulted me, launching my business, Agility Science, and that’s where I do consulting and coaching for people throughout the world, quite frankly, but mostly United States-based.

    O’Hanlon: Alright, great. Such an honor to have all three of you on the panel with me today. I love the breadth of experience and depth of experience that you all have and each one of you brings something different to the table, so I do appreciate all three of you being here.

    I want to dive right into the Assessment of DevOps Capabilities tool, I guess, for lack of a better word, it’s an assessment tool, that the DevOps Institute has recently released, and it is now available for organizations to use it to basically assess their DevOps capabilities. It’s one of those titles that needs no explanation, basically. [Laughter] But I think it’s a great tool, and I think it’s going to be very well received in the market.

    But I do wanna talk a little bit about the background of it. So, Feisal, maybe we can start with you. What are some of the challenges that you’ve seen in assessing DevOps capabilities in the enterprise? It seems to be, obviously, there is a need or this assessment tool, so what do you see?

    Mohammed: Well, for me, an assessment—any assessment worth its salt would need to have a good sample size. I think that’s essential. You need to have a really good sample size and not just depend on the responses of a select ________. Let me represent the—misrepresent the actual conditions, if you like, that the organization is actually at, right?

    So, what I do like about the ADOC assessment tool was that it allows for you to scale up the assessment. It allows hundreds of people to participate in this exercise. You know, if you do not have such a tool available, what happens is that this will be largely a manual, face to face process, right? And when it comes to a manual, face to face process of getting assessments, getting people to chime in on their views, chime in on their feedback—essentially, what you will get is tyranny of the loudest, right? The person with the loudest voice will be heard. And then you’ll get the messes that just shrink into the background, right, just disappear into the background.

    With this assessment tool, it allows people to, in some ways, some anonymity, and they’re braver to give their true assessment of where they are in terms of DevOps capabilities. I think that’s the really cool part about the ADOC tool.

    O’Hanlon: Alright. Niladri, what about you? What challenges have you seen with assessing DevOps capabilities in the enterprise? Beyond Feisal noted with having enough people to do a good sample, what do you see?

    Choudhuri: So, a couple of points. One point is, if you look at the assessment—who is doing what, is the point. So, there are multiple organizations or consultants who goes and does assessments. And one of the challenges which I see is that many of them thinks in terms of maturity. And like what I have discussed with John Willis and some of the people who have started the momentum of this, I mean, how can you have a majority of an outcome?

    It’s a continuous improvement process. So, we have to look at it from that point of view. Not that these 25 points have been ticked, so we are done, we don’t have to do any more.

    O’Hanlon: Right.

    Choudhuri: However good we are, we can still improve. So, that’s the first thing. And the second point, which I also see is that the senior, top people in the organization, they have, as people mentioned, they have a rosier picture of what is actually happening.

    And I have seen that, when I go to any of the conferences or even in the DevOps Enterprise ________, when you see them on the podium, the top management talking on the podium, I call it—I mean, it’s not that they are not doing good work, they are definitely doing good work, but it’s a more sanitized version of what is actually happening. When you talk to their team members during the breakfast or the lunch, you get to know a lot of the other challenges which comes up.

    So, as Feisal said, another very important aspect is to get the right information. So, one is the sample size. The other is, I would call it the psychological safety. The people should be able to come out and say what they really feel, and not always say everything is nice.

    O’Hanlon: Interesting.

    Choudhuri: Now, that, getting that right picture is very important, because ultimately, we all have to understand that we are doing it for the improvement.

    O’Hanlon: Yeah, that’s very well said—very well said. Thank you, Niladri. And what about you, Don? What are you sing? Because, obviously, you are working with so many different companies in so many different areas. I imagine you’ve seen these challenges kinda run the gamut, so what are you seeing out there?

    White: Everything that Niladri and Feisal said is spot-on. The one thing that I would like to mention is what to assess. Our assessment tool is so comprehensive and informed by all the expertise. And knowing what to assess is a huge part of it, but it’s really important to get a true, good assessment of the whole area. The psychological safety is absolutely spot-on. People need to be able to be true and honest about what’s going on, because you’re absolutely right, Ni—

    O’Hanlon: Niladri.

    White: – Niladri. The starting point, you can always improve. It’s all about that continuous improvement journey, but knowing where you’re at is critical. And most people try to think of the technical stuff—there’s so much people, the people part is the biggest part. And being able to assess the people part—because culture is my big thing. Culture is my huge thing, because if you don’t have the right culture, that mindset will not take root and it won’t grow, it won’t blossom, and you can’t grow it. you gotta get that culture right. The people part is the critical component.

    So, that’s—what I love about this assessment, it digs into that. It’s not just all the technological know-how, it’s the people pieces.

    O’Hanlon: I love that.

    Mohammed: And that’s spot on. If I just may add on a little bit and ________ on what Don said, I fully agree with you. The culture is the most important ingredient necessary for any movement to take place, right? Any maturing, any improvement—it has to be the right culture. And the thing about DevOps is, the organization is so—it’s so diverse, right, that DevOps may mean different things to different people.

    O’Hanlon: Mm-hmm.

    White: Yes.

    Mohammed: You ask a group of persons and they say, “Oh, we’ve got this set of tools, we are already DevOps.” And you ask another set of persons and they say, “Look, our processes are really lean. I think we’re DevOps.” And so, you know, people do not have a holistic, complete view of what DevOps is. And that’s fine. They’re coming from different perspectives. And when assessment comes in, it binds everything together, and it gives the true capabilities of what an organization is really capable of, right, from all aspects. And that’s really important.

    White: I mean, I learned some things just by taking the assessment of some things that I wasn’t even aware of, practices and things of that nature. And you know, quite frankly, we’ll take it next year and we’ll learn more, because DevOps is continuously evolving, right? That’s the big thing, especially from the technological perspective. But the people pieces—that’s the huge thing, the mindset and where you’re at from psychological safety, those are the huge pieces.

    O’Hanlon: That’s a really, really interesting point, because, you know, you think about an assessment, a lot of times, companies will take an assessment, and it’s kind of—in their mind, it’s kind of a one and done thing, right?

    White: Mm-hmm.

    O’Hanlon: And it’s kind of the same with DevOps, you never really—to your point, you guys, you never really achieve DevOps maturity, because the industry is changing so much.

    So, with that in mind, though, a company will take an assessment, they have the information—how do they use that information, and is it something that they treat as maybe, say, a living document that is constantly updated and improved upon? Niladri, I’d like to start with you on this question, because I think it’s very, very important that organizations understand exactly what we’re talking about when we’re talking about this assessment tool and DevOps in general.

    Choudhuri: Absolutely. Very, very important point, because that also has a lot of impact on what we get as the data. The point here is, we have to be very, very clear as a consultant when we are going with ADOC is that this is not a tool to fire your people. This is not a tool to evaluate your people, whether they are doing something good or bad. It is about how to make them more efficient, effective, and better. It is about achieving the organization’s goal, what needs to be done.

    That is definitely a very important aspect that I feel. Because if there is that fear, if there is, that psychological safety is not there and people think, “Oh, at the end of this, my management will look at it and see whether Niladri has done better or Feisal has done better and give a promotion or a hike to Feisal and not to Niladri, then Niladri is not going to deliver—I mean, give the right information.” Then the whole purpose is lost. So, we have to be very, very categorical in stating, as a consultant when we go, that this is for the improvement journey and not to punish somebody.

    White: I couldn’t agree more with that.

    O’Hanlon: Go ahead, yeah. So, Don, do you have maybe some thoughts on how organizations can use the assessment information after it’s completed? I mean, you know, we’ve made it clear that organizations really need to consider this as kind of an ongoing thing, and I think it’s super important that organizations do understand that. But, you know, maybe after the first assessment, what can they do with that information?

    White: Well, the big thing is, getting everybody having a collective understanding of what your current state is. And this is just one current state tool to get everybody collectively understood on that. Understanding your value streams and all that, those are all current state tools, but it’s a starting point to help you figure out a roadmap to move forward. It’s your starting point, and you look, and as a consultant, we can guide that, because we know kind of the sequential order in which you wanna attack these things, right? And we can help them prioritize their roadmap and their backlog of how they wanna proceed, is how I view it.

    O’Hanlon: Feisal, any thoughts on that?

    Mohammed: Yep. You know, assessments—Niladri’s right, Don’s absolutely right as well. Assessments shouldn’t be used for the wrong purposes. It should be guided by the real desire to improve, to move to the next level. That’s the first.

    The second thing is that an assessment shouldn’t be a one-time exercise. Look, I’m at an age where I’m doing health screening every few years, I really am. And every health screening, I get a snapshot of where I’m really at in terms of my health. And then I figure out, where are the areas I need to improve upon? Where are the areas I need to watch out? I need to look at just little bits of maybe change in lifestyle habits so that I get the benefits of the health assessment results, right?

    And it’s not a one-time exercise. I need to do a checkpoint assessment at some point in time in the future to determine whether what I’m doing is yielding the right results.

    O’Hanlon: Mm-hmm.

    Mohammed: So, it should be an organized, periodic set of assessments with predetermined, agreed plans to move from one state to a future desired state, and then those assessments take place over and over again, heading towards that general direction of improvement, right?

    So, one thing we need to debunk is that we do it once, then we figure out what to do, and then that’s it. No, we need to constantly evaluate. We need to constantly assess ourselves in regards to our capabilities.

    O’Hanlon: So, it’s not just about understanding or taking this assessment and understanding where you are, though, but you also have to have kind of that guidance, I you will, from folks who are experienced in the field. You know, it’s one thing for you to—Feisal, if you went to the doctor and you got the tests done and thy explained to you exactly what the results were.

    Mohammed: Yeah.

    O’Hanlon: But if you went out and did all the testing yourself, you’d look at all these numbers and say, “I have no idea what this means.”

    Mohammed: I would not only have no idea, I would probably be alarmed, you know?

    O’Hanlon: [Laughter] Right.

    Mohammed: I’d think, “I should be dead by now,” right? I’m looking at all these test results—but you do need that expertise to help break these pieces of information down for you, calm you down, and say, “Look, these are the steps that you need to take,” right?

    O’Hanlon: Yeah.

    Mohammed: There are a lot of things that you can do, there’s a lot of things that you should do, right, but these are the things that you should focus on immediately in that journey, right? There’s an order is what Don said. There’s a sequence, there’s a realistic sequence which you can undertake, right, to gradually improve and hit towards the general direction of excellence.

    O’Hanlon: Exactly, exactly.

    Choudhuri: If I may, Charlene—so, this is a tool which is helping us in moving to improve the way of working. And taking what Feisal said, that it’s not a one-time activity—so, we have to look at that evolutionary process of improvement. So, you look at an assessment, you find the weaknesses in the different, the five dimensions, then you decide, “Okay, let’s look at some of the value streams where the weakness is more,” decide on what you need to do, whether you need training, whether you need automation, whether you need whatever change in the process, you do it, you take it forward, you go for another set of assessments. And you keep improving on your journey.

    Because today, what is important to understand is, we have to be adapting to the changes that is coming and more to come.

    White: What I would like to also—

    Choudhuri: And this will help you with that.

    White: What I would also like to point out is, you also need to keep the outcomes. Why are you doing all of this in the first place? Make sure that that is what you’re driving all of this toward.

    The other thing I wanted to point out is, there’s the enterprise assessment and then you have, I think, a team assessment. And so, you use enterprise to kinda get a holistic picture of it, and then once you kinda figure out where you’re at holistically, you can figure out where within the organization you want to do it. Then you can assess those areas, and then you continue to assess those areas as you’re continuing that journey, and it’s a continuous process.

    And Feisal, I love your metaphor with the health. I think that really resonates well, because it’s really what—it’s very similar to that. We assess all the different metrics in our body—well, just look at an organization as an organism, right? An organism that has health concerns, and we need to tweak that with continuously assessing it and coming up with a roadmap and a plan and then executing on it, and then testing our hypotheses that we’re moving toward our outcomes that we’re trying to achieve.

    Mohammed: Absolutely. And it should not be a project, it should be a program.

    White: Yes, yes.

    Mohammed: Right? It should not be a one-time effort, it should be a program effort—weight management, health management is lifetime. It should be that way, and organizations should embrace that.

    White: And the wider it’s within the organization, the better, because the folks that—if you’re just dealing with a partial part of the organization, well, those people that are going through the transformation are not working in a vacuum, they’re working within an organization that needs to kind of be on the same page, because they need to interact and collaborate with one another. If they’re not on the same page and wanna keep the old ways of working and are not open to being able to collaborate and work with these people that are trying to do more DevOps stuff, they’re gonna have limited success.

    So, the broader the understanding of this journey is, the more successful it will be.

    Mohammed: Agreed.

    O’Hanlon: That’s a great point, that’s a great point. And, you know, Don, just to kind of expand a little bit on that and the need for having somebody who’s kind of an experienced person who’s been in the business for a while to kinda help them through the assessments—I would imagine that it not only helps them understand where they are, but also kinda help them build a roadmap for where they need to go, and also show them the areas where they’re in need of most improvement and, from a culture perspective, I imagine that that is super important for organizations.

    White: Absolutely, yeah. Being able to prioritize your plan of attack and know where you really need to focus your energies, but being able to assess your actions is just as important. Because you have a hypothesis that you’re doing these things that are going to move you closer to your goal, but after you do those things, you want to validate your hypothesis by assessing.

    O’Hanlon: Right, right, right. Alright, and offering up areas where maybe the organization hadn’t thought—they would not have thought on their own. So, interesting stuff. Alright.

    Hey, guys, I would love to have this conversation for hours, and I know we could, but we are running up against our time. But I do want to thank Feisal, Niladri, and Don for such a great conversation. I wish you guys the best of luck with ADOC, and I think it’s gonna be a great success. You guys are awesome, you’re so well versed in the DevOps space and you really know your stuff, so considering the fact that you guys were involved in creating it, I know the industry is definitely gonna get a lot of value out of ADOC.

    So, thank you, again, and thanks so much for getting on the Zoom with me and talking about it and about the market in general. So, thanks again—it was great to see you guys.

    White: Thank you. Pleasure meeting you, too.

    Mohammed: My pleasure. Bye, guys.

    Choudhuri: Bye.

    O’Hanlon: Alright, everybody. Please stick around. We’ve got lots more coming up, so stay tuned.

    [End of Audio]

  • Celebrating the One-Year Anniversary of TechStrong TV

    Celebrating the One-Year Anniversary of TechStrong TV

    A year ago today, we started a new streaming project called “TechStrong TV” to provide the audience with an alternative source of information and entertainment, focused on delivering great tech content, during the unusual times of the COVID-19 pandemic. Little did we know back then what this would mean for all of us.

    In less than a year, TechStrong TV became an award-winning broadcast with thousands of videos, hundreds of thousands of views and more than 600 guest appearances by tech thought leaders, business leaders and industry experts. Our mission is to provide the best in-depth analysis on current industry issues and to deliver the most relevant tech news and the latest information on software development, DevOps, cloud-native, digital transformation and cybersecurity. Most importantly, we started doing this to help our community stay tech strong in times of uncertainty. We are committed to our community and we believe it is our duty to keep everyone informed and updated on everything that’s buzzing in the IT industry.

    TechStrong TV features a variety of video series that make up our daily show, including:

    • DevOps Unbound: A bi-weekly/monthly roundtable sponsored by Tricentis, providing a deep dive into DevOps, with an emphasis on automation, continuous delivery, accelerating transformation, testing and quality.
    • Analyst Corner: Hosted by Mitch Ashley and seasoned industry veterans, focusing on the latest trends and opportunities businesses see during these unprecedented times.
    • CISO Talk: A bi-weekly video series that explores the issues and topics that CISOs are dealing with today and how they prepare for the future.
    • The Lab, by GitLab: This monthly segment features GitLab Sr. Developer Evangelist Brendan O’Leary as he shares the latest GitLab updates.
    • The H4unt3d Hacker: A weekly podcast hosted by cybersecurity researcher and ethical hacker Mike Jones, one of the founders of Anonymous, and featuring like-minded cybersecurity professionals who discuss ideas and topics relevant to the industry.
    • Ambassador Insights: A monthly panel discussion featuring members of the DevOps Institute Ambassadors sharing their expertise and insights on various topics in the DevOps space.
    • WFH Fitness with Jeremy Jones: Jeremy, a member of the MediaOps sales team as well as a certified personal trainer, brings his knowledge of fitness to TechStrong TV with a 20-minute home workout for any level of fitness, from beginner to advanced.
    • Something Old: Replays of some of the most memorable presentations by top industry analysts and IT practitioners from past in-person and online events and virtual summits.

    We’ve had the pleasure to conduct executive-level discussions with outstanding thought leaders such as Sid Sijbrandij of GitLab, Shlomi Ben Haim of JFrog, Sacha Labourey and Stephen DeWitt of CloudBees, Ashok Reddy of Digital.ai, Sandeep Johri of Tricentis, Emmet B. Keeffe III of Insight Ignite and many more.

    Today, we not only celebrate the show, but we also celebrate each and every one of our hosts, guests, sponsors and, of course, our viewers, for being tech strong and supporting our community. We wouldn’t have made it this far without you. So, thank you for being a part of TechStrong TV and stay tuned because we have a lot of great content coming your way. We are only getting started.

    All the episodes of TechStrong TV are available on demand. You can watch our weekly TechStrong TV livestream on Monday, Tuesday and Thursday at 9:30 a.m. ET on the web, or on YouTube at DevOpsTV Channel, Facebook Live, LinkedIn Live, Twitter or on Roku, Apple TV and Amazon Fire TV via the devopsy.kinsta.cloud TV app. Also on Android and iOS devices via the devopsy.kinsta.cloud mobile app.

  • Application Security and Continuous Observability with DeepFactor

    Application Security and Continuous Observability with DeepFactor

    Today’s modern applications are becoming increasingly complex and released more frequently than ever before, therefore increasing security, privacy and compliance risks. How do you identify the security and compliance risks hidden in your application before you deploy it to production?

    Continuous observability enables DevSecOps teams to observe millions of application telemetry events and find runtime security, compliance and privacy risks within the DevOps pipeline, while providing AppSec teams the ability to set guardrails and have continuous visibility with every build.

    In this TechStrong TV interview with DeepFactor Founder and CEO Kiran Kamity, we discuss the concept of observability and how to apply it for security and compliance. We also talk about the increasingly important role of AppSec and DeepFactor’s new Observability-as-Code API, which enables DevSecOps engineers to leverage observability functionality in their CI pipeline and gate builds.

    The video of the conversation is below, followed by the transcript. Enjoy!

    Transcript

    Mitch Ashley: I have the pleasure of being joined by Kiran Kamity, who is founder and CEO with DeepFactor. Welcome, Kiran.

    Kiran Kamity: Thank you, Mitch.

    Ashley: Great to have you. We’re gonna be talking about observability, super-hot topic, but before we get there, tell us a little bit about yourself, a little bit about your background, and then a little bit about DeepFactor.

    Kamity: Awesome, yeah. I came to the Bay Area about 20 years ago. I did my undergrad at the Indian Institute of Technology in India in Chennai, and then I came here to Stanford for my grad program. Once I came to the Bay Area, you get addicted to the entrepreneurial spirit, you never leave, this becomes your home. Happened to most people—happened to me as well.

    So, the Bay Area is my home, and I’ve had a mix of enterprise and infrastructure cloud computing, virtualization, and DevOps/AppSec kind of background over the last 20 years. I’ve done two companies as a Founder, which were acquired by other companies like Citrix and Cisco. My first company, RingCube Technologies, was acquired by Citrix. We built a container run time for the Windows Operating System before the Docker days. This was acquired by Citrix in 2011, so I was responsible for some of the product teams at Citrix after the acquisition.

    Then the bug bit me again, and I started ContainerX, which was a turnkey containers in a box type company, which was acquired by Cisco, and it’s now called Cisco Container Platform. While at Cisco, I was Head of Product for the Cisco Cloud Business Unit, which included container—container networking, OpenStack, and some of the other initiatives that they had.

    During that time, as I was looking at what to do next and analyzing the market, a lot of the learnings came to the following. There’s a lot of momentum that has happened so far in cloud native architectures, DevOps, et cetera. And the learnings were that the next wave of innovation is going to be as DevOps becomes DevSecOps. And that’s why I started DeepFactor, and we believe that the next wave of innovation in the world of DevSecOps is observability.

    Ashley: That’s something I both relate to and also am just fascinated by other entrepreneurs is that story of, you’re working on what you’re doing now and you’re still kinda looking at, “Well, what’s the next thing coming up, and what might I go do next?” and then you go off and solve the next problem.

    Kamity: Yeah, absolutely.

    Ashley: Start another company to do that—like you said, you get the bug, it’s kind of a fever. [Laughter] It definitely is.

    Well, cool. We’re talking about observability, and it does seem to be the hot topic of kinda late 2020, early 2021. So, let’s first start with kinda how did we get there—get here? How did we get to this place where suddenly observability is a thing and not only a thing, but important to a lot of people?

    Kamity: Yeah. Just to qualify it a little bit, our focus at DeepFactor is applying the concepts of observability for security and compliance, which is truly novel, and there’s very few companies that are trying to do that.

    Ashley: True. Observability can mean just sort of the next elevated monitoring, right?

    Kamity: Exactly.

    Ashley: So, you’re [Crosstalk] around security.

    Kamity: So far, a lot of the observability plays have been in the logs metrics tracing. Applying the concepts of observability, truly as the next generation of evolution of APM. But at DeepFactor, we’re leveraging the concepts of observability for identifying security and compliance risks in your applications before they go to production.

    So, to answer your question about how did we get here, let’s take a step back and analyze what has happened over the last few years, with respect to application development, right? Apps have become a lot more complex than they have ever been today. I mean, think about it—a common application is made of a bunch of different languages. You have a Java service, you have a Node.js service, and you have Angular in the front end, you have lots of different pieces, you have a database, et cetera.

    You have a lot of third parties—third party libraries that are baked into your services, third party components that are not built by you such as Nginx and MySQL and MongoDB, et cetera, that become part of your application.

    Ashley: A lot of open source, right, in that stack.

    Kamity: A lot of open source. Applications are now also being deployed in a bunch of different ways. You have applications that are not containerized, still mainstream. You have containerized applications, you have full on Kubernetes applications, and you have land applications as well, so the deployment of applications has become complex as well.

    So, in this world of applications becoming a lot more complex than they’ve been, what essentially happened from a security perspective is that the attack surface area of your application has significantly increased. It is the highest it’s ever been so are, and it’s only gonna go that way.

    Let’s take a look at a few other trends that have bene happening in industry. The velocity of releases—that has gone up as well due to DevOps. You’re no longer building or releasing an application once at three months, once at six months. You’re releasing that multiple times a week with DevOps, and different companies are different aspects of that spectrum, there.

    Now, when things are more complex and they’re being released at such a rapid pace, there is no way humanly possible for your AppSec teams to find all of the security risks and compliance risks that lie in your application before they deploy to production. At the same time, the risk of these issues being in production is higher than it’s ever been. If you think about it, the sophistication of the bad actors has increased significantly as well over the last few years, and therefore, the nature of the breaches, the size of the breaches, and the damage that they can cause has increased as well. Coupled with that, privacy concerns have increased, resulting in standards like GDPR and CCPA and all of those things emerging as well.

    Now, in such a landscape, you’ve got to automate identifying the security and compliance risks that are hidden in your application before you deploy your application to production. And that is where the current tools of just code scanning or identifying issues based on signatures or just DAST scanning your application, et cetera, don’t cut it. You need something that watches your application while the application is actually running in both pre-production environments as well as in a canary deployment of minimal production deployment before you release it to your broader production deployment.

    And in that environment, you’ve got to be able to watch the millions of events that are happening inside your application, take that data, analyze and find the needles in the haystack, and therefore determine where the security and compliance risks are and pass on all of this information with rich evidence such as stack traces, metrics, and whatever it takes to fix these issues back to the developers. And a lot of this has to happen in a seamless manner that is nicely tied into your DevOps kinda pipeline, and that’s where observability applied to security and compliance comes in, and that’s exactly what we call continuous observability at DeepFactor.

    Ashley: Interesting. I know, talking with you previously and kinda hearing about DeepFactor, you all talk about start left, not shift left—this idea that, really, it starts from the beginning, not, “Let’s kinda push it as far left as we can.”

    Kamity: Yeah, absolutely. If you think about it, we’ve had operator specific tools emerged in the last five years with respect to security. So, you’ve had container security tools that identify issues in your Kubernetes configuration or your Docker configuration or vulnerability scanners that identify issues in your host operating system if you’re deploying your app in a VM.

    Now, those are all the types of insights. Are there any misconfigurations that could lead to security issues that are very relevant for the Ops people? And those tools are coming up with the idea of shifting left, because you need to find these configuration issues before you go to production so that the Ops people can deploy these applications properly.

    But when it comes to developers, their agenda is not securely deploy your application. They don’t care, honestly, about how you’re Docker or Kubernetes is configured, for the most part. They care about what is in their application, securing at the source. And when the agenda for Dev teams is to secure at the source, then all you care about is—what is my application doing, whether it’s my application or some third party that I brought in, or just my interpreter itself when it is running? And can I identify the risks involved and understand my attack surface within the application ahead of time? And that’s why we call it start left.

    So, we think that operators care about shifting left. Developers should truly care about starting left.

    Ashley: Yeah, it’s interesting, because your point about code scanning and DAST approaches to security is, from a code standpoint, you do wanna be writing a secure code, so it’s a valid thing, of course, to be doing. But you mentioned Lambda, you mentioned, of course, infrastructure as code, essentially, where all this is dynamic, right, in our environments today, and more so, not less, every day, right?

    Kamity: Yes.

    Ashley: Every day, it gets to be more dynamic. Now, you’re really talking about the whole context of the environment with the application. Kind of, if you thought about it in the network, you’d say all seven layers, right? If you think about it in the security stack of software, it’s application plus all of the other things, right?

    Kamity: Yes.

    Ashley: It’s interesting what—how do you find people are accepting this idea of run time information being provided with context, you know, this rich information you were talking about, is that something new to developers or like, “Oh, my gosh, I’ve been waiting for this forever” or, “Well, this is really cool. Look at—let me see what I can do with it”? What’s more the experience that developers have?

    Kamity: Yeah, so, I think different organizations react differently to something like this. The old way of thinking is—oh, developers don’t care about security or compliance.

    Ashley: I’ve never met a develop that wants to write insecure code or unsecure code. [Laughter]

    Kamity: Exactly, right? That is exactly what’s happening now where, given the consequences of shipping insecure applications and given the need to be more and more secure at the source, I think developers—and just simply because it’s just not humanly possible for your AppSec teams to identify all these things. Given the talent shortage of the AppSec skill set as well, it is, the responsibility if identifying these risks has to be borne by the developers. Because at the end of the day, the developers are the ones that are writing the code and you’ve got to make sure that you’ve shipped secure code.

    Engineering leadership and AppSec teams in various organizations that we’ve been working with have been fully accepted. In fact, they’re fully aware. In fact, a lot of them want this kind of concept, it’s just the lack of tooling today. Because if you think about the current tools that are available, they’re doing the best they can with the existing set of tools.

    I mean, they’re scanning the code, they’re trying to scan the application from time to time—but those tools don’t lend themselves well, nicely into seamless integration into your CI pipeline, and therefore, giving developers the insight about, “Hey, here’s where we saw your application did this.” That can only happen with observability tools like what we’re building, because we watch every thread of every process of every service in your application when it is running in test and even canary deployment in your part of production before you deploy that thing widely to a larger section of production. And that is the kind of insight developers do care about.

    What we have gotten repeated feedback as we have been building this product with a few development partner type enterprises so far is that, the insights that we have needs to be enriched with richer evidence information so that developers can actually take that evidence information and directly go fix the problem. So, we’ve augmented our insights with stack traces wherever appropriate. You know, obviously, the good old things like CVE numbers and things like that, we have that.

    But what we focus more on is not just giving you a list of CVEs, but complementing the insights that your software composition tools give you by giving you run time usage information of that CVE. For example, we can tell you if a tool like Snyk will tell you there are 250 vulnerabilities in your application, DeepFactor will tell you, “Hey, there are 250 vulnerabilities according to what Snyk is telling you. Fifteen of those things have been used by your application at this time, when your application was executing here, ad here is the function, here is the call stack.”

    So, that will make it easy for a developer to go, “Okay, now I don’t have to get overwhelmed with fixing all of the 250 things or adding that to my backlog, I can actually prioritize which ones to fix first, because that’s what my application is actually doing.” It’s not about the whole thing that has been checked into your source code, it is what your application’s actually doing that will help you catch the more important things. It’ll help you also reduce the number of alerts that can inundate you.

    Now, with all of these changes, the rich evidence, reducing the number of alerts, and to the point, alerts based on what your app is actually doing, developers are finding it more and more meaningful, our insights. And as we grow the company, that’s gonna be our primary focus.

    Ashley: That’s always been the challenge with vulnerability scanners and code scanners is, yes, I get all of those results. What of those are real? Yes, they’re all theoretically possible. I may not be using it in a way that actually exposes me to that CVE, that vulnerability.

    But what you’re saying is, you’ve actually detected the use in the application or the software stack of something around that CVE that’s worth looking at. Hopefully, you’re cutting down on the number of things that are actually, they go look at. You can ignore the rest, if you will, or at least know that they’re much less likely to be an issue.

    Kamity: Yeah. We do not give you too many alerts. We give you the alerts that are relevant for your application because we watch the millions of events that are happening in your application in every part of your application, across various layers of the stack—like, system caller interface, library calls that your application has made, network behavior, web and API, all of that.

    And based on that data, we treat it as a data problem. So, we take that data and then we try to identify anomalies and detect that these are the risks that lie in your application from a security perspective, and this is how it maps into compliance. So, we will tell you that these are the security risks in your application and in our next module of the product, we’re gonna tell you that this can hurt your PCIDSS, and here’s the number, basically.

    Ashley: Mm-hmm. It definitely is gonna improve your relationship with the security and compliance team, right? If you’re solving these problems before it gets to them, they have to ask, “Well, did you do anything about this? Are we susceptible?”

    Kamity: Yeah.

    Ashley: Talk a little bit about—so, where in the tool chain and the workflow pipeline, where do you fit? Where does DeepFactor play?

    Kamity: Yeah. The best way to think of us is, if you take a step back, if you are thinking about your DevSecOps initiative in total, you want to plug in into a bunch of different points from a security perspective into your CI pipeline. Your developers write code. The next step should be you try to find risks in your code. That’s where the SaaS tools come in, they find the risks that are there in your code.

    Then you create your build artifacts—let’s say, your executables, your container images, and whatnot. Then you try to find risks that lie in your build artifacts. That includes your code, any third parties that you’ve compiled together and created your services. It’s still static, though. You’re not running them yet. Tools that allow you to identify risks in your build artifacts could be container scanning tools, like image scanning tools that scan your container images and find issues or software composition analysis tools like Snyk and Black Dock and tools like that. These tools find vulnerabilities that exist in your components after they’ve been built.

    Then you run your application, you’re testing your application. Either you’re testing it in a test environment or you’ve deployed and you’re testing it in a minimal configuration of your—like, a canary deployment in your production. During that time, you’ve flicked DeepFactor on. DeepFactor doesn’t require any changes to the code of your application; you’re simply running your application.

    And that’s where we’ve built a significant amount of IP. You know, my Co-founder, Mike Larkin, he’s the CTO, he’s the father of the OpenBSD hypervisor. And our senior engineering leadership members came from Qualys and FireEye, having been in the area for 20 plus years working on security products, each.

    So, we’ve created something that involves zero touch, pretty much. You don’t have to touch your application at all, you simply run a command called DFCTL, just like KubeCTL, we came up with DFCTL. So, you do DFCTL, run your app; or DCFTL, run your container; or you drop it into Kubernetes. We have a webhook admission controller that you simply drop into Kubernetes, and then any pod that you want to be monitored, you simply can specify a config file and that pod gets monitored automatically with DeepFactor.

    Now, the way DeepFactor inserts itself is completely behind the scenes. It’s language agnostic. You don’t have to worry about, is it Java, is it Node.js—DeepFactor figures out that it’s Java or Node.js and does some specific things and finds out more information.

    So, you simply run this, your application is running in your test environment or your minimal production environment, DeepFactor observes everything that it’s doing. When the tests are done, it tells you—you throw your automated tests at it while your application is running, just like normal. And then when it’s done, DeepFactor gives you all of that information about what insights have been found and what’s the evidence information that’s pointing to the insight. Is the issue or the risk presenting the attack factor lying in the code that you wrote? Is it lying in a third party that you brought in, or is it at the interpreter level itself? All of them are risks as far as the attacker is concerned that could be exploited, so you need to be aware of where your risks are.

    Ashley: Now, are developers putting in some library calls or DeepFactor code into their application stack as well, then? Is that how you’re getting into the software, knowing what’s happening inside as well as outside?

    Kamity: Actually, that’s the beauty of our IP, and we’ve filed a few patents in that area. Developers do not need to write any code to change, or change anything in their application. You simply enter DFCTL and run your app and DeepFactor inserts itself into the application at your run time, completely seamless to the developer, and when it’s done, it unplugs itself and your application and gives you all the insights.

    Ashley: Wow. That sounds pretty cool. I can imagine that’s a big plus for developers. [Laughter] Yet something ls they don’t have to debug, right?

    Kamity: Exactly, yeah. That’s the significant part of our IP.

    Ashley: You know, it’s interesting you mentioned your team comes from a number of other security companies that have been around for a while—you know, you mentioned Qualys and others starting in the scanning, the vulnerability management space some time ago; that’s about when I got into security, too.

    What do you think we’ve learned from those types of companies and those experiences that we’ve sort of changed our perspective about where we are today, just given—yes, we have much more complexity in software, much more porous security issues, but what have we learned from all of that security scanning that’s helping us?

    Kamity: Yeah, no, I think there have been numerous, numerous learnings, and the learnings have evolved over time as the landscape of application development has changed as well. You know, you’ve had tools in the past that were designed based on the applications of the past. But tools of today and tools of tomorrow are different, because the applications of today or the applications of tomorrow are definitely trending in a different direction.

    One example of the thought process itself is that, you know, when things are in single digits or a lesser number, it’s okay to have manual scanning, manual testing, once in a while test it and then find information, which is kinda the old kind of scan once in a while, identify it, or bring in a pen tester once in three months, you know, check some boxes and get it done kind of thing.

    Those are all great and they’re still relevant even now. What has become even more important is why you do those once in a while scans and checks. You’ve got to make sure that you get in the habit of securing at the source. You can no longer imagine that your infrastructure or the perimeter is gonna secure your application properly. You’ve got to make sure that you build your application securely to start. And that fundamentally has changed the kind of tools that we need to build in order to equip the developers who build applications to secure at the source.

    At the same time, I think the role of AppSec has become even more important than it has ever been. Because, you know, sometimes I keep getting asked, “Oh, are you saying that developers should use these security tools? That means the AppSec teams are no longer relevant?” That is totally wrong, because AppSec teams, their job is increasingly more relevant. Because if you take a step back and you look at the number of attack vectors that are there in your application, we just talked about how your pipeline should be architected—secure at the source, making sure that you scan your code, scan your builds, test your running applications, and identify risks in all of these areas—who ties them together? Who comes up with this overall strategy? Who comes up with that triaging process and passing the evidence back to the developers, identifying which ones are important and which ones are not?

    All of that should come from the AppSec person in the team—AppSec or if AppSec is assimilated into your DevOps and we call it the DevSecOps person, that’s the role of this person is to make sure that he or she is the shepherd of your CI pipeline from a continuous security perspective and then feeds all of that information back to the relevant parties. Some of that could be your developers, some of that could be to your engineering leadership, and some of that could be to your security leadership.

    Ashley: Mm-hmm.

    Kamity: That is how I see the organizations of tomorrow shaping up, learning from what has happened over the last 15 years to 20 years of innovation in this area.

    Ashley: I think that makes a lot of sense. Otherwise, (a) we’re just throwing tools at it, everybody’s doing whatever and who knows whether that’s helping us improve and improve security. And you mentioned the data coming out of it, right? That can also be used for continuous improvement, continuous learning, what are trends that are happening in our application?

    Suddenly we’re seeing much more of this technique or this architecture or this environment being deployed that, you know, not always do the security people have exposure to that early on in the process. So, it’s a good way just to know what the heck is goin’ on and then also, you have an idea about how all of your security tools, developer or non-developer, fit into an architecture that makes sense.

    Kamity: Yeah, exactly. I mean, imagine flipping a switch and identifying, “okay, these are all the touch points that my application has and these are the millions of things that it’s doing” and condensed very well to, “these are the red dots in that whole story, and this is where your risks lie.” That’s powerful, and I think it’s the AppSec person’s job to set all of that up and make sure that a framework is created and then say, any time something that comes up, you know, make sur that you pass it on to the developer with the appropriate evidence and work with the engineering team to decide.

    Because when you have so many different services and so many different languages, the AppSec people, especially because they’re already short staffed, cannot possibly know everything about the business logic of the application, resulting in those decisions that could have been made to bring in component X and component Y and whatnot.

    Ashley: Mm-hmm. You know, Kiran, one of the things that I’ve said over time is that security people need to get a greater understanding of software architecture. They don’t need to have to be developers, right, that’s not what their skill set is, nor necessary their desire. But you can’t treat security as this hard outer shell, you know, we just keep making it smaller and smaller. And now all you’ve got is thousands or hundreds of thousands of small outer shells and now you’re not securing anything, any more.

    It seems like the AppSec team can play a really important part of helping bridge that gap of what are we doing specifically, what are the architectures that we’re using, what might be some of the security risks that maybe a security engineer is just not fully up to speed on or trying to keep up to speed on as it’s changing?

    Kamity: Yeah, absolutely. Imagine the power of flipping the observability switch and the AppSec person going and saying, “Hey, Dev team, we noticed that in this particular piece of your code, you’re using an API that has been deprecated by the operating system” or, “In this particular piece of code, you’re invoking memory improperly, because this tool is showing me exactly what was done when this particular area of memory was allocated with the wrong permissions. Or, “This is an area of code where your interpreter is doing something wrong. Is it possible for us to go change the version of the interpreter that we’re using, maybe upgrade it to the latest version or put a patch?” Or, “Do we need to, in order to mitigate this thing, assuming that there’s no fix in the interpreter, do we need to go put something in our WA in our infrastructure to block the particular attack from happening?” Or, “Should we report this problem upstream to Java itself, the Java community itself, so they can go fix the problem in there?”

    So, lots of different things that could be done once the AppSec team is empowered with this much rich information about what’s happening in the application.

    Ashley: You know, something I don’t know that we talked enough about, we talked about how rapidly and how quickly we’re delivering software applications now. The environment of the software, the API calls we’re using, the libraries, the services, interpreters—all of that is changing in parallel very quickly. Sometimes you don’t feel like you have time to keep up with it, or that’s all you do is spend your time keeping up with that, not kinda delivering business value.

    I think folks that are maybe not involved too deeply in the software creation process really realize not only the complexity but how much change there is to deal with. There’s a lot that goes into that. We talk about technical debt or backlog or whatever—it’s a lot more than that, there’s much more to it. [Laughter]

    Kamity: Absolutely, there’s a lot more than that, and I think having an informed security team as well as, you know, coupled with a structure and the right tools baked into your pipeline, which results in informed Dev team, can result in goodness overall. You’ll end up identifying security and compliance risks earlier in your Dev cycle. You’ll end up fixing those things earlier, and therefore, you will end up shipping a much more secure application, and it’s a cycle. Every time more developers check in code, you know, this kind of identification happens automatically, and you end up identifying more and more risks and fixing more and more things, resulting in more and more secure applications into prod.

    Ashley: Mm-hmm. Awesome. Well, what are some things folks might have access to you can help them get started? Obviously, they can download HIV testing product or get involved that way. Do you have some other tools or things that they might be able to use to make it approachable to get into this kind of an approach?

    Kamity: Yeah, they can go to DeepFactor.io to check out the product, understand more about the product. And if they want to get started, they can either download the community edition that is now free for 10 user teams or less. If you need any help with setting up the product, you can reach out to our Customer Success person.

    We’re also giving away a free DevSecOps Risk Assessment to companies that are working with us as we expand our organization more. This will help any engineering team or any security team to get a free assessment of what DeepFactor can find in their applications so that they will be able to identify, “Okay, these are the kinds of things DeepFactor finds, and it’s useful for me and here’s where I need to go next” kind of thing.

    So, that DevSecOps Risk Assessment is completely free. Contact us, hello@deepfactor.io or just go to the website to learn more.

    Ashley: Awesome, great. I know you’re also speaking at the Cybersecurity 2021, I think you have a couple of sessions there, right? The dates are March 4th and 5th for that event.

    Kamity: Yeah. We have a couple of speaking sessions at Cybersecurity ’21. We have a virtual booth there as well, so do check us out. There is a—you know, our team can answer any questions or even try to explain to you or help you understand what DeepFactor can do and identify in your application.

    Also, today, we’re launching Observability-as-Code. It’s a new module that we’ve created, and a product that allows people to bake in observability into their CI pipeline, similar to how Infrastructure-as-Code enables DevOps and DevSecOps folks to spin up, spin down infrastructure in their CI pipeline itself and other related scripts. You can do, now, the same thing with observability for security and compliance with DeepFactor. So, you can use our API, we have a Swagger doc ready, you can use our API to invoke DeepFactor as part of your CI pipeline, get the results, triage the results, use that results to block, if there’s any P1s you want to block the _____, you can do that. You can do things like that with the Observability-as-Code API that we just announced.

    Ashley: Excellent. Well, I hope folks will check you out. I think it’s a great path to be going down, and I’m sure developers appreciate writing more secure code, but completing an application that’s more secure that they’re involved in developing.

    So, Kiran Kamity, great to have you here, CEO and founder, co-founder—I guess founder [Laughter] of DeepFactor.io. And be sure and check out the speakers that you all have at Cybersecurity 2021. It’s a great conference and we look forward to hearing more from you, there. Thanks for joining me today. Great to talk with you.

    Kamity: Thank you much. Appreciate the opportunity.

    Ashley: You bet.

    Kamity: Bye.

  • TechStrong TV: Sumo Logic Goes the IPO Route

    TechStrong TV: Sumo Logic Goes the IPO Route

    Sumo Logic has come a long way, becoming a public company with its IPO of 14.8 million shares at $22 per share. In this  TechStrong TV interview Christian Beedgen, CTO and co-founder at Sumo Logic, joins Alan Shimel to discuss all the hard work that lead to this major accomplishment.

    Transcript

    Alan Shimel: Okay. Big special event today here on TechStrong TV devopsy.kinsta.cloud. I’m Alan Shimel. Thanks for joining us. Our guest is Christian Beedgen. Christian, for those who don’t know, is the CTO/co-founder of Sumo Logic and it’s certainly a big day for Sumo Logic and all of their people and customers as well as the DevOps world. Hey, Christian. First of all, congratulations.

    Christian Beedgen: Thank you very much. Thanks for having me, sir.

    Shimel: Thank you. So Christian, you know, today is a – no matter how you slice and dice it, this is a major milestone, a major day for the Sumo team. Of course, everyone, you know, they see an IPO and they say, “Oh, another one of these dot com tech startups,” but what they don’t – you know, they don’t realize the blood, sweat and tears that gets us – that gets one to today. Why don’t we start off by – give us – you’re a cofounder – give us the history of Sumo.

    Beedgen: Yeah. So look, we started in 2010. Our hypothesis was that – your machine data analytics in the widest sense was sort of right for disruption and sort of a thing that we felt we could bring to the table was this insight that this type of product had to be taken away from sort of the classic enterprise software delivery model where a bunch of developers write code and then throw it over the wall and customers are sort of stuck with installing and running it and basically turn it into software-as-a-service. So Sumo Logic is a machine data analytics software-as-a-service offering. We got there from our own experience, like doing security analytics and security information and event management at ArcSight

    I ended up being an early employee there – so was my cofounder – and we kind of went through growing up with that company and did basically SIEM for nine years. It became very successful itself, and towards the end it became clear that we ended up just spending way too much time talking to our customers back then about how to kind of – you know, how to sort of take care of the system rather than actually using it, right? And then so the system servers were supposed to be there to monitor for various things. Same with Splunk at the time, right? You know, monitor the uptime reliability and security and becoming these giant systems that somehow needed to be maintained, and then you could actually – you had a hard time monitoring themselves, right?

    And so I think we turned all our security people into vendor storage admins and all that, but like that was just not cool, right? We felt that by turning it into software-as-a-service that was going to be a much better story because we don’t just end up building the product; we’re also running it, which we feel we’re probably better equipped than 2,100 customers are right now or whatever number of customers we will have in the future.

    Shimel: Yeah.

    Beedgen: So that was sort of the basic idea, right? And so it started with us putting together a scalable org management backend. So folks could _____ their logs. We initially focused on application monitoring, et cetera, use cases, so more sort of on the operational analytics side. But right away folks started using that part of the product for security stuff as well just because it really solved the problem pretty elegantly and they could just put in the data and get insight out of it, and we kind of kept adding to it and over the last 10 years, fast forward through various trials and tribulations we managed to establish that SaaS was a valid delivery model for machine data, that it was a valid delivery model for this type of analytical platform, that folks that need to keep their systems reliable and secure can easily rely on a SaaS solution and that it is in fact a better solution, right?

    And that kind of what brings us to today. We ended up going back into security bigtime over the years as we matured and felt that – you know, the thing is in a startup is you’ve got to have some amount of focus in the beginning, but we always knew the security stuff was very interesting. It was always part of the plan. We were lucky to grow the company and get to the level of maturity where we could then double down in that we made two acquisitions to speed that up. We have a cloud sim in the market today and so that’s kind of how we got there, right? And I think maybe sort of the biggest hurdle that we jumped over there was going back to the initial days, sort of the doubters, the people who thought it couldn’t be done, which if you don’t have those then your idea’s probably not good enough, right

    Shimel: Absolutely.

    Beedgen: Then ArcSight came around the block and Hugh and his folks back then just basically proposed that you could do real-time correlation on security events. People also say I’m crazy; I can’t do that, right? So we kind of learned from that a little bit, and we said, “Hey, you know, that’s – we’ll use that as positive energy.” And the thing to overcome really was the idea that we could do it as a service, this incredibly large scale data processing, which now in the light of cloud-based, cloud-delivered data lakes and so forth it’s now much more commonplace, but 10 years ago it wasn’t and that was not an easy sell necessarily and for people to even take you seriously

    But the other thing also was as a SaaS a customer has to basically jump over that hurdle of realizing that their data is now managed in a software-as-a-service solution and not necessarily on prem anymore. We did a lot of work early on to sort of figure out how to make that work for our customers, right? And I think ultimately a combination of that and the fact that the product is just compelling managed to get us to sort of really put our hook in the market in the first couple of years, and we had the opportunity to sort of grow out from that

    Shimel: Absolutely. Look, ArcSight was a great product in its time. I’m from the security world, right? It was – you know, in the age of sim it was the high water mark. I think certainly though what you were able to kind of capture lightening in a bottle with Sumo was to build that next generation of what you could do with an ArcSight in a cloud, SaaS-based environment, but at the same time it wasn’t all about security

    I think, as you mentioned, Splunk kind of touched on this, some of the others, but you also were able to ride what we call the DevOps, this whole wave of DevOps and now we’re calling observability and monitoring and so forth to capture data, not just pure security feed, but all kinds of data that people are interested in, doing it in an uber scalable way by using the cloud and SaaS which really brought down the cost versus your average ArcSight investment was a couple hundred thousand dollars, right? So you could do this in the cloud much cheaper and it allows you to do more, right? Because now it’s not prohibitive to capture more data, analyze more data. It’s not cost prohibitive. And so Sumo really becomes what we can do with today’s technology and using what people think are important today; and look, kudos to you guys for recognizing it, building it, capitalizing it, and here we are today

    Right? So I’ve got to ask you this. So personally – right, ArcSight never went public. ArcSight, for those who may not know, was acquired by HP for a nice penny back then, right? But it never had – you never did this whole IPO thing. How does it feel

    Beedgen: We did actually  –

    Shimel:  Oh, really? I don’t remember.

    Beedgen: Yeah, we did. No, actually what happened was that the company actually went to – this was actually super interesting. So ArcSight, like leading into 2008, I think kind of passed a sort of revenue bars and those various things and in the end they actually went public. They just about managed to squeeze out in I think it was February 2008, and it was a tough environment even then, and then of course went completely to shit, you know, later in 2008, but even so it was – you know, being there it was quite a rollercoaster. It taught me a lot of things, including not actually refreshing the stock price on a daily basis or even on an hourly or minute basis. I probably just look at it once a month or so, you know, because sometimes you’re not going to like what you’re seeing

    But early in 2009 recovery kicked in, Obama came around and this sort of cybersecurity speech and people started believing in cyber in particular again and people started looking for investments, and they put money into ArcSight. Stock came up to actually I think, you know, quite a nice level, and then what happened was in late 2010 – I was not with the company anymore at that time. I exited in late 2009 to then start focusing on what eventually became Sumo, right? HP actually did pick them up, so yeah, so they were public for about two years.

    Shimel: About a year.

    Beedgen: Yeah.

    Shimel: You know what? It’s long enough ago I forget. But how does it feel today?

    Beedgen: Oh, it’s complicated, right? It feels good, obviously. You kind of like zoom into that a little bit more. It’s a little bit overwhelming. There’s a lot that kind of goes in that there’s this sort of – there is a sense of release when this finally happens, and we always thought that this was a company that had – you know, given the market was pretty well figured out and we always thought that if we managed to execute properly then this was a company that from the beginning would stand a chance to actually go to this level, and so a lot of this kind of like coming through, kind of proving itself today.

    But, you know, the reality is it had actually been proven out year over year already, right? And so I feel that, as I’ve said in the past, it’s kind of a marathon but the marathon metaphor sort of implies that there’s a end, but if you kind of build and continue to build a successful company it’s actually an infinite race, right? But even so there are lapses and there are markers and milestones and all of that, and for everybody – of course I don’t want to downplay it, you know, being – becoming a publicly-traded company is a huge milestone, right? It’s beneficial it gives us a chance to sort of raise more money and use that money to continue to kind of do what we do more and better, and it does also provide – you know, it creates wealth on some level for hundreds and hundreds of people that have been working their butts off to get the company to where it is, and I think – let’s not forget that that’s also sort of – you know, that’s really your _____

    Shimel: That’s what it is, it’s value to the shareholders and the employees are some of the shareholders there. Christian, I know it’s got to be a busy day for you. You’re all the way in Germany and it’s probably been a busy, busy morning and day there. I want to first of all congratulate you and the whole Sumo team, right? I mean it’s – this is – no company goes public on one man’s back, right

    Beedgen: Oh, it’s true. [Laughs]

    Shimel: As you mentioned, right? It’s – and it is a lot of hard work. These are not overnight successes. We wish you the best of luck. We also – look – you know what, Christian? This is a beacon for other companies in the space, in the DevOps space, in the security space, to see that, you know what, it can be done

    And the team at Sumo, you know, took their lessons from ArcSight, built a better mousetrap, a better solution, a solution for today, and you’re being rewarded for it and rightfully so. So congratulations to you and all of the Sumo team on your IPO. We’ll be – we’re not going to watch the stock price every hour either, [laughs] but –

    Beedgen: It’ll be fine. It’ll all be fine.

    Shimel: Yeah, you guys do what you do and everything else will take care of itself, right?

    Beedgen: That’s kind of how – that’s what got us there and we’re not gonna change that. [Laughs

    Shimel: Absolutely not. Hey, congratulations.

    Beedgen: Thank you very much.

    Shimel: Come back and join us soon. Hopefully we’ll be able to see each other in person soon one day.

    Beedgen: That would be great. That would be great. Anytime.

    Shimel: We’re tired of being in the house. Alright. Christian, Beedgen, CTO/cofounder of Sumo Logic on their IPO today. This is Alan Shimel for TechStrong TV Digital Anarchist. Thanks, everyone.

  • TechStrong TV: How strongDM Helps Fintech MANTL With Access Management

    TechStrong TV: How strongDM Helps Fintech MANTL With Access Management

    The fintech space is growing by leaps and bounds, as more consumers shift their financial transactions online for both convenience and necessity during the COVID-19 pandemic. MANTL is a fintech startup providing banks and credit unions with the technology they need to meet the demands of their customers who want to do their banking from anywhere and on any device.

    In this TechStrong TV interview, we speak with Ben Conant and James Qualls of MANTL and Elizabeth Zalman of strongDM to understand how strongDM’s technology is helping MANTL with access management for its backend systems to enable a strong user experience.

    Check out the interview below and follow along with the transcript to find out more.

    Transcript

    Alan Shimel: Hey, everyone. Thanks for joining us for another episode of TechStrong TV. In this segment, we’ve got three people, as you can see, and let me introduce them to you. I’m gonna start with the lady, Elizabeth, Liz Zalman of strongDM. Hey, Liz—welcome back.

    Elizabeth Zalman: Thanks, Alan. Great to be here.

    Shimel: Okay, and then we’ve got two guys. The guy up in space there is Ben Conant—he’s not really up in space, he’s in Tenafly, New Jersey, but hey, you know, with the magic of Zoom, he could be anywhere. Hey, Ben, welcome to TechStrong TV.

    Ben Conant: Hey, Alan, thanks for having me.

    Shimel: My pleasure. And then last but not least, we have James Qualls. James, I didn’t even ask you pre-hand—where are you from? Where are you coming in from today?

    James Qualls: I’m in Harrison, New Jersey.

    Shimel: Okay, so, we’ve got a bunch of Northeast—Liz is up in New York and I probably have the biggest New York accent of all of you guys, so, there you go.

    But anyway, so, we have not—I don’t think we’ve ever covered MANTL on our show or even in any of our devopsy.kinsta.cloud, Security Boulevard, Container Journal, I don’t think we’ve covered MANTL before. So, let’s start off with a little bit about who MANTL is and then, as part of that, James and Ben, tell us what your roles are at MANTL.

    Conant: Sure. So, I’ll start. I’m Ben Conant, I’m the CTO and co-founder of MANTL, and MANTL is a fintech startup that provides banks and credit unions with the technology they need to meet the demands of modern customers. So, you can kinda think of us like Shopify, but instead of helping sort of medium-sized retailers have an online store without an engineering department, we do the same thing for American banks and credit unions.

    So, like, there’s actually 13,000 financial institutions in America, and 96% of those financial institutions are not Chase or Bank of America or SoFi that pump millions if not billions of dollars into technology. And these financial institutions really don’t have access to technology vendors that they like, want to work with, or provide them with what they need.

    So, that’s why MANTL exists. We are trying to reimagine what it can be to be a small bank, medium-sized bank in America or a credit union by providing technology that meets what they need.

    Shimel: Very cool. James, do you wanna—what’s your role at MANTL?

    Qualls: Yeah, so I’m the Director of Engineering here at MANTL and primarily responsible for infrastructure or liability engineering. I have the pleasure of architecting everything that MANTL runs on and we have the opportunity to run on a very modern cloud infrastructure. So, we use Kubernetes, everything’s configuration as code, running as Terraform. You know, we take advantage of as many cloud products as we can.

    Shimel: Excellent. And then Liz, we’ve had strongDM before, but for people who may not be familiar, give us the strongDM story.

    Zalman: The strongDM story is that the way people manage access to infrastructure has fundamentally changed since cloud. You’ve got an explosion of servers, database management systems, cloud providers. Kubernetes came into existence, and so doing it by hand or relying only on Active Directory, it doesn’t work anymore, and so strong creates a single control plane for you to both manage and audit the access of anybody who works for you—a contractor, an employee, service account to any infrastructure that is yours.

    Shimel: Cool. So, for purposes of setting up the discussion of how strongDM works with MANTL, Ben, I’m gonna ask to give us an example of some of this technology and apps that you guys are creating or helping maintain and power for your fintech clients, for your small and medium banks, credit unions, stuff like that.

    Conant: Yeah, so, the first product that we decided to develop for this market of sort of medium-sized banks and credit unions is a way for those banks to have a kind of open an account dot bank dot com website that was completely white-labeled and personalized to their brand, but really felt like signing up for Robinhood or Acorns or one of the sort of big fintechs that have a really slick sign up ________. Because a lot of these banks, you know, they don’t—in order to achieve the kinda deposit growth that they want to achieve, they have to go online, but they’re really suffering from not having a website that anyone would want to sign up for a bank account on, right? So, that was a very specific product, but there’s a huge market for it, so we decided to start with that.

    And then, you know, from a technical perspective, what does that mean? It means, for us, we have node microservices running in a Kubernetes cluster. We’re also talking to post press data stores in GCP, and then we need to control access and have firewalls and UAT environments for the banks to test stuff out using Cloudflare.

    So, you know, strongDM kind of ties into that, because as we grew and as we scaled, we needed to manage internal access to different pieces of our infrastructure, and we were actually thinking about building out our own little app to do this and have SQL access provisioning stored up in a database, but then, you know, through looking at vendors and finding strongDM, it seemed way better to sort of go with a company that was dedicated to providing that.

    Shimel: Very cool. Now, it would seem to me and, you know, I’m not the expert here, you guys are, but Liz, you know, when they’re setting up this sort of account opening app or online account opening app, that seems like something that strongDM would definitely be of much help to, no?

    Zalman: I think it was. I remember, James, I think, in our first conversation, you had very, I think the interesting thing about the MANTL team—whatever, it’s interesting about all my customers, but MANTL has a very clear point of view on the way that they want to do something in order to honor what their customers need. And so, James has always had a very clear point of view of, “We need something implemented like this, for these business reasons. I’ve tried on these other solutions. They don’t work for reasons X, Y, and Z, and so actually, MANTL is one of our most sort of forward-thinking, pushing the boundary customers that exist.

    I remember, James, when it came to setting up HTTP access for your internal employees and talking about header redaction and—I think it was Vault?

    Qualls: Vault.

    Zalman: The hosting of Vault, yeah. I was like, “Alright!”

    Shimel: Secrets.

    Zalman: “Gotta upgrade that.” [Laughter]

    Shimel: Yeah, no—Vault’s huge, right? I mean, you know, Vault is a little-known power—not little-known, but to those in the industry, it’s little-known, but outside of it? I mean, Vault may be HashiCorp’s biggest, you know, product, and they have some great products.

    But so, James, you know, Elizabeth’s kinda thrown you under the bus here, a little bit—it all comes to you. [Laughter] So, you know, how did the mission—you know, what else did you look at? What are the kinds of things, right, and how did you come on strongDM?

    Qualls: Yeah, so, I would say that we have, I would say the top three resources that we needed to gain access to—one, obviously, Vault, which, you know, it’s an HTTP based product, but you know, we could’ve gone with Cloudflare Access, ______ we could’ve gone with Google’s Identity-Aware Proxy. But the bottom line is that it’s much easier to manage and provision access if the system that you’re using is consolidated into one product, and I don’t want to have to manage access to these resources across three or four different products.

    So, we continued to look around and when we found strongDM, the first thing that we provisioned access for was databases. That’s something that no other product on the market does better than strongDM. strongDM covers a number of database protocols, we happen to be obsessed with Post Press. But strongDM supports things like Cassandra, things like BigQuery—so, you’re not necessarily limited in terms of protocol.

    There was an alpha that they were running where we got immediate access to the ability to not only proxy to databases through strongDM but also to proxy to HTTP based workloads. Vault happened to be the use case, and the e-mail that Liz is referring to is when I was talking about the audit logs and strongDM actually logging the Vault tokens in the early alpha and I requested that we have some kind of header redaction. And her team took our feedback immediately and within a very short period of time, they had implemented a fix or that. And to be honest, even in the alpha, the product was very usable. We were able to use it immediately and no one really knew that we were in an alpha, the product just worked. So, essentially, we were able to consolidate access to resources that we had actually been using private tunnel, a Pritunl, to run a VPN to those resources.

    After migrating to strongDM and after finally providing access to all of our resources, we use Post Press, Kubernetes, Vault, and there are some other internal resources that we provide access to all through strongDM, we were finally able to kill that VPN. So, we are an entirely identity-aware system at this point, purely because of strongDM. And then we have an added benefit when COVID hit, we were able to entirely go remote, because we didn’t have to scale a VPN. And this product is super high performance. We haven’t run into any bottlenecks, either, so you know, we’ve quickly grown over the last two years from 11 to almost 50 people now. And we’re all—all of us are presently remote, and all of us are using strongDM.

    Shimel: Very cool, very cool. And I don’t know the answer to this, and I hate asking questions I don’t know the answer to, but is there an application to use strongDM outside of MANTL’s own internal workforce for some of these banks, credit unions, you know, small to medium banks and credit unions as they—because, you know, there’s all kinds of financial regulations that you’ve gotta deal with here from q compliance standpoint and everything else. So, do you use strongDM beyond the internal MANTL team?

    Qualls: Liz and I have had a conversation about that, about potential applications for strongDM’s technology. I would say that probably MANTL’s biggest technical hurdle, when we’re integrating with a new bank is setting up network connectivity. And traditionally, that is, it’s by and large, it is usually an ________ VPN that we’re connecting to. And I see a potential application for strongDM there, although we haven’t attempted to see if it would work, or if one of our customers would actually be—or find that acceptable. [Laughter]

    Shimel: Ben, I’m curious what you think about that.

    Conant: Yeah, I think there is a huge market of banks that, you know, beyond just connecting to MANTL and allowing MANTL to operate with their sort of legacy systems, there is a huge market within banks where they have exactly the same problem, right? Like, people who are analysts at banks need to access lots of different data that’s all siloed in different data sources and different sort of network resources. We’ve heard a lot of our customers really struggling to set up or scale their own VPN solutions. And we’ve also worked with them to kind of, like, try and help mitigate those issues.

    But I think that strongDM is definitely a product that banks themselves should consider adopting, right? Because in the same way that it helps MANTL employees have highly compliant and secure and easy to manage access to the resources they need to do their jobs, banks have that problem but almost way larger than MANTL because they are 500 person organizations or 1,000 person organizations instead of a 50 person, you know, software company.

    Shimel: Yeah. I mean, because that was my thought on it, too, is these banks—I mean, the kinds of issues you’re talking about, James, that you guys are dealing with at MANTL and why you would use a strongDM kind of solution, you know, the small banks, community banks, credit unions—they got this, they have the same issues, right? Maybe some of them still are, you know, on legacy infrastructure, but if anything, I would imagine this whole COVID thing is accelerating their transformation there as well.

    Qualls: Absolutely. When COVID initially hit, you know, we had several banks, you know, just scrambling to scale their VPN infrastructure or bank—you know, some people were not actually even able to go beyond a certain point and they had to reconfigure their entire network topology as everyone was forced to go remote.

    In terms of, you know, in terms of how strongDM can be applied, I think that with COVID being a driving force behind that, I think that there’s definitely an opening for banks to start adopting newer technology, and strongDM is so easy to operate. It’s literally a don’t even think about it product. When we deploy it, we have the pleasure of deploying it on Kubernetes, so, we literally don’t even think about it. Scheduling and everything happen automatically. But strongDM is very well packaged. It’s a small binary, you give it a token, and you start it on any server you want. Yeah.

    Shimel: You know what, Liz, it sounds to me like James is giving you your new sales channel.

    Zalman: I actually just wrote that down. “Kubernetes—we literally don’t think about deploying it.” [Laughter]

    Qualls: Yeah. [Laughter]

    Zalman: No, customers have the best way—customers are the best from a product marketing perspective because they perceive the industry as they perceive it as a practitioner, and I’m—well, we’re practitioners, we’re also vendors. And so, their language is always the best. And they always know the right way to do things, I think.

    So, I can actually think of two product changes that James had requested. One was the header redaction in Vault, but the other thing was when strongDM deployed support for Terraform. The very first thing that James asked for was, “So, it’s great that you have a provider, but I need to be able to read in all of my configurations before I go and add strongDM to it, so when are you gonna support Terraform import?”

    And so, it’s very similar, right? You have practitioners, you have very forward thinkers for, like, “This is the right way to do things, and can you help me align to that?”

    Shimel: Excellent. Hey, Ben, I got a question for you. You know what? I love doing interviews with people like James and Elizabeth and we knock around things like, you know, Kubernetes and Terraform and Istio and maybe Cloudflare and stuff like that.

    But Ben, you know, you’re CTO and co-founder, you’re going to talk to these small community banks and credit unions, and even their IT departments, do they, you know, when you start bandying about stuff like this and this is—you know, does that resonate with them, or do they just say, “Hey, that’s why we have you here. You deal with that stuff. We’re not interested in what Kubernetes and strongDM is”?

    Conant: I think that there’s a very real sense in which the banks that are our customers are really purchasing as a service a large part of their company’s technology stack, right? So, if I’m the CTO or the CIO of the bank, you know, I’m trying to figure out, how do I move to the cloud in a way that is gonna make sense, right? And one big way to do that is to simply purchase MANTL. Because now your entire account opening stack is actually hosted on GCP, and you get all of the security benefits of that. And in the same way, you know, your—you want to be very involved with the decisions of, like, “Well, what technology is my vendor actually running?” Right?

    So, I think that the forward-thinking banks really do take it seriously and ask a lot of questions about our stack. I think maybe more importantly, you know, there is a very intense vendor due diligence process that even the smallest banks in America go through before allowing themselves to work with a technology vendor, right?

    And so, one thing that strongDM really helps us do is, you know, maintain a state of what we call perpetual compliance, right? So, we have an amazing Director of Security at MANTL, and we undergo SOC 2 audits, PCI audits, and other types of security audits every year. And, you know, having the capabilities that strongDM comes with out of the box allows us to, at a moment’s notice, produce the documentation that’s required for a SOC 2 audit for a lot of the stuff that we do. And that keeps our customers very happy. Because not only are they concerned with, “Oh, wow, you guys are on GCP, you’re using Kubernetes, you’re way ahead of the curve relative to the other vendors that we could go with,” but they also like the fact that we sort of breeze through these audits and are able to provide them with answers to the tough vendor due diligence questions that they do ask in the sales process.

    Shimel: Excellent stuff, man. Liz, I’m wondering if what Ben says he’s seeing kinda is parallel to what you guys see as well that, you know, especially dealing within the financial industry and fintech, there is sort of a high bar of due diligence in terms of is strongDM really secure, compliant, no back doors or—you know, I’m not creating a bigger problem by solving, trying to solve another problem.

    Zalman: Certainly. I think it’s twofold. So, companies get to a certain size where—and we’ve experienced this in fintech where they’ve rolled their own for some time, and then it gets to the threshold with respect to security RFIs they need to answer or they’ve hit a threshold in terms of employee base where they say, “Okay, I actually don’t wanna develop a core competency in identity and access management, and I want to offload that to a service provider.” Similar to how MANTL solves, essentially, a hosted web app and flow for credit unions to come into the 21st Century.

    And then, certainly, as part of any diligence process with us, we get asked, “What are your security—you know, what do you attest to? What are the results of your pen tests?” We did SOC 2 type 1 when we were eight people large, because it was such a core part of the sales process. I think customers want to be able to buy something that they have confidence in every aspect—that it provides the services, that it’s high availability and doesn’t go down and that it is as secure and people do what they say. So, certainly, that’s been a big part of the software since 2016.

    Shimel: Wow. That’s a while. Alright. Guys, we’re about out of time, but I realize MANTL, for people who want to get more information on a hot fintech startup out of Jersey there, where can they go on the web?

    Conant: Well, MANTL.com, M-A-N-T-L dot com, and you can actually see on James’ shirt it has the correct spelling of our name. But that—

    Shimel: Nice billboarding, James—good work.

    Conant: [Laughter] If we were both wearing that shirt, then it would’ve been a little bit weird, but I’m glad that it’s James and not both of us.

    Shimel: It wouldn’t go on the ISS anyway, so you know, you’re dressed appropriately, Ben—we’ll let it go.

    Conant: MANTL.com is a great place, there’s also been a number of industry publications about us, talking about how we’re helping in American Banker and others, helping community banks really become fintech companies, which we believe is their future, right? We think that all these fintech companies are trying to become banks. If you look at SoFi or you look at Simple Bank or any of these up and comers—really, you’ve got these small banks that, if they just had a platform to move and really innovate from a technology perspective, they are going to become the fintech, you know, [Cross talk] of the future.

    Shimel: It’s funny, they just, from both sides of the spectrum, converging on a common market is what you’ve got there. But Elizabeth, strongDM, for people who may not know, where do we go to get more information?

    Zalman: strongDM—S-T-R-O-N-G-D-M. Here at strongDM, the DM stands for Dragon Matrix. [Laughter]

    Shimel: Okay.

    Conant: I did not know that. That’s awesome.

    Zalman: Yeah, it came up at our last on-site—although, I gotta say, everybody wants T-shirts, and I’m like, “No, no, no. No T-shirts, I want a trucker hat.” But then that would look weird on camera—James’ shirt is much more effective on camera, so.

    Conant: [Laughter]

    Shimel: Yeah, no—the shirt works, James. Good work. Hey, guys, we’re gonna call it a wrap on this segment here for TechStrong TV. James Qualls, Ben Conant—did I mispronounce it? yeah okay—from MANTL, and of course, Liz Zalman, from strongDM. Thanks for joining us. This is Alan Shimel—we’ll be right back with our next guest.

  • MediaOps Teams with Gary Berman to Add “CyberHero Adventures: Defenders of the Digital Universe” to Its Award-Winning Lineup of Video Series

    MediaOps Teams with Gary Berman to Add “CyberHero Adventures: Defenders of the Digital Universe” to Its Award-Winning Lineup of Video Series

    Hacking Victim Turned Cyber Advocate Gary Berman Joins MediaOps to Co-Produce and Distribute His Unique Show Highlighting Cyber and IT Thought Leaders Protecting the Public

    Boca Raton, Fl – Sept. 14, 2020 —  MediaOps, the place to tell your story in the most powerful way, today announced it has teamed with hacking-victim-turned-cyber-advocate Gary Berman to co-produce and distribute the “CyberHero Adventures: Defenders of the Digital Universe” video podcast. The show will join MediaOps’ award-winning lineup of video programming including TechStrong TV, DevOps Unbound and CISO Talk, all on the Digital Anarchist platform.

    “CyberHero Adventures: Defenders of the Digital Universe” is an educational and entertaining series based on interviews with cybersecurity and IT thought leaders who protect the public from cyber attacks. Berman conducts in-depth interviews with industry experts to discuss real-life cyber crime stories, anecdotes and lessons learned.

    Berman was a victim of cyber criminals earlier in his career, when he ran his own marketing firm, which ended in the loss of his business. Berman pivoted from being a victim ​to becoming an advocate, and after a 25-year career in marketing, entered the cybersecurity field with a mission to protect others from suffering the life-altering consequences of being hacked. In each episode, he shines a light on all the unsung heroes who toil in anonymity to keep us safe at work, home and school.

    As an advocate, Berman was challenged by the complexity of cyber technology, attempting to distill complicated technology information into a communications platform accessible not just to the cybersecurity community but also to the general public. With support from the tech community contributing real-life stories of cybercrime, Berman launched the cyber hero comics series. The “CyberHero Adventures: Defenders of the Digital Universe” show was launched from the comics.

    “I am proud to join the world-class professionals at MediaOps, as the next step in accomplishing my mission. Together, we are creating a highly engaging, entertaining and informative show that will be the antidote to the ‘Zoomification’ of the cybersecurity and IT community,” said Berman.

    “Gary brings a fresh, unique perspective to his cyber awareness mission. We look forward to working with him and making his show a must-watch for both the cyber community and civilians looking for sound cybersecurity advice,” said Alan Shimel, CEO of MediaOps. “Our mission is bringing quality programming to our ever-growing audience across our omniversal channels. The CyberHero Adventures video series is a great example of this.”

    “CyberHero Adventures: Defenders of the Digital Universe” will be available via the Digital Anarchist network and streamed via TechStrong TV, which is available on the web at LinkedIn Live (devopsy.kinsta.cloud page), Facebook Live (devopsy.kinsta.cloud page), YouTube (DevOps TV channel), Techstrong.tv, DigitalAnarchist.com and the MediaOps community sites (devopsy.kinsta.cloud, Security Boulevard and Container Journal). The show will also be available 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 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.

     

    ABOUT MEDIAOPS

    MediaOps, the place to tell your story in the most powerful way, is an omniversal media company covering IT industries and practices that are re-shaping the world of technology, including DevOps, Cloud-Native, Cybersecurity and Digital Transformation. Through a convergence of new media distribution platforms, we deliver the experiential stories IT professionals need to gain fresh insights and learn new skills. For marketing partners, MediaOps delivers unparalleled access to inform and engage with a highly involved IT community, for thought leadership, demand generation and specialized campaigns. MediaOps is not only the most trusted name in technology media, but the most loved as well.

    ###

    Contact

    Rebecca Auguste

    rebecca@mediaops.com

    (561) 430-3347

  • TechStrong TV: strongDM Helps Kustomer Go Remote

    TechStrong TV: strongDM Helps Kustomer Go Remote

    For a procurement process to be effective, the relationship between the customer and the product team is almost as important as the functionality and features of the product itself.

    During this interview for TechStrong TV, strongDM CEO Elizabeth Zalman and Steve Flinchbaugh, senior SRE at Kustomer (a customer support CRM platform for managing high support volume effortlessly), talk to us about the strong bond between the Kustomer team and the support team at strongDM.

    Steve explains how Kustomer uses strongDM to empower its remote teams, how it fits into their development workflow and how strongDM has made his and his team’s lives easier.

    strongDM allows remote teams to easily manage access to databases, servers, Kubernetes clusters and web apps.

    Check out the interview below and follow along with the transcript to find out more.

    Transcript

    Alan Shimel: Hey, everyone, thanks for joining us for this next session here on TechStrong TV. This is gonna be a really good session; it’s something we haven’t done before. I have two guests, which we’ve done before, but we’re really gonna zero, we’re gonna take two different companies and see how they interact and how that helps, especially given everything that we have going on around us.

    Let me introduce my two guests to you first. First of all, we have Elizabeth Zalman. Elizabeth is the CEO of strongDM. We’ve done—I think we’ve done at least a podcast and so forth with strongDM before. Liz—hey, welcome, thanks to TechStrong TV.

    Elizabeth Zalman: Thanks, Alan. Nice to be here.

    Shimel: Thanks for joining us. Okay, and then joining Liz and I is Steve Flinchbaugh. Steve is with a company called Kustomer, and that’s spelled with a K, and he’s gonna tell us about it, as well as his position and background there.

    Steve, why don’t we start off with you, okay? Kustomer with a K—what do you guys do, and what do you specifically do at Kustomer?

    Steve Flinchbaugh: Sure, Alan. Thank you for having me. So, I’m a senior SRE at Kustomer, and what Kustomer is, is a CRM for customer support. And we really are built off of our platform. There’s a lot of intelligent automation that allows our customer service teams, our customers, to give the best possible customer experience they can and accomplish their customer service goals through, ideally, less staff and less effort using our platform.

    My goal as the senior SRE is to ensure the reliability of our platform, the kind of implicit trust that everyone expects, and to make the job for our developers as easy and seamless as possible.

    Shimel: Cool. So, a real, live SRE right here on our show—very cool. You know, there’s a lot—I don’t know if you guys have seen, there’s been a lot of articles written lately in the press around, you know, are we overblowing the whole SRE thing, right? And is it real, how real, and where does it fit in and all of these other things.

    But anyway, Liz, we gave Steve a good chance to tell us about Kustomer with a K. Let’s give you your chance—tell us about, remind our audience about strongDM.

    Zalman: Yes. Steve is one of my favorites, by the way—so is Kustomer with a K. They’re one of the most forward thinking customers with a C that we have. [Laughter]

    Shimel: Okay. Very good play on C/K, there. [Laughter]

    Zalman: strong is a—it’s a proxy, it’s a control plane, it’s insert whatever word you want there and it lets you manage and audit access to servers, to databases, to Kubernetes clusters, to whatever infrastructure you’re running that is firewalled. So, typically, that access is managed by hand, or keys are sitting in a box or a vault somewhere, and we let you collapse all of that down into a single control plane for both the management and auditing of that access

    Shimel: Yep. And I just—look, I feel like we have to mention that, you know, given the whole COVID situation and working from remote, you know, strongDM has been a real godsend to a lot of companies who had to kind of flip a switch and empower remote people to have access and stuff that, you know, from a different place on different machines, devices than they had before.

    So, though strongDM had a great case before COVID, right, a great use case, post-COVID, Liz, how many—you know, I’m not asking for the amount of customers, but I mean you’ve seen a lot, I imagine you’ve seen a lot of activity from customers who are, have switched to remote and need help with that.

    Zalman: Yeah, certainly, it was challenging before. I think most companies today have remote workers, anyways, or multiple office locations. With the lockdown with COVID, I think what ended up happening is, for companies who rely on the corporate network itself as the perimeter within the building, that perimeter is now gone, and so, what do you do? If you’re using something that’s IP-based, all of a sudden, your IP surface area went from, like, two to 5,000 if you’re an enterprise.

    So, we certainly saw a doubling down of existing customers and an increase in interest in the product. I might ask Steve, like, could you have imagined what—I mean, what was it, like, you guys have an office in New York…do you guys have remote workers? I don’t—yeah.

    Flinchbaugh: Yeah, so, we have an office in New York and we recently—that’s our headquarters—and we recently acquired some office space down in Durham, North Carolina. That’s kind of our first official outpost, and that was kind of our introduction to people outside of New York, and it was—this was after we had adopted strongDM, and I have to say, it was entirely seamless. And ever since the pandemic began, I know it’s good because I haven’t thought about it that much. strongDM is—

    Shimel: That is always the sign. You know what—sorry—I was in security for 20 years. They didn’t call it cyber then, it was InfoSec, but we always used to say, “If they didn’t think about it and it didn’t hit anyone’s radar screen that they—you know, that was a good thing.” When people hear about security stuff, it’s because something bad happened.

    But I wanna make a point here, though, and that is—Steve, it’s my understanding you guys didn’t, you’re not a Johnny come lately to strongDM. You guys were using this well before COVID and the present situation. Talk to us—let’s go back in time to then, it was about a year and a half ago, right?

    Flinchbaugh: Yeah. And actually, if you don’t mind, I’d like to go even further back in time, about four years ago—

    Shimel: Be my guest.

    Flinchbaugh: – when I joined Kustomer.

    Shimel: Okay.

    Zalman: You joined it four years ago?

    Flinchbaugh: Four years in September.

    Zalman: Wow! How big were you then?

    Flinchbaugh: I was, I think, employee number 16. We were still in stealth mode, we weren’t charging our customers yet, and Steve comes into Kustomer bright-eyed and bushy-tailed. But at this time, we were running agents on our servers to provide SSH access to our engineers, and I was charged by the CTO to stand up a VPN, which I had never done. And this came in the form of open VPN, and I had to manage the certificates and the log-in and the users and every employee that joined the company, I had to on board them and configure a profile.

    And then, fast forward to, I think it was about a year ago, where the CTO again came to us and said, “Hey, there’s a really cool company that I think we should take a look at. We have a mutual investor, and they have a lot of cool features that we haven’t had for the past three years.” So, we had a couple really cool meetings with Liz and her team. I could immediately tell that we were working with a team that knew what they were talking about, they were technical, they were fun to work with and they kind of just got what we needed out of the tool.

    And now, today, there are so many things that are taken off of my plate in addition to more features for security and making developers’ lives easier that strongDM now gives us.

    Shimel: Very cool, very cool. Alright, now, we can fast forward to Durham and how strongDM helped with the rollout there of a new—I don’t wanna call it a remote office, but I think you used the term outpost?

    Flinchbaugh: Yeah, so, it’s definitely, like, our—we call it HQ2, I believe, but we’ve got a fully functioning, we call it squad, so we kinda have self-sufficient and cross-functional teams out there, and everywhere across the country, but Durham was our first remote squad, if you will.

    And the neat thing about strongDM is, I don’t necessarily have to say when a new user joins, when someone joins the company, there’s not necessarily a task in my to-do list. It’s so self-service with our Okta configuration, a user can go in and say, “Hey, I wanna start using strongDM, I’ve heard all about it. How do I get access to our data storage and our private resources?” And at that point, I get an e-mail, I can add them to a roll, to a group, and they’re happily on their way. So, I don’t need to configure a profile, I don’t need to do anything special for these individuals. So, from my perspective, it’s incredibly easy to onboard new and remote folks.

    Shimel: That sounds like too good to be true. Is it true, Steve?

    Flinchbaugh: [Laughter] It does feel too good to be true sometimes.

    Shimel: Okay, and you’re saying you guys use Okta for a lot of your IAM and stuff like that?

    Flinchbaugh: Yeah, part of our maturation as a company, you know, back in the day, we had, of course, authentication and identity all over the place and now it’s much more unified. All of our tools that can integrate with Okta, it just makes it that much easier. And again, it’s just things that I don’t have to think about as often

    Shimel: So, Liz, let me throw something back at you. Again, the whole IAM space is something I’m somewhat familiar with—how important is it for strongDM to integrate with an Okta or ADs or other kinda directories and stuff like that

    Zalman: It’s critical. It’s one of the core principles of the business. I think, you know, I’m guessing, Steve, the customer made the decision to buy Okta well before strongDM.

    Flinchbaugh: I think it might have actually been around the same time—but yes, I think Okta was shortly before strongDM

    Zalman: Yeah, so, you have to start with the question of, “What is my identity store? What controls identity, and then how do I integrate that identity store with everything else?” So, strong has integrations with all of the SSOs—because I don’t want to reinvent the wheel. Steve’s already invested a bunch of money in Okta. He’s already reinvested a whole bunch of money in whatever he’s using for automation, Terraform or otherwise or an Amazon tool. Most companies have already invested a whole bunch of money in Splunk or Sumo Logic or QRadar, whatever they’re using for logging, I don’t need to reinvent the wheel with logging and alerting, I just need to make sure there’s a connector between the two.

    And so, honoring what people have already invested a whole bunch of money in and sort of bet the farm on already is critical.

    Shimel: Yeah, you know, Steve, you’re an SRE, so you live this every day. But it’s something—I’m an observer now. My days of those battles are over, right? But as an observer, it’s still, I shake my head sometimes, because so many companies like Kustomer, right, have kinda made their bets on the tools that they use, right? They’ve put together an identity in access management, but it’s not log management, cloud platforms—you know, your whole tool set. But yet, there are still plenty of companies who are trying to say, “No, no—you should use us for everything, right? We can sort of do what strongDM does.” You know, and you know the old saying with this, right? They try to give you 80% of the functionality for 40% of the price, and if that’s good enough for you, it’s good enough, right?

    And I was never a fan of that model—Liz, you’re laughing; what do you think? I mean, we see this still, and I don’t—you know, I assume some companies go for that, you know? But I can’t imagine it really works out. You just don’t get the function—we live in a great time where there’s so much available to us to try to make lives easier for people like Steve, for the SREs of the world and the Ops folks. You know, why would you try to just shove everything into one vendor and do, and put up with less than.

    Steve, what do you think?

    Flinchbaugh: So, it’s definitely, when you’re a smaller company, it’s, of course, much easier to adopt and drop and try new technologies and vendors. But, of course, as we’ve grown, that cost becomes higher and higher. So, when I first joined Kustomer, we could try new things whenever we wanted, but I can already see in the couple years that I’ve been with the company that implementing something like strongDM would be almost exponentionally more effort now, because I’d have to go through different departments and accounting and finance and communicate with the team, and developers just wanna know, “How do I do my job? Like, just tell me what to do.”

    Shimel: Mm-hmm.

    Flinchbaugh: And more than the functionality and the features of the product, I truly feel like we have a relationship with the strongDM team, and that’s almost just as important to us. We know that they are responsive, that they’re gonna listen to us, that they’re gonna help us out—and they have, you know, literally weekly.

    And that is so important to us as customers that, if someone came along and said, “Hey, we’ll charge you 50% of the price that strongDM does,” I don’t think I would be too tempted to consider that right away.

    Shimel: Yeah. But I think that goes to the model today, right? It’s part of this whole cloud native, open source, freemium core, open core, whatever you wanna call it, which is—the key is not to go hire some enterprise sales guy who comes by and wines and dines people. It’s about—hey, here’s the product. Let me get the product in your hands, right? Let me deliver delight, as they say, right, with that product, and the bonds that are formed from that type of relationship, right, it’s—if you wanna call it DevRel, you know, a lot of people call it developer relations and community relations—those sort of bonds are much stronger than the old sort of sales game that I grew up in, for instance.

    Elizabeth, with what Steve is saying, is that sorta news to you that it’s much easier to get in and kinda grow with these customers than it is to kinda come in when they’ve reached a certain scale and it’s a lot harder to get adoptions done

    Zalman: Certainly, it’s easier when a company is young—50, 100, 150, even 200—to get implemented. I think to Steve’s point, eventually,  you have a procurement department, and then you have to go through the traditional, like, “Oh, that’s the price? Okay, we’re gonna knock it down by 50% now,” right, and that’s just how the operate.

    Shimel: Right, yeah. Mm-hmm

    Zalman: And certainly, there are much longer sales cycles in the enterprise side, with a company of Kustomer’s size. Even the size today, you know, two week POC and you can play with it enough, to your point, Alan, where you decide if it’s right for you, if it fits enough of your requirements.

    With larger enterprises, it’s—and again, to Steve’s point, it’s not…you do have to go team by team, right, at a larger enterprise and say, “Okay, we’re gonna do the finance team now, and then we’re gonna do the engineering team, and then we’re gonna do the DevOps team.” And it’s sort of rinse and repeat and you get the hang of it after a while, but it’s bite sized chunks, always, whether the bite sized chunk is the entire company at once, or work group by work group.

    Shimel: Yeah. And I think that very much mimics the whole DevOps adoption pattern as well, right? You don’t go in and just turn on a large enterprise to DevOps, you do it bubble by bubble, team by team, right? And quite frankly, the other thing is, though, is I will tell you that sometimes that procurement process and all the b.s. that goes with it is why developers or DevOps people will whip out a credit card and just do it, right? And you get the whole shadow IT thing or whatever you wanna call it, but it’s like, who wants to—you know, I gotta sit and explain to this person why strongDM makes my life easier? You know, I mean, it’s—especially someone who has no technical background, it’s like, you know, where do I begin?

    But, you know, nevertheless, you guys got a year and a half of history here. Steve, where do you see the first squad’s in Durham, I assume that means you guys are planning second and third squads and maybe outside the U.S. and what have you—is strongDM tied, I imagine, tied into that as the roll out moves along here

    Flinchbaugh: Yeah, of course. It’s become the way that we access our resources across all of engineering. And we actually acquired a Spanish company, Reply.AI, a month back.

    Shimel: Oh, very cool.

    Flinchbaugh: Yeah, so—

    Zalman: Congratulations

    Flinchbaugh: Thank you. So, I’ve been having some conversations with the Reply engineers, and I can already tell that they’re impressed with how we use strongDM and how it kind of fits into our development workflow. And so, that would be interesting, because they have infrastructure of their own, infrastructure that we haven’t used before, so it would be a cool opportunity to say, “How does this plug into strongDM?” And I really have no concerns that that would be the case, but it’s gonna be a fun task to get all of that in the same kind of workflow that all of our Kustomer engineers use today.

    Shimel: Excellent. When you say Spanish, like in Spain—they’re based in Spain?

    Flinchbaugh: Yeah, they’re based in Madrid. I believe they’re a fully remote company, though, throughout Spain. So, they kinda have that remote culture, already, so it’s perfect for us right now, and of course, their AI expertise is nice to have, as well.

    Shimel: Absolutely.

    Zalman: Steve, where is their infrastructure? Like, is it in the U.S. in AWS or is it in something sitting in Europe?

    Flinchbaugh: I can’t say too definitively, but I do know that they have a mix of AWS and Heroku right now.

    Zalman: Interesting.

    Shimel: Really?

    Zalman: So, you’ve got a distributed team in Europe and now, effectively, multiple data centers if you’re talking AWS and Heroku that aren’t merged with Kustomer as well—

    Flinchbaugh: Yes, indeed.

    Zalman: Yeah, I see.

    Flinchbaugh: That’s right.

    Shimel: Sounds like an opportunity, Liz. [Laughter] Liz, let me ask you a question—how many, I mean, what I’ve always loved about the Internet is, it knows no borders, frankly, right? I remember the first time I put up websites and I started seeing hits come in from around the world. This is, like, 1996, and I was like, “Wow, we’re global!” Not at Media—you know, not this company, obviously.

    But what is the customer mix at strongDM? Is it international or is it mostly U.S., or—if you know?

    Zalman: Yeah, it’s heavily international. We’ve got, actually, a big contingent in Australia, we have Europe, we have Asia. Our large enterprise customers all have offices in India, whether they’re using contractors as a work force or an actual office there, you’ve got the U.S., you’ve got Canada, you’ve got South America.

    Oh, and you know what? Actually, I was just gonna say we’re not in Africa—we’re totally in Africa, so it’s everywhere. And then even, we’re not in the Middle East, I don’t think. But even more interesting, I think, than where the people are, it’s where the data centers are. You’ve got this crazy Cartesian product of people trying to connect to stuff, and most companies—we’re in China, I mean, we’ve got people on, we have workers on factory floors in China who need to SSH into infrastructure.

    Shimel: Very cool.

    Zalman: And so, it’s crazy to think about all of the networking going on, the latency, and how to make that connect, and it’s just personally fascinating to hear the new use cases that come up. I was like, when I heard factory, I was like, “Wow!” And then I started thinking of, like, Tesla. I was like, “I wanna be on the factory of Tesla,” but no.

    Shimel: Yeah. That could be in China, too. You know, it’s funny you bring it up, I actually interviewed a CEO of a company maybe last week who, they are instrumenting manufacturing factories, because a lot of that machinery was not connected that you can, you know, you had visibility, and they actually put things on to machinery that allow you to instrument them and monitor and stuff. There’s amazing things going on. And by the way, each one of those add-ons to the manufacturing machines has to have a certificate, an identity—you know, there’s a whole piece of this, too, and I just think it continues to go on.

    Steve, we don’t have a lot of time left. How has the COVID thing kinda affected you guys?

    Flinchbaugh: So, personally, I feel incredibly fortunate to say that my work has changed almost not at all. I think my position and a lot of our department is very remote friendly, and even though we weren’t set up, really at all, for remote before the pandemic, the transition has been relatively seamless—obviously, from a strongDM perspective, it is seamless.

    But overall as a company, I think—of course, there’s a ton of adjustments with different departments and some are having it easier than others. But I actually think engineering is, our efficiency and output and how we’ve put out features since the beginning of this has actually increased just a little bit.

    Shimel: That’s great to hear, man. Really good. Guys, we’re about out of time. I want to thank both of you—both of you coming at us from New York, today, I should mention, so thanks for joining us. Liz, any last thoughts, comments you want to add?

    Zalman: Nope, I don’t think so. I wanted to say thanks to Steve, and I appreciate the comment on relationship. It’s so important, as I say—you know, at strongDM, everybody touches the customer equally. It doesn’t matter if you’re in account management or support or engineering that I joke that if we were to ever have commissions at the company, which we don’t, I would give support the commissions, because they’re that important.

    Flinchbaugh: As a support company, somewhat as an employee there, I can very much appreciate your support team as well, Liz, and it’s not an exaggeration to say it’s the best support that I’ve received from any vendor, ever.

    Shimel: Very cool, very cool. That’s a good way to end it. Alright, Elizabeth Zalman, CEO, strongDM; Steve Flinchbaugh, SRE at Kustomer with a K—thanks for joining us on TechStrong TV. This is Alan Shimel. We’ll be right back with our next guest.