devopsy.kinsta.cloud

Tag: devops chat

  • DevOps Chat: Modern Applications with SignalFx CEO Karthik Rau

    DevOps Chat: Modern Applications with SignalFx CEO Karthik Rau

    Monitoring has come a long way since the days of 2 a.m. alerts, with automation and analytics now integrated in—and integral to—the life cycle of modern applications. It’s a topic Karthik Rau, CEO of SignalFx, knows well, and one we discuss in this latest DevOps Chat.

    In its three years of selling, SignalFx has grown a whopping 300 percent year over year—an astounding number, even for a startup.

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

    Alan Shimel: Hi, everyone, it’s Alan Shimel and you’re listening to another DevOps Chat. Today’s DevOps Chat features Karthik Rau, CEO of SignalFx. Karthik, welcome to DevOps Chat.

    Karthik Rau: Thanks, Alan. It’s great to talk to you again.

    Shimel: Always a pleasure to have you on. So, Karthik, let’s just do a little setting the base here, baseline setting. And I’m gonna assume most of our listeners have at least heard of SignalFx, but maybe some haven’t and maybe some have heard it but they’re not sure exactly of who SignalFx is. Why don’t we start there?

    Rau: Sure, Alan. SignalFx is a monitoring and operational intelligence solution for the developers and operators of cloud-native applications. Our founding team, my cofounder and our original engineering team, all came out of Facebook and were responsible for building the monitoring systems at Facebook, back when they had a “move fast and break things” culture, which today everyone calls DevOps, but, back then, they didn’t really have a term for it. So, at a high level, what we do different from everyone else is we are focused very heavily on the analytics part of the monitoring problem. We collect data – time series, telemetry data – across the customer’s entire environment, from the hardware to the middleware to the application, all the way up even through the API layer, and we apply real-time statistical models around that data to identify patterns that are unusual and different, and alert on those trends proactively so that customers can get ahead of issues and be more proactive in their monitoring, rather than reacting to a bunch of noisy alerts.

    So our customers are able to, No. 1, get a much better handle of their distributed cloud-native application architectures, understanding the patterns, what’s happening. They’re able to detect issues as they emerge, which is very important in today’s environments because most people are pushing changes out a lot more aggressively, and so you wanna detect changes immediately, rather than wait and discover stuff after you’ve made a number of changes. And it’s particularly important for today’s application architectures where you’ve got a lot of bursty workloads, like with containers, where you’re spinning up and spinning down capacity in minutes and you really need your monitoring systems to be (a) real-time and discover components immediately and then (b) be a lot more sophisticated in finding issues as they happen.

    Shimel: Excellent. And, Karthik, you know, I should also mention that, in terms of UI, SignalFx is one of the best UIs, web-based UIs that I’ve ever seen. And I’ve looked at a lot of applications, a lot of programs, over the year – over the years. Year? I wish it was “year.” And, you know, so – and I’ve told you this before. I’m just think whoever designs the interfaces there is a rockstar, so just mention that, but –

    Rau: Yeah. Thank you.

    Shimel: You know, we spoke a little bit off-mic, Karthik, and we were going over what are some of the new metrics coming out of SignalFx, how business is going, and you mentioned some really eye-popping numbers, right? First of all, you guys are showing something like 300 percent year-over-year growth for the last couple years, which is – you know, everyone will say, “It’s a startup; they’re supposed to grow like that,” but, dude, until you’ve done it, you haven’t done it, so that’s an astounding number. But also a big move into large enterprises. Is that correct?

    Rau: Yeah. So, yes, absolutely. So we’ve been, as you’ve mentioned, tripling our business year over year, since we – over the past year, but significant growth even above that in the early years. We’ve only been selling for about three years. Our customer base is focused quite a bit on mid- to larger-size companies, so we’ve always been focused on larger accounts, whether that’s the web-scale players, who are operating large-scale applications with four or five nines availability requirements, but also a lot of the enterprise accounts, who what we’ve been really excited about is they’re really moved wholesale into cloud and cloud-native application architectures. And we’ve seen that trend accelerate over the last two or three years, so that’s been a large area of success for us. You know, we’ve got Fortune 500 customers across many verticals – media, retail, financial services, industrials, transportation – so we’re definitely seeing that trend accelerate across the enterprise, not just in a handful of verticals.

    Shimel: Absolutely. But, Karthik, what about for the person out here listening to this, right? And he says, “Wow, that sounds great. I love what Karthik says they’re doing and the Facebook kinda background and all of this great stuff, but I’m not a unicorn. I’m not even a large enterprise.”

    Rau: Well, I think that everyone today is trying to build software quickly, right? Gone are the days where you have a three-year development cycle and you release software and hope you get it right. It’s just not gonna work in today’s world of web services and your competition are tech companies that are moving at lightning speed. So the issue isn’t really – the world is changing. The way people are building and releasing and managing software is fundamentally different.

    And what SignalFx does, the analytics around SignalFx, you can look at it in two ways. One way is, yes, if you’re a large environment, you absolutely have to have it to reduce noise, but another way of looking at it is you could be a small environment and you wanna have a more predictive way of discovering issues, as they emerge, so that you too can move fast without breaking things, right?

    And if you look at it that way, having the kinds of capabilities that SignalFx provides are critical, even if you’re a department within a big company or you’re a startup with 50 people or 20 people. You still wanna be able to do the proactive analysis of, “Hey, this code push that I just rolled out, a canary release, is unusual relative to the rest of my application. And maybe that’s indicative of a problem with my code and I wanna roll it back before rolling it out across all of my users.” Right? You don’t have to be Facebook-sized or Google-sized to have that problem. You’re just building a modern application.

    So that’s why we do have customers across segments. I mean, our focus is certainly on the larger accounts, but we’ve got a lot of departmental deals within enterprises. We’ve got a lot of startups that are also using us, who care about having a more predictive approach to monitoring.

    Shimel: Yeah, no, you know, I think the key there – and you mentioned the word, Karthik, and it’s funny; it’s a word I’ve been hearing over and over again. And that this term of the “modern application.” I don’t care whether you’re big, small or Goldilocks. The modern application, as we call it, right, demands certain things, and one of them is obviously monitoring, but also modern applications demand automation, real-time type of data flows and insight. And it’s not just the guys who develop once every few years – that certainly is not a modern application – but it’s also more than just how frequently you update your code. I think the modern application, you know, what goes are in, the kind of stuff, or at least one element of it is the kind of stuff you’re talking about with SignalFx. Right? These go like hand in glove.

    Rau: Yeah. Absolutely.

    Shimel: So I think that’s – so, to me, more than size of company. I mean, that’s almost a determining factor. Another item I just wanted to mention on the – or bring up on SignalFx itself, as a company, is you guys recently announced a rather large round of funding as well.

    Rau: That’s right, Alan. On the backs of all of our success, we continue to build out our product and continue to accelerate our go to market. We just closed a $45-million Series D round in May and we’ll be using that to continue our investment in R&D. We’re continuing to expand globally. I think I’d mentioned to you offline here that we’ve just expanded into Europe. We also recently expanded into Australia. We’ll continue our expansion geographically, so, hopefully, a lot more people across the seas will hear about us and see us, in the coming quarters.

    Shimel: No doubt in my mind about it, Karthik. I can tell you, from – when I look at devopsy.kinsta.cloud’s demographics and metrics and analytics, it blows me away that only about 36, 35 percent of our audience these days are U.S.-based.

    Rau: Mm-hmm.

    Shimel: About 31, 32 are based in Europe. 15 percent in India. Australia is probably the fourth or fifth largest country, for instance, for our readers. So –

    Rau: Yeah, that’s right.

    Shimel: – you know, the thing about this market is it’s truly, truly a worldwide market. And I know, Karthik, if you’ve had the chance to go to China recently, but I was there for Interop China last month, talking about DevSecOps, and I will tell you that the DevOps market in China is exploding. I mean, just there’s a lot of people there, obviously, as there are in India, but DevOps is really catching fire.

    And, as you and I were talking about offline, Karthik, it’s one thing if you’re chasing that crowd or you’re chasing that wave. In the case of SignalFx, it’s a beautiful thing, where, maybe when you did launch, you were a little out ahead of the market, a little out ahead of the state of art, but they’re catching up to you now, right? They’re coming. And it’s good to be there, waiting for them.

    Rau: Yeah, absolutely. The market – what’s been most interesting about – you know, at SignalFx the last several years, has been, when we launched the company three years ago, our – what we did that was so different from everyone else is we had this real-time streaming analysis engine, streaming analytics engine, that could apply these sophisticated models within seconds across large data sets and help you be a lot more predictive in identifying issues. And no one else was doing it that way and still no one else is doing it that way. And, at the time, people would ask us questions of like, “Well, what does it really matter if you can do things in seconds versus minutes? ‘Cause the human attention span is only minutes and if you wake up in the middle of the night, it might take you minutes to go and deal with an alert.”

    Well, that was kind of in the old days. Now what’s happening is there’s so much more automation happening across the entire operations landscape. I mean, people talk about it as infrastructure as code, right? You basically automate the entire end-to-end process as much as you can. And, more and more, there are these frameworks that enable greater automation, like Kubernetes, and what we’re finding now is people are really recognizing that, “Maybe we don’t need roomfuls of NAC engineers waiting to find a yellow light or a red light to then go and manually invoke a script from a run book, if we can just automate it.”

    Well, guess what? If you’re gonna automate a remediation like that, garbage in, garbage out. You need quality in. You need to have quality signals. You need to be able to untease signal from noise and you need to be able to do it quickly. And if you can do it quickly, then you can automate quickly and you don’t – the whole notion of having a human wake up and spend minutes orienting themselves goes out the door ’cause you can just – or having the roomful of NAC people responding to it goes out the door. You can just automate it. And then the capabilities of SignalFx then are very unique and very critical to enabling you to drive this end-to-end automation.

    And what we’re finding is now more and more of our customers and marketplaces recognizing this, as they’re embarking down this path of leveraging microservices and automation around microservices and infrastructure as code. Having a system like SignalFx, with its real-time analytics, is absolutely critical. So it’s been fascinating to see that evolve over the last few years.

    Shimel: Yeah. No, for sure. You know, Karthik, it was interesting. I saw an interesting metric today. Something – I forgot who it came out of – Gartner or someone. Within two years, something like two-thirds of cloud deployments will be container-based, which kinda blew me away, to tell you the truth. Have you heard anything like that?

    Rau: I mean, that’s an incredible metric. I mean, I would say we’re certainly seeing a tremendous amount of interest in containers. Well, it’s gone from interest to actual deployments, right? So, two years ago, there was a tremendous amount of interest in it. Nowadays, I would say that is the de facto new architecture, so I think the keyword there is “new,” right? So two-thirds of new deployments, I totally believe that, that that will be the case, 100 percent.

    Shimel: Crazy. I mean, we talk about internet time and the time crunch and it seems to be accelerating like global warming is and climate change is, but the idea that we’d see that kind of number in that kind of time just kinda blows me away. So, Karthik, we spent a bunch of time with this stuff, going over the SignalFx, a little bit about the market, right? Let’s take a look at a crystal ball and gaze into where do you see SignalFx, let’s say, going over the next, let’s say, 18 tp 24 months?

    Rau: Well, we continue to invest across our business, right? So our focus right now is we believe there’s a giant problem that needs to be solved in the industry, which is, “How do you get better visibility and monitoring around the new stack? And then, beyond that, how do you get better visibility into how your operations are impacting your business?” So, as I mentioned at the top of this podcast, we think of ourselves as monitoring and operational intelligence for modern applications, so one of the things that we – we see all our customers go through a similar progression, where you’ll start doing the infrastructure monitoring for this new world, where you gotta look at the entire microservice, versus an individual node, and you start to get into application and look at application performance issues.

    But then, very quickly, customers typically start to look at how are all of these metrics affecting their business, right? You know, “How many of my partners are making API calls in my services? And who are my most expensive partners and my least expensive partners?” Or, if you’re a SaaS vendor and you wanted to do a gross-margin analysis by customer, all of the data already exists in your monitoring system, and we see more and more of our customers extending the use of these systems to answer broader questions around operational intelligence.

    So that’s kind of – those are the three sort of key pillars of what you use a system like a SignalFx for, right? It’s infrastructure monitoring, it’s application monitoring, and then it’s operational intelligence. So our plans, as a company, are really focused around those three pillars. You need to invest in product to support all of the use cases around those three areas. And then continuing to invest in our sales and marketing team so that more and more companies out there can benefit from what we have to offer. So that’s our focus over the next 18 to 24 months.

    Shimel: Fantastic. And, as we spoke about earlier, it’s nice to be out in front of the market, but, Karthik, your job, as the CEO, if you choose to accept this mission impossible, is how do you stay out front of it? You’re right? How do you know – how do you – I mean, you think containers are gonna be dominant, right, so you wanna put that cloud-native dominant. What do you think is sort of next big things coming out there?

    Rau: Well, in our space, I think the most fascinating new set of technology is around service mesh. You know, as more and more of the world moves toward leveraging containers and orchestration frameworks like Kubernetes, the service mesh is gonna be a really interesting way of automatically getting visibility into all of the flows between all of these different microservices, having a control plane to operate against all these microservices. And it’s still relatively young. It’s still in its infancy, but there’s a lot of great stuff happening there, you know, what you see Lyft doing with Envoy and Istio and LinkerD. There’s just a lot of really interesting stuff happening there.

    And the theme here is, as developers own more and more of running their applications and the runtime, what you’ll find is more and more of the stuff that used to be this black-box, proprietary thing that vendors would come in and do in the runtime are just becoming available as a part of the core services. So, in the case of service mesh, a lot of the instrumentation of metrics and traces and monitoring data is just you’re gonna be able to get it by virtue of running in a Kubernetes-style environment and you’re not gonna need these expensive, proprietary agents to come in and collect that data for you.

    So that’s great for customers. It creates a standardized mechanism of data collection and it provides a lot of automatic instrumentation, which is great for customers. Of course, then that just begs the next question, “Well, what are you gonna do with all that data?” So we’re focused on ingesting more and more of these new types of data from these new frameworks and making it even more – the more data we get, the more powerful and rich the context we can provide around our alerts and algorithms and dashboards, so we’re really excited to see that trend continue.

    Shimel: Very cool. Karthik, we’re about out of time. We’re probably over time here. I apologize for keeping you on so long. But, hey, man, you guys are kicking butt and taking names, and congratulations. For anyone listening out there who hears Karthik talk about growing 300 percent at SignalFx year over year and raising $45 million and it sounds like, “Well, la dee dah,” I’ve been there and I can tell you it’s not easy. So congratulations. Keep up the great work and we’d love to check back in –

    Rau: Thank you, Alan.

    Shimel: Let’s not wait a year to check back in with SignalFx. Let’s have you on here sooner than later.

    Rau: Absolutely. Let’s do it again soon, Alan. Sounds good.

    Shimel: Karthik Rau, CEO, cofounder of SignalFx, our guest here on DevOps Chat. You’ve just listened to another DevOps Chat. Have a great day, everyone.

    — Alan Shimel

  • DevOps Chat: Alert Management with Everbridge’s Prashant Darisi

    DevOps Chat: Alert Management with Everbridge’s Prashant Darisi

    IT service management (ITSM) has been around for a long time, but its relationship to DevOps has been nebulous at best. In this DevOps Chat, we explore the connections between DevOps and ITSM with Prashant Darisi, vice president of Product at Everbridge.

    Everbridge is swiftly making a name for itself in the alert management space as a pure cloud company whose roots are firmly planted in DevOps. As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Alan Shimel: Hello, everyone, this is Alan Shimel, and you’re listening to another DevOps Chat. Today’s DevOps Chat features Prashant Darisi, VP of Product at Everbridge. Prashant, welcome to DevOps Chat.

    Prashant Darisi: Thank you very much, Alan. Thanks for having me.

    Shimel: Oh, it’s our pleasure. So, Prashant, you know, just let’s get off the bat, many of our listeners may not be familiar with Everbridge. Everbridge is not quite your usual startup in that it didn’t announce funding last week or something like that. So, why don’t you give your listeners just a quick kinda corporate background on Everbridge?

    Darisi: Absolutely. Now, in the simplest single sentence, I would say Everbridge is the global leader for integrated critical event management solutions. We are a publicly traded company and we were founded following the tragic events of 09/11, where we realized that whether it is cross-team collaboration, cross-department collaboration, cross-city collaboration—there wasn’t a system out there that can connect all the dots to make sure that most important and pertinent information about safety of people, safety of enterprise, IT systems, physical assets and non-physical assets can easily ________.

    And so, that’s how this company got started. We are truly born in the cloud. So, the good news for our cloud customers is that we were not a bunch of on-prem companies that we pushed into one of the cloud platforms and said, “Hey, here we come, adopting the cloud.” From day one, a pure SaaS company. [Cross talk] Today we have more than 5,000 global customers, and we serve about 9 out of the 10 largest U.S. cities, nine out of the 10 largest U.S. investment banks, seven out of the 10 largest U.S. software companies, 6 out of the 10 largest global consulting firms, 6 out of the top 10 U.S. universities, 5 out of the top 10 pharmaceutical companies, all the 4 large global accounting firms, right, and 25 of the 25 busiest North American airports use our SaaS platform to ensure critical communications for anything that affects public safety, enterprise IT outages, cyber attacks, or even terrorist attacks and severe weather conditions. So, that’s who Everbridge is.

    Shimel: Excellent. And that’s very impressive, Prashant. Thanks for the background. You know, certainly, alert management alerting is in and of itself something that is not foreign to our DevOps audience, right? There are several sort of alert management, event management players who have really—I mean, they are sort of your traditional startups, right? They’re not public. I think one was actually acquired yesterday for $120 million.

    Darisi: That’s true.

    Shimel: But—you know, but they don’t, frankly, they don’t have the scale and the girth that Everbridge has, right? So, Everbridge was doing this before there was this DevOps movement and we were all excited about continuous delivery and continuous integration and that kind of thing.

    So, but now, you know, what—I guess my question is, Prashant, what has made the DevOps market interesting to Everbridge?

    Darisi: Yeah, for multiple reasons. One is, we have the platform that can support it, right? So, when we talk about how do we go and reach people—well, DevOps, for us, is more of a cultural change, right? I don’t want to pretend here, saying, “Hey, we looked at DevOps, this was the most exciting thing on planet Earth, and we start calling ourselves DevOps.” So, we are a critical event management company, but the beauty of this is that we drink our own champagne. When we talk about continuous integration and continuous delivery, we have, from a pure enterprise perspective, over 3,800 customers, and all of them get our new releases on the same instance, right? We offer it through ________ as well.

    Now, we could not, obviously, do any of this using a traditional waterfall method, either in terms of the velocity, or in terms of quality. So, when we talk about, do you guys use Datadog, do you use Jenkins, Drone, do you use GitHub, do you put your artifacts in JFrog—any of the popular tools that are out there. We’re not trying to promote any one product. We live, breathe, and die by these processes day in and day out. That’s a survival issue, because we’ve never had what we call an on-prem piece. This is the only way we deliver value.

    Now, if that’s what we’re doing and that’s the platform that helps people communicate and collaborate, why wouldn’t we naturally go into the world of DevOps? Traditionally, of course, we started into the ITSM piece of the world, right? This is where the ServiceNow, Remedies, and the HP SM worlds came into the picture. But, as organizations started shifting, Alan, I remember, I think you wrote—what, two, three years ago, that all the CIOs said 88 percent of them will adopt DevOps in the near future? That’s when even we started pivoting—how can we help these folks bring these solutions together?

    So, the reason why we’ve gone here is, we can obviously help folks communicate with each other. We have about, what, 100-plus communication devices, and one of the advantages we have is, why DevOps is great—companies are also starting to spread their development centers across the world. You know, I’ve done development for—what, two decades, as an engineering guy? But I never was on call, right? But look at where the world stands today.

    And so, if, just like technical support, engineers are starting to follow the sun model where you have a communication system that can cut across countries and do language translation, can you have collaboration tools like Slack, Tribe, HipChat, put it all together? Can you help customers do them with automation? Can you do language processing on who said what, what kind of diagnostic scripts were run? Last time when you patched the system, what were the results of it?

    The analytics of those things—we have the platform, and the fact that we manage 210 million contacts worldwide, and the fact that we can send 2 billion messages, that’s the number we delivered in 2017, and we have access to 100-plus communication devices—it became a very natural fit for us from a domain expertise from within the organization, what a customer that’s doing CI/CD needs, and from a platform perspective of what kind of scale and geographic reach you need to have to bring the two worlds together.

    So, I don’t want to pretend that we are born a DevOps delivery company, but we certainly are a born DevOps product company that today is public.

    Shimel: Got it. So, Prashant, you mentioned a couple things, there, Prashant. The first thing is, there’s a very common fact pattern that I’ve observed in talking to many vendors in the DevOps space, and that is that their involvement in the DevOps market started with their own use of DevOps, right? They started using tools like Jenkins and JIRA and some of the others you mentioned, and that their own use and adoption of these tools allows them to kinda see the benefits, right, of using DevOps, and also then allows them, frankly, to have some credibility when they’re talking to DevOps teams in the marketplace, because you yourself are a DevOps team yourself, right? You understand what it’s about.

    Darisi: Yeah.

    Shimel: Understand? Yeah?

    Darisi: Yeah, absolutely—completely understand. And, I think it’s, for us, just look at our own organization, right? And I don’t know how many of your listeners will agree. We have offices in Los Angeles, right here in Burlington where I’m sitting, Lansing, Beijing, London and Stockholm. Now, not all of them are development organizations, because we have grown organically. But we need to scale down that framework and true DevOps practices to keep ourselves, have some semblance of sanity. Otherwise, you know, we go nuts.

    So, I do agree that, because we live and breathe these systems, I hope we are able to deliver our solutions with a credibility both from a domain expertise perspective, but also, a very natural alignment with the tools that the customers are using, right?

    Shimel: Yep. Excellent. And then, Prashant, you brought up another kinda topic that we have been kinda running into and writing about more recently here at devopsy.kinsta.cloud, and that is the whole relationship between ITSM and DevOps, right?

    I think initially, you know, we started devopsy.kinsta.cloud back in 2014, there was this feeling of sort of ITSM goes with waterfall, if you will, or it’s from that generation, and that somehow DevOps and ITSM were mutually exclusive. But the fact is, what we’ve seen in real life is that that’s not the case, right? That there are—ITSM, there is a bridge from DevOps to ITSM and back. And that there are, there’s—you know, I always like to tell people, Prashant, there’s only one truth. I don’t really care what you call God or, you know, we’re talking about religion, right? Good is good, bad is bad, and truth is truth.

    So, the right things that we’ve learned to do in ITSM shouldn’t become wrong things in DevOps, right?

    Darisi: Yeah. [Laughter] Yeah. So, since you used the word God, I will say amen—you hit the nail on the head, right?

    Shimel: Yeah. [Laughter] Okay.

    Darisi: I’ll give you a simple, Alan, here’s the analogy, right? I need to go from here, Burlington downtown, a lot north of Boston downtown, and I need to go from here to there. I could walk, I could take a small car, or I could take a BMW. Now, if my GPS is wrong, a BMW will only take me to the wrong place faster, right? It’s, in the end, whatever we use—tools, methodologies, anything—they’re a means to efficiency. It starts with a cultural change, right? Putting the right processes in place, and then automating these processes for efficiency reasons.

    So, I would argue that—like I said, I just came back from meeting this very large priced customer, oil, and you could feel that the DevOps team thinks ITSM or ITIL or COBIT or any of these things—these are dinosaur practices. It’s not. Actually, you can use the elements of DevOps principles within ITSM. And you’re not going to solve everything using DevOps, because if you look at our shadow IT, there are some systems and infrastructures that are still being held traditionally in data centers that need to be highly secure. Then there is this concept of business driven apps where folks like to use Salesforce.com for their pipeline management. You’re not in control of that any more.

    So, somehow, you have to be able to figure out what’s the dependency of the so-called shadow IT system sitting in the cloud, completely managed by a third party vendor through an SLA agreement, and you’re on prem in your own private cloud enterprises.

    And so, I think the reason why people thought or still think, I think, ITSM is waterfall is this whole notion that, culturally, ITSM or ITIL or COBIT practices are all about who controls, right? Well, rather than talking about who controls, if the same principles can be applied within an IT organization to start enabling the business, start empowering the business to say, “Okay, you are in the better position to make the judgment call on something simple like access request, or what are the things that you need to look for when you deploy a patch or upgrade, and we will take care of the security aspects of it, and if something goes wrong, we will ensure proper communication and collaboration”—I don’t see any friction between the two worlds.

    There’s a tremendous difference in lexicon, for sure, but many, many banks and many, many organizations which are true IT organizations are saying, “Prashant, do you follow the agile model?” Right? “We are doing project management doing agile now. Oh, you’re coming here to do an implementation and integration of DNC Committee or ServiceNow or HP SM? Can your PS implementation team help us break it down across our sprints?”

    So, everybody has now started looking at the value of agile frameworks and beginning to see that, you know, the two worlds are coming together. And obviously, they’re embedding, from an HR perspective, people into each other’s team as well. So, then we talk about site reliability engineer, DREs, ________ operation folks, development folks, and perhaps even infrastructure folks all sitting in a standup or around a standup table. It’s all coming together.

    So, I think this is a little artificial, whether we’re trying to drive this line or a hard line between it, there are definitely different lexicons, but I think there is an easy way to bring these people together from a process perspective.

    Shimel: I agree 100 percent. And I think we’re seeing that kinda play out, right before our eyes in real time now. You know, we’ve seen, for instance, ServiceNow come out with a DevOps related system, right, that brings a lot of this together as well. I’m also involved and one of the co-founders of DevOps Institute, the DevOps Institute, and we have a drill down class on the bridge DevOps to ITSM.

    So, I think that’s all there. But Prashant, as much as there’s a bridge being built and we’re learning how ITSM and DevOps works together, another thing we’re learning is how critical event management works with so many of these DevOps tools—and you mentioned some earlier on, but can you share with our audience, give us an idea, you know, we talk about automation and stuff like that—how does Everbridge help with that?

    Darisi: Yeah. So, we’ll take it at the, let’s say, 10,000-foot level, and I’ll quickly and rapidly try to bring it down to a simple tool. But when we talk about critical event management, for us at Everbridge, a critical event or a disruption is a disruption is a disruption.

    And so, since I gave the example of a tornado approaching a building in Oklahoma City, let’s stick with that. Now, whenever such an event occurs, we know what is going to get impacted, but I’m not sure people do get that. For example, clearly, we know some people will be affected from purely an evacuation perspective. We know that the buildings and the physical assets within the buildings will get affected, and then we also know that we might be hosting a data center or a set of services that are going to get impacted.

    So, how can we help our customers figure out what we have coined as a consequence map. What is the consequence of a critical event or a disruption to a company’s business, both from a people perspective, physical assets perspective, and enterprise IT operations perspective?

    And this is where automation starts becoming very critical. How do you understand, from a CMDB integration, what are the components out there, or which business units are affected, right? So, Everbridge, from our perspective, we do CMDB integration on a very lightweight basis. We obviously don’t want to get into the CMDB business, but our job is response correlation, right? We are not in the business of reading logs and packets and telling you about events. We are not a log miner company, we are a response correlation company. When a critical event occurs, there are a lot of connectors and automated tools that will tell us something is not right. Now, there could be a direct correlation from a response perspective on a denial of service attack that goes and impacts the performance of a website.

    How do we make sure that we are helping our customers correlate their responses, right? How are we able to look at the product and location, the services that are impacted both upstream and downstream and trying to figure out, from a communication and collaboration perspective—Alan, you; Prashant, you—both of you are working on this critical event. One came through an item system, a new relic, or somebody telling you, and the other thing comes from a QRadar or a Resilient kind of a system saying denial of service underway. How do you know that you need to combine forces?

    So, Everbridge wants to be in the business of response correlation, far less about event correlation. So, our automation platform or the smart orchestration platform starts picking up data from these disparate sources, integrates with stuff like the CMDB and looks at the CIs and says, “Hey, I see that these critical events are related,” right? For example, a fire in a building can—it’s police, it’s ambulance, and it’s the IT systems that are sitting there—how do we correlate this? That’s the business we are in. And, for that, you need a smart orchestration platform that is looking at data or alerts coming from these different places.

    And then, when it comes to the pure IT pieces of it, right, how do we help from a DevOps perspective? Well, let’s start with the communication part of it. Can we reach out to these people, whether it is on call calendars, making sure that we follow the proper escalation procedures? I heard something else, Alan, you were talking to somebody, saying, “Hey, people still prefer e-mail,” or that’s still the number one choice. Well, in our Everbridge platform, for certain types of events, based on the criticality, we do not give the choice, even though every individual can pick 100 different types of modalities in which they can receive an alert, but for certain critical events, we will override that. We will wake you up during the morning—because guess what? An e-mail cannot wake you up, right?

    So, it depends on those business policies and rules, and that’s the kinda of work Everbridge wants to do. And then, once you have communicated with these people, how do we bring them together? I mean, just today, right, we had to start GoToMeeting, and if I had used the phone, I would put in a 10 digit number, then a 9 digit code, then an audio PIN. Well, the way we help our customers is, when you receive that SMS text, all you do is press 1, and you’re on the Smart Conference page. No numbers to type, no nothing. And if you are sitting somewhere in Europe, somewhere in the Philippines, India, China, U.S., each one of them will receive a local code. So, nobody’s on an international call. If there is a language translation that needs to get done of the same, exact trigger, we help our customers do that, too.

    So, now that you have a bunch of developers who are all responsible for taking care or of the resolution process, people typically will say audio is great, right, and oh, by the way, recording the audio is great as well. Can you enable us through a collaboration tool? So, this is where the second aspect of it comes, right? Whether it is using Slack, using HipChat, Tribe, Cisco Spark—we bring these people together.

    And all of this is recorded or, as long as the customer prefers, they’re all associated with the IT incidents, and then we want to leverage this data for knowledge transfer, for blameless root cause analysis, a post mortem of the events that happened so that next time when a similar pattern of incidents occur, we should be able to say, “Hey, last time when this happened, go and look at that Slack channel or the HipChat channel. We ran these two diagnostics ________. Have you seen this? Do you want to try this again?” And then, our connectivity on the remediation side, people could say, “Hey, I think we should move to Apache server,” right?

    And the way our infrastructure is set up, you can pick a certain set of Runbook procedures that are automated or, Alan, you could get a call and say, “The team that’s presently on call has decided that they need to reboot the server. Alan, you have been determined as the security architect that needs to approve this. Press 1 to approve an automatic reboot of the server, press 2 to join the conference bridge, or press 3 to enter the Slack channel.”

    This whole process is automated, right? Whether it is smart conferencing or the on call schedule or integration with these collaboration tools or the Runbook automation tools and the recording for archival knowledge base and analytics purposes—everything is done with our platform today.

    So, it can take various shapes and forms, but these are some of those key macro cases, Alan, of how our customers are using our product.

    Shimel: Got it, got it. Alright. Prashant, I told you when we started, Prashant, the times goes so quick here. We’re way over time already, but—so, we’re gonna have to call a wrap. Maybe we can come back and revisit and talk more about this within the larger kinda landscape of what we see today in IT as well.

    But for now, let’s call it a day. Prashant Darisi, VP Product for Everbridge, thanks for being our guest on DevOps Chat today, and we hope to have you back soon.

    Darisi: Alan, thank you very much for having me. Looking forward to another conversation. Thank you.

    Shimel: Okay. This is Alan Shimel for devopsy.kinsta.cloud, and you’ve just listened to another DevOps Chat.

    — Alan Shimel

  • DevOps Chat: Modern Apps in DevOps w/ Andrea Martinez Crawford, IBM

    DevOps Chat: Modern Apps in DevOps w/ Andrea Martinez Crawford, IBM

    Andrea Martinez, now Andrea Crawford, is the CTO for DevOps for IBM Hybrid Cloud. In this DevOps Chat we had a great discussion on what is “modern apps in DevOps,” how to upgrade your legacy apps, what to do if your legacy apps are not upgradeable and what this all means for DevOps.

    Great discussion and as usual, the streaming media audio of our conversation is immediately below, followed by a transcript of our conversation.

    Alan Shimel: Hey everyone, it’s Alan Shimel and you’re listening to another DevOps Chat. DevOps Chat today is going to be a good one. We have with us Andrea C. Martinez who is the CTO for DevOps for IBM’s hybrid cloud.

    Andrea, welcome to DevOps Chat.

    Andrea Martinez: Hey, thanks for having me, Alan.

    Shimel: Thank you. Did I get that all right?

    Martinez: So, I’m mostly known as Andrea C. Martinez but I’ve recently gotten married so my new last name is Andrea Crawford. Different last name but the same cowboy hat. So I always wear my cowboy hat in my profile pics. If you’ve got the hat you’ve got the right gal.

    Shimel: And it’s the right Andrea. Okay. No hyphen – Martinez-Crawford or something like that?

    Martinez: Nah, I’m not that fancy. It’s just Crawford.

    Shimel: I’ve got to tell you I just got back from China last week and I was with my partner Jayne Groll, one of the co-founders of the DevOps Institute, and one of my co-founders there, Jayne Groll, is actually now Jayne Groll-Ray because she’s also recently married and what a mess on the – hats off to you – getting your passports done and redone and what name to use because you know it has to match exactly and all your other IDs – I didn’t realize what a –

    Martinez: Alan, that’s why we get the diamonds in our ring.

    Shimel: I guess so. Yeah, and well-deserved. Anyway, congratulations on your recent marriage but we’re going to talk DevOps and we’re going to talk a little bit about modern applications here today, okay?

    Martinez: Awesome. Sounds good.

    Shimel: Great. All right. So I should mention that we have a webinar coming up on June 28 at 1 p.m. Eastern time on this topic and really this chat is just sort of a lead-in to the full hour-long webinar and that webinar is on DevOps for application modernization and we’ll put the link to it in our show notes here but if you find what we’re talking about today interesting by all means check out the webinar.

    But let’s dive in. So Andrea, let’s talk a little bit about modern applications versus non-modern applications: Do we have archaic applications, are they obsolete applications? What do we mean when we say a modern application?

    Martinez: Yeah, I think to – and by the way, I like your archaic reference there. I think to really appreciate the modern application we really have to understand how applications use to be designed and built not all that long ago.

    So, if I were to go back to the N-1 generation of applications I could make some pretty broad characterizations of how they were designed, built and delivered. So, if we were to like take it back to around the late-Clinton era of post-dot.com boom, world wide web and the internet, you know, that was really becoming the network platform where enterprises were exposing business function and really more of nascent digital economy.

    So some of the characteristics of what I’ll call “heritage applications” were, No. 1, they were monolithic so the applications lived on these things called “application servers,” typically running on maybe like higher end commodity infrastructure – think like X86, power hardware with large amounts of disk and memory, we had big centralized databases and these memory hog application servers.

    So the applications ran inside these app servers and they were fairly monolithic – that means they basically bundled the presentation or the view, the business logic and the data model components all together.

    The second characterization I would say for heritage applications is that they lived on these app servers that resided on these sort of heavyweight operating systems and although at the time Linux was very much on the scene overall. The trust in Linux was not yet solidified so you had these operating systems that were sort of these enterprise, server, big and bold editions of this OS – and it was pretty prevalent, you know? Windows and proprietary Unix based operating systems pretty much ruled the day.

    And, No. 3, the – in terms of the infrastructure on-premises data centers ruled the roost. I mean virtualization technology’s around, we had this notion of logical partitions, L-pars, VMware, virtualization, but it was mostly a hardware OS story, okay?

    And then we had, in terms of looking at the actual heritage applications themselves, we had the rise and dominance of function-rich languages like Java and dot-net because the application server middleware pretty much dictated the language of what an application was coded in, right? So we still have a lot of these skills around today.

    And I think the last characterization of a heritage app was in the way that they were delivered. So we had the waterfall delivery – very sequential, big-bang releases with siloed organizations, dev teams didn’t really talk to the operations teams and having that kind of silo was pretty much the norm.

    So, that’s how I would sort of characterize the heritage applications.

    Shimel: Yeah, dead on for me Andrea. We didn’t talk about this but in my background I had started a web hosting company in those dot-com days and I sold it to a company and started to work with them and we were one of the first big, what they called ASPs, if you remember those days – application service provider – and so this is – we wound up doing the whole IPO and all of that – this is 1997, ’98, ’99, 2000, into 2001 –

    Martinez: Absolutely. Yep.

    Shimel: Oh, they were glory days. We were probably one of the largest Lotus notes, if you – you know,

    Martinez: Yeah, all right.

    Shimel: So, picture this: We’re hosting – we are offering hosted Lotus notes as a service – it’s not even IBM WebSphere yet, I think it was still notes server –

    Martinez: Domino?

    Shimel: No, it wasn’t even Domino. What came before Domino? I mean this is old. And then Domino came out and it kind of rocked our world because it was really a big thing for us. But there’s no – it was on dedicated hardware, there was no cloud, T1 lines were about $1,200 a month, and so you had to deliver it over a T1 line oftentimes – you know, a dedicated T1 line point to point – and then we expanded to PeopleSoft and Oracle apps and stuff like that, and what a disaster. I’ve got to be honest. I mean we went through about $500 million – a half-a-billion dollars in monies raised between the IPO and so forth – but it was hard. It was really, really hard.

    And then we tried to get into the whole custom app kind of hosting with ISVs and so forth.

    Martinez: Oh boy.

    Shimel: So, what you just described I had a déjà vu to my bones and, yeah, I wouldn’t call those modern applications but I think we’ve done a good job.

    Now contrast that, though, with what modern applications are like today, Andrea.

    Martinez: Yeah. So there’s sort of been an inflection point where some pretty emergent things have happened since those days, right? And you know we dealt with all of those issues around the heritage environments and applications. And now all of the sudden if we take a look at what I call “modern applications” today – Alan, you mentioned the cloud – No. 1, modern applications live in the cloud. So these applications leverage the elastic, infrastructure and platform that comes with it.

    When we develop modern applications – you also may have heard them referred to as “cloud-native applications” or “born-on-the-cloud applications” – and really what has happened here is to leverage that type of virtualized infrastructure we’ve started to breakdown the monolith and the applications that run on them.

    So, now we’re taking our bundled model-view controller applications and frameworks and we’re deploying them separately as components and hopefully we’re using architectural styles like microservices so that the monolith becomes broken down into choreographed microservices that can be managed separately, okay?

    So, we have technologies that actually support this today. And so Docker, Kubernetes are some of the technologies that have come on the scene since that have allowed us to have a control plane and an environment to manage smaller-granularity applications which are hopefully services.

    So, the other thing about modern applications that I think is interesting and has fostered the adoption of these microservices and smaller components is the fact that the solution stack has become more and more commoditized, right? And so, when you think about the solution stack of network hardware, operating system, middleware layer and so on, we’re seeing a commoditization of the solutions stack from the bottom up, okay? And that is – the whole notion of cloud computing, right? – We’re no longer concerned so much about CPUs and CPU architecture, you know, X86 versus Power P Series, this or that – it sort of doesn’t matter as much anymore, right?

    And because of that, I think that has also fostered in some cases where critical proprietary software was not necessarily needed for enterprise applications. And so, when you start to break down the monolith and deploy smaller services, you’re isolating your risk because you’re isolating business functions and smaller chunks that are lighter-weight and it’s really analogous to the difference between deploying a 10-ton gorilla and deploying a colony of ants. If one ant dies it’s not a big deal, right?

    But commoditization has even spread to the way that these little ants or microservices talk to each other with the advent of API interfaces and as long as you use rest APIs over HTTP or a lightweight messaging protocol that’s pretty much the lingua franca of modern applications today.

    So, I think there’s probably this notion of componentization and that is actually fed into the notion of polyglot programming, and so enabling modern apps to be programmed in just about any language. So, you’re no longer bounded to this big, proprietary application server; you can program in just about any language, and as long as you can talk – rest over HTTP or send an A-synch message over a lightweight message hub – it sort of doesn’t matter.

    You know, you can be a Java or a dot-net bigot but, hey, the new guy who knows Python and is really good at it, he can get in on the action, too. It’s all good.

    Shimel: Absolutely. So, Andrea a lot of what you – you know, it was more than a mouthful there – and a lot of what you’re talking about really describes DevOps, right? This idea of chunking down stuff so it’s not the monolith, right, and doing small – you know, lots of smaller, little things rather than one large, bigger thing and learning and feedback looping and all of that – I mean this is – it’s DevOps 101, right?

    And to me – and this is – you know, I speak to a lot of people obviously around the world about this stuff – but to me there’s a chicken-and-egg relationship between DevOps and modern application infrastructure, development and deployment as you’ve described. I don’t know if you could have one without the other. I just don’t know which one comes first. But they’re intrinsically linked, right?

    And this is why, in my mind anyway, we need – you know, there’s a special relationship, if you will, between DevOps and modern application and how we do modern applications today.

    Martinez: Spot on, Alan. I mean, when you think about the gorilla versus colony of ants analogy. Think about having to deploy the 10-ton gorilla – it’s typically pretty complicated but there’s a lot of dependencies and release management is of utmost concern – but deploying the colony of ants you’re deploying a lot of little things at different times – so you’re achieving the multispeed IT – if you don’t have DevOps, if you don’t have that kind of automation to do the build, compile, package, test, deploy and you’re doing it intra daily – if you don’t have that automated then your cost case is going to fly out the window.

    DevOps is essential for modern applications. Period.

    Shimel: Dead on. Dead on. Amen. You know, you’re preaching to the choir here, Andrea – we’re devopsy.kinsta.cloud – but it really is essential and there is this sort of hand-in-glove type of relationship.

    We are, as I promised you when we started – the time goes so quickly and there’s more I want to cover. So we talk about how DevOps fits into the story on the how and why of modern applications.

    You know IBM has this history now – and as I mentioned to you four or four-and-a-half years ago when I launched devopsy.kinsta.cloud IBM was one of the leading advocates for what was kind of the rise of the DevOps community and culture. And then you guys had the garage method, which was really kind of intrinsically again all about DevOps and DevOps ways, if you will – how does all of that fit in to modernizing applications and the way we’re doing it now?

    Martinez: So the IBM cloud garage method is IBM’s opinionated view on how to deliver especially modern applications: It combines Agile, DevOps, Lean and our enterprise-design thinking and sort of rolls it all up into this wonderful burrito of reference architectures, practices and techniques – you know, it’s lunchtime, so I’ve got food on the mind – but it’s basically a way to help our clients act like a startup so that they can achieve the kind of agility that they need.

    So, DevOps is also about organizational and behavioral changes because that’s really paramount. At the heart of our method is culture – how to organize our teams, the collaborative practices, social coding, pair programming – breaking down the silos, right – that’s what DevOps is all about, having product owners sit with the squads, right? – sit with them. You know, DevOps is a behavior story – a tool automation story – and it’s all in the name of enabling business agility.

    Shimel: Absolutely. Andrea, I’ve got another final area I want to click on if you don’t mind. And that is for our folks listening out here – and it’s a worldwide audience at devopsy.kinsta.cloud – and I’ve traveled the world doing this, and though we all want to do DevOps we move at different speeds and we’re at different stages of our journey.

    What advice, if we can kind of give blanket advice – what advice around DevOps would you give to our listeners who – and again, Andrea, this is something you’ve probably learned, right? – I wish we all had a greenfield to play in, but we don’t, right? We have brownfields and there’s heritage apps, as you call them, and there’s modern apps, there’s old and new, fat and skinny, ants and gorillas – even burritos – what advice can you give our listeners on how to deal with all of these things?

    Martinez: I think just recognizing that you may have to approach DevOps a little bit differently depending upon whether you’re modern or heritage or even somewhere in-between. Typically DevOps for heritage applications, you’re retrofitting automation in situ, right? So, you’re sort of bringing the automation to the app. Whereas for modern applications, you definitely want to have a DevOps Day One approach, right?

    Because the ability to create a cloud-native application and have the automation in your mind right on day one is critical. But just know that you may have instances where you may not be able to bring a heritage application all the way to modern – you might be somewhere in between Fred Flintstone and George Jetson, right?

    Shimel: Two of my favorites.

    Martinez: But that’s okay, right? I mean that’s real-world. Because it may not be cost-effective to automate everything but that’s all right, you know?

    So I think we can engineer our way through some of this – and there are products out there – you know, you mentioned before that hybrid cloud was really sort of the area that I was focused in terms of DevOps – and we have proprietary products, open source products, we have our Urban Code Deploy, our IBM Cloud Private – that really sort of helps bridge the gap between applications living in this cloud or that cloud – whether they’re modern or heritage there is an answer.

    It’s not cookie-cutter, but we have the piece parts and the emerging technologies on the scene to help navigate.

    Shimel: Yep. Excellent. So Andrea that is important for people to know but where do we go – where can people go to find out more about this?

    Martinez: So I think the first place I would point them to is the IBM Cloud Garage method website – and I’m sure we’ll be providing links as part of the podcast references – but at that site you can definitely find reference architectures for DevOps, reference architectures for microservices in cloud-native development – and one of my favorites – the practices and techniques that we employ with our garage method for automation, tooling and social collaboration throughout the software delivery life cycle.

    Shimel: Perfect. So, Andrea, as I mentioned, the time here it goes so quick. It was delightful, refreshing and fantastic having you as a guest here. I’d love to have you – you know, where else are we going to learn about gorillas, ants and everything else? I need to have you back on the show. We’ll talk off-mic about it, but if it’s not too much – and we’re Florida neighbors – so I’d love to have you back here. But we’re going to wrap it up for this episode of DevOps Chat.

    Andrea Martinez-Crawford, welcome and thank you for being our guest on DevOps Chat today. We will have links to a lot of what you’re speaking about in our show notes, so folks, please take a look at that. But for now, we’re going to call it a wrap on this episode of DevOps Chat.

    You’ve just listened to another DevOps Chat and hope to see you soon everyone. Have a great day. Bye-bye.

    — Alan Shimel

  • DevOps Chat: Microservices & Containers – Mastering the Replatforming of the IT Infrastructure

    DevOps Chat: Microservices & Containers – Mastering the Replatforming of the IT Infrastructure

    The replatforming of the enterprise IT infrastructure utilizing microservices and containers is no small undertaking and is usually provoked by a shifting set of key business drivers. That is precisely the case today. The term “digital transformation” is in the hearts and minds and on the lips of top-level business executives and IT leaders alike. The underlying traditional or legacy infrastructures that have dominated enterprise IT for nearly 30 years simply cannot handle the workloads or power the applications that will drive business decisively forward.

    Microservices & Containers

    Both microservices and containers are destined to play a major role in this enterprise replatforming, for different reasons. Containers, for their part, hold significant benefits both for developers and the development effort as well as for the organization itself. Understanding this range of benefits is instrumental to securing IT budget for containers going forward.

    In this DevOps Chat, Jim Scott, director, enterprise strategy and architecture at MapR, discusses the most promising and compelling tools, technologies and solutions destined to play a major role in this replatforming of the enterprise. Jim highlights how to stay one clear step ahead as IT undertakes what is arguably its most mission-critical task in a generation.

    You can also download a great ebook on this topic by Jim at here.

    As usual, the streaming audio of our chat is immediately below, with the transcript of our conversation below that.

    Audio

    Transcript

    [su_pullquote align=”right”][su_custom_gallery source=”media: 118809″ target=”blank” width=”300″ height=”300″]Jim Scott
    Jim Scott is Enterprise Strategy & Architecture at MapR Technologies and is very active in the Hadoop community. Jim helped build the Hadoop community in Chicago as cofounder of the Chicago Hadoop Users Group. He has implemented Hadoop at three different companies, supporting a variety of enterprise use cases from managing Points of Interest for mapping applications, to Online Transactional Processing in advertising, as well as full data center monitoring and general data processing. Jim also was the SVP of Information Technology and Operations at SPINS, the leading provider of retail consumer insights, analytics reporting and consulting services for the Natural and Organic Products industry. Additionally, Jim served as Lead Engineer/Architect for Conversant (formerly Dotomi), one of the world’s largest and most diversified digital marketing companies, and also held software architect positions at several companies including Aircell, NAVTEQ, and Dow Chemical. Jim speaks at many industry events around the world on big data technologies and enterprise architecture. When he’s not solving business problems with technology, Jim enjoys cooking, watching-and-quoting movies and spending time with his wife and kids. Jim is on Twitter as @kingmesal.[/su_pullquote]

    Alan Shimel: Hey everyone, this is Alan Shimel devopsy.kinsta.cloud, and we’re here for another DevOps chat. We’ve got a nice chat lined up today. Lucky enough to be joined by Jim Scott of MapR. Jim, welcome to DevOps Chat.

    Jim Scott: Thanks, Alan.

    Shimel: Thanks for having – thanks for being with us today, Jim. So Jim – well, let’s start with this. Our audience may or may not be familiar with MapR, but let’s assume for the moment they’re not. Can you give us a little bit of background about MapR?

    Scott: Sure. So MapR is a converged data platform. The operable words being “data platform.” So MapR provides a data platform for all data. All types of data, all locations, cloud on premise, and it can run in all of those locations simultaneously. The premise of the platform is to deliver a standard open API architecture on top of our data platform, so that customers can reap the benefits of our platform, but not have to worry about being locked in to the vendor, MapR, for the software that we provide through those open APIs, or even the infrastructure that you choose to run on.

    So if you wanna run on your hardware in your own data center, or if you wanna run your software in the cloud or multiple clouds, you can run your software on top of MapR on any of that infrastructure, anywhere you choose, any time.

    Shimel: Great. So Jim – and just for our audience information, what’s your role with MapR?

    Scott: Oh, so for MapR I’m in charge of enterprise architecture, both internally and externally.

    Shimel: Excellent.

    Scott: So what that means is internally, I’m basically lining up and showing how we’re using MapR to solve our own problems, and then externally, it basically means I work with our customers a pretty substantial amount, helping them work through how to be successful with a big data platform. So what is the right way to do something. I’ve personally worked in a large number of different industries, and so my experience comes to the table quite often.

    Shimel: Got it, got it, got it. We got a little vibration there, but I think it went away. And Jim, as we were talking off-mic before we started today, I was telling you I had covered MapR back in Network World when you guys launched, and I’m gonna guess that was around 2008 or so. Correct? 2009, maybe?

    Scott: Yeah, the company went in – or was founded in stealth mode in 2009.

    Shimel: Yep, I remember it. So certainly there’s been a lot of water under the bridge in terms of in 2009, cloud itself was quite the rage. It was relatively new, still, and people were still figuring that out. The whole big data market – there wasn’t a market for big data, frankly. Hadoop and these things had just come out.

    But Jim, probably one of the biggest innovations or changes in infrastructure over the last two or three years, maybe four, has been the big move to containerization of microservices. I would imagine you’re seeing this at MapR as well.

    Scott: Yeah, absolutely. So if we look historically, just say maybe eight, ten years back, message-driven architecture started becoming popular; service-oriented architecture, things of that nature. And that popularity was great – eh, maybe even 15 years back. But the problem was scaling out the messaging platform itself was difficult, it was expensive, and it was really just a pain from an administration perspective, to be able to scale out.

    So we’ve seen this transition over the last handful of years, moving more towards a microservices model. And the term – a lot of people like to throw it around loosely and call something a microservice when it’s not, but the less monolithic in nature, the more difficult to handle the large scale.

    Which is why the Kafka API and what MapR provides with MapR Streams helps enable the customers, because they have the ability to push through massive volumes at a linearly scaling cost model, so they know exactly where they’re going. So it’s pretty easy to push through something like 1.5 trillion events per day on a platform like MapR with as little as five servers.

    And the more micro in nature, the higher the volume you’re going to need to be able to handle. And so those messaging systems of the past – just not there. Just couldn’t handle it. I mean, I remember being excited when we were getting 50,000 to 60,000 messages per second through the system.

    Shimel: For good reason, Jim. You’re talking to someone who was excited when the 386 came out. So yeah, I hear you. But Jim, fundamentally what my – and I just had this discussion, because we actually have a little microservices journal, Microservices Neighborhood, within devopsy.kinsta.cloud. And I was talking to JP Morgenthal, who’s a CTO at DXE, actually, about this just yesterday.

    Fundamentally, fundamentally – and we’re talking about real microservices now, not nonsense, right? But fundamentally, it has such promise to change the way we do development and to change the way our infrastructure runs, right? Especially when you marry it to containers.

    Scott: Yep. Yeah, and I think what you’re alluding to, and this is one of the things that I have the biggest problem with when talking with people about microservices, is the fundamentals are that a microservice is really more about the deployment model than anything else.

    And without a container to be able to put it in and deploy it, it becomes a very difficult and unwieldy thing, even though it’s so small.

    Shimel: Got it. So Jim, you mentioned before you were working on both the internal and external aspects of this. Internally, if you can – let’s not give away any company secrets – but internally, is MapR utilizing your container-based infrastructure with microservices?

    Scott: Uh-huh, absolutely. Yeah, matter of fact, we talk about it pretty regularly. So for our own website, we have implemented customer 360 capabilities. We run our software inside of containers, and we run it currently on one cloud, but we have on-premise hardware, and we will be in the not-too-distant future running multicloud and on-premise all simultaneously. And in order to do that you need a technology like a container to get that type of isolation from your infrastructure.

    Shimel: Yep. An abstract, if you will; an abstraction – I had an interesting conversation, Jim, with I think it was at _____ recently, or another site, another large organization who had totally moved to a containerized infrastructure, and he was talking about what a profound change it was.

    And I asked him about patching containers versus immutable infrastructure, just standing up new ones, replacing the old, rather than actually patching the existing ones. Where are you on that question, if you don’t –

    Scott: Well, I love the concept of being able to go back to my base, default image and be able to run it through my entire devops process, continuous integration process. So I can go patch one instance in my dockerfile, I can test the core out, make sure it’s doing what it’s supposed to, and then I can let all of my downstream builds run, pick up the new container, and run them through their integration tests.

    Shimel: Excellent. So Jim, I don’t know if everyone in our audience understands this whole idea of eating your own dog food, and what it means. But can you maybe give us an example or two of how things you’ve learned by using them internally at MapR have translated into better service, better product, better results for end users?

    So how you’ve taken it out, how you’ve taken certain processes or waves of technology that you use yourself, and translated that into a customer experience.

    Scott: Yeah, so there’s a couple that pop to mind, and number one is actually containers. We only introduced support for containers around the beginning of this year.

    Shimel: Really?

    Scott: But we’ve been using – yeah, it was – I think our press release that we did on it when we officially released support was around February time frame this year. But technically speaking, we have a number of customers who’ve been using containers with MapR for two, three years.

    And little secret here: We use it internally, and have been for two, three years as well. So making sure that we had it fully vetted and very well baked from a support infrastructure perspective was really critical, but getting that out there for customers, really important.

    Because it solves such a major problem with containers, which is you look at something so simple as security, right. If I am responsible for the web server for my company and you are responsible for the financial systems of your company, or of my – or our company, that software in a container has the ability to run on the same server.

    But if they run on the same server and we are utilizing local storage on that server – because you can’t save data inside a container; it blows up. It’s gone when the container dies. So if you save data locally on that server, what happens? Well, suddenly I run these security risks of my web server having access to financial information – probably not a good idea.

    Shimel: No.

    Scott: So we implemented, within our MapR persistent application client container, the ability to talk to MapR from within the docker container. And because MapR offers NFS support, it’s almost invisible and there’s hardly anything to do. And you give it a ticket from your authentication environment, and you’re good to go.

    Whatever’s running inside that container has a user ID, and when it talks to MapR, the data is saved and protected. You don’t have to worry about oh, well, if I’m gonna save data, I’ll save it to the local server. You get rid of that whole problem. It isolates where the data goes, already being protected and highly available, if your server physically dies, just like if your container dies, you don’t care. You don’t have to restore the server to try and get the data off of it.

    Shimel: Got it, got it. That’s 100 percent – that’s the beauty of that whole abstraction layer, if you will.

    Scott: Exactly.

    Shimel: Jim, here’s an interesting question, and I don’t know if you have this info, but I figured I’d ask anyway. We’ve been doing a bunch of surveys about container adoption, and it’s funny, we’ve done several of these surveys now over, let’s say, the last two years, and when we first started, a lot of people had plans of looking at docker and containers.

    Other people, a decent amount of people, had containers in their – they were in the testing dev environment kind of thing, not production. Few had them in production. Then recently, like our most recent surveys, let’s say, over the summer, that number shot up. Probably 40, 50 percent of respondents have containers in production.

    That may be because it’s devopsy.kinsta.cloud, we’re in a devops bubble, and so you get people using this kind of new stuff. But I’m curious, out of the MapR customer base, a gut check if you don’t have the real number, what do you think the percentages are that are using containers in production these days?

    Scott: It’s a pretty big number. I don’t have a hard-and-fast number, but if I just go by the customers that I talk with, I feel like it’s gotta be over 50 percent.

    Shimel: Really? Wow.

    Scott: Yeah. Yeah, we’ve got one extremely advanced customer in Australia, their name is Quantium. And they talk about how they use MapR all the time, and they’ve basically reinvented their entire operating model, and they’ve done it on top of MapR. There’s an enterprise architecture I documented that they talk about periodically; it’s called the zeta architecture.

    They basically use an orchestration layer, they use MapR for persistence, and then they use containers to launch and deploy anything anywhere arbitrarily across their cluster of hardware for their customers. And they turned their entire internal platform to an as-a-service model for internal and external customer consumption.

    Shimel: Got it, excellent, excellent. We’re hearing stories like this all over now, and the interesting thing is it’s almost wherever you see containers, you’re seeing microservices. But you’re also seeing microservices in places where you don’t necessarily also see containers.

    And it reminds me of when I was in school, we used to learn all pasta is macaroni, but not all macaroni is pasta, or something to that effect. But microservices has a place outside of containers, though they seem to just go really well together.

    Scott: Yeah, absolutely, and I think when you start looking at the different types of use cases that you would fit into a microservice, this is where you start seeing how people are going to choose to deploy and manage. If you’re looking at event-driven, message-driven, where it’s taking a message in, it’s doing some work and it’s dropping a message back out, versus it’s a restful service endpoint, where it’s a synchronous response.

    Yeah, people are choosing to do things in different ways, but nearly – everyone that I talked to, they’re using containers in some fashion.

    Shimel: Yep, yep. It’s true in my case too, but like I said, I always figure well, I’m in a bubble, so of course I’m gonna see that. Jim, what’s next for MapR?

    Scott: Oh, that’s an in intriguing question. Recently, we announced our 6.0 launch, and we have greatly enhanced a number of features around our database capabilities. I seem to have this conversation a lot with people, is they start looking at big data technologies, and they say well, this is great and all, but I’ve built this software to work with mySQL or Postgresql or Oracle or whatever RDBMS.

    So that’s fine, you can containerize those applications if you wanna start changing your infrastructure and how you orchestrate your software, and if it’s important enough to you, you could migrate it over onto a no SQL database like MapRDB document database, or you can just leave it running in a container so you have a more flexible infrastructure.

    And the database technology enhancements that we’ve been making are really critical to kind of driving the future of getting people off of those super-expensive to scale RDBMSes that are being used for non-relational purposes.

    Shimel: Excellent. Just time frames – when might we see some more on this stuff?

    Scott: Well, it’s been announced in the last few weeks, and so we’ll start our 6.0 general availability very soon. I forget the exact date. Then we’ll just continue plugging along, adding more new, fantastic features to help enable the customer base.

    Cloud integration with our platform is another really big one, making sure that we can help enable customers to benefit from the concept of cloud neutrality. Cloud providers are never just gonna get together as a consortium and say hey, why don’t we standardize our APIs to the benefit of our customers?

    It just doesn’t happen. It’s not gonna happen. Google, Microsoft, and Amazon are never just gonna call each other up and say hey, what do you think about this?

    Shimel: I agree. Agreed. Well, not – you know what – well, I was just, I’ve seen a lot of changes over the years, but that’s probably a pretty safe bet, Jim.

    Scott: Yeah.

    Shimel: Unfortunately. Anyway, Jim, believe it or not, as I told you when we started, the time goes really quick, and we’re about out of time for this version of DevOps Chat. But we’d like to maybe have you back on in the future. We’d love to keep up with what’s happening with MapR, especially as it relates to microservices and containers and some of the new stuff we have going on.

    Jim Scott: Yeah, sounds great.

    Shimel: Great. But in the meantime, if people wanna get more information about MapR, where can they go?

    Scott: Well, I would recommend they go to MapR.com.

    Shimel: Okay.

    Scott: Or of course, you can always follow MapR on Twitter and/or any of the other social networks that you join and work with. But the website is always my favorite, because there’s a lot of great material there, including the MapR blog, and all of the ebooks, including the “Microservices and Containers” ebook that I wrote is out there, for free.

    Shimel: Got it. Got it, got it, got it. All righty, well, we’ll have to maybe get some links to those we’ll put in the show notes of this as well.

    Scott: Yeah, that’d be great.

    Shimel: Fantastic. Hey, Jim, thanks for being our guest on this episode of DevOps Chat. Look forward to having you back soon and finding out more about MapR. Continued success, and keep us posted about what you guys are doing.

    Scott: Thanks, Alan. Appreciate it.

    Shimel: All right. Hey, everyone, this is Alan Shimel for DevOps Chat on devopsy.kinsta.cloud. Thanks for joining us, and we’ll see you soon on another chat. Take care, everyone. Bye-bye.

    — Alan Shimel

  • DevOps Chat: Chef Update with Ken Cheney, Chef CMO

    DevOps Chat: Chef Update with Ken Cheney, Chef CMO

    There are always new developments going on at Chef. We caught up with Chef CMO Ken Cheney to give us an update. Last time we spoke with Ken was right after ChefConf. Since then, Chef continues to move forward on several fronts including Habitat, Automate and INSPEC. We speak to Ken every other month or so, as it is always good to know “what’s cookin’” at Chef.

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

    Audio

    Transcript

    Alan Shimel: Hey everyone, Alan Shimel, editor in chief of devopsy.kinsta.cloud here, for another DevOps Chat. Today’s guest on DevOps Chat is our friend Ken Cheney, CMO of Chef. Ken, welcome back to DevOps Chat.

    Ken Cheney: Alan, it’s great to be here. Thanks for having me.

    Shimel: Thank you. Ken, I apologize, between your schedule and my schedule, it’s been a while since we’ve had a chance to catch up. I think the last time we left off it was – was it right after Chef Conference, ChefConf?

    Cheney: It was actually right before ChefConf. So it’s been a couple months, right? Given that was at the end of May. 

    Shimel: Ken, I don’t think I’ve been home for more than two or three days at a time since then. So yeah, it has been. But for our listeners who maybe aren’t lucky enough to be down in Austin and ChefConf this year, can you fill us in a little bit about maybe what we missed?

    Cheney: Yeah, so ChefConf this year, as you mentioned, was in Austin, Texas. And you know, I think the highlights of ChefConf, on the product side, were some announcements we made around Chef Automate and bringing in our open-source tooling fully under that umbrella of Chef Automate. So Chef Automate is our commercial offering. And first and foremost, we brought in InSpec fully, so now, from one spot within Chef Automate you can see both how you’re doing in terms of your infrastructure and how your infrastructure automation is going with Chef, but also from a compliance perspective you can see what’s happening in terms of policy through the Chef Automate UI. So it’s really – the product has evolved from how it was working before, where we essentially had two servers for and now you have a single, common UI for looking across all the various data points

    In addition we brought in the Habitat data so now you can see the state of your Habitat instances that are running in the wild.  And you know, what I find really interesting about what’s happening with the compliance front is that, you know, we’re really evolving quickly from just being focused on sort of core compute elements to now expanding InSpec out to cover up on cloud-based APIs. So we can now go at AWS and Azure and be able to scan those, as well as VMware environments. So you know, we’re expanding InSpec to be a language that’s not just appropriate for compute, but also for broadly managing all of your infrastructure as code. And so that was announced as well at Chef Conf. And I think that’s a bi move forward. You’re going to see that continued expansion of that InSpec language and capabilities to go after a broad set of other types of infrastructure in the near future.

    And it’s an area where we see just a tremendous interest and uptake from our customers and users. So anyone who hasn’t tried out InSpec, I really encourage them to try it as part of Chef Automate if you want to actually see that InSpec data roll up into common policy views and really understand how you’re doing at an infrastructure level, both in terms of the state of your infrastructure but also how your infrastructure is conforming to policy around compliance and security. You get that from one place. And in this world of WannaCry and other exploits that are happening, it’s amazed me how many organizations, when tools like InSpec exist, still have giant vulnerabilities, right? And here we have this open-source tool that can solve this problem of really understanding what is your exposure. And then you can use a tool like Chef to actually remediate and fix it. It just blows my mind that it’s still a common occurrence.

    Shimel: It blows your mind, Ken? For 20 years it’s blown my mind. For those of us in the security space, it’s no secret that well over three-quarters—actually, probably over 80 percent or 85 percent of attacks and successful attacks actually take place not because of what we used to call Zero Day or unknown vulnerabilities, but because known vulnerabilities were not patched.

    Cheney: That’s exactly right. That’s exactly right, yes.

    Shimel: And that’s the key. I mean even today –

    Cheney: Yeah, and –

    Shimel: It’s crazy. I’m sorry, go ahead, Ken.

    Cheney: Oh I was just going to say, one of the common things, you know, as many organizations haven’t really fully automated – and so they reintroduce the vulnerabilities into the wild all of the time. And what I love about what you can do with InSpec is you can actually – because you’re managing as code, every time you test your software, every time you push a configuration with Chef, you can verify that you’re not reintroducing to file that or something on a keyboard the reintroduces that potential hole in your organization.

    Shimel: Yep, you know – I’m sorry, can you hear?

    Cheney: Yeah, yeah, go ahead.

    Shimel: I’m getting a little audio back. I hope this is recording well. Ken, we did a survey a while back where only 75 percent of organizations are actually scanning their code for vulnerabilities prior to deployment. And you know, what are the other 25 percent thinking?, is kind of what I think. But anyway, on the topic of security, Ken, I wanted to quick mention that Matt Ray of Chef is actually speaking at a conference I’m doing as a part of RSAAPG on DevSecOps next week. And Matt, I think, is based in Australia, correct?

    Cheney: Yes, he is. Yeah, Matt is based in Australia and he will be talking about InSpec, and folks who are there can attend his session and learn more, for sure. 

    Shimel: So maybe it’s because I’m traveling to Singapore and so it’s kind of right in my face, but to me, it’s this global – I mean, DevOps has really become a global – I don’t want to use the word “phenomenon” – but a global force. And we’re seeing it

    Cheney: Yes, it is.

    Shimel: – you know, certainly in EMEA, but we’re seeing it in AP. And then just this week, Ken, I think Chef just announced their first Latin American partner, right?

    Cheney: Correct, correct. Yeah, we are definitely seeing DevOps at a global level and seeing broad interest. And what’s interesting is that – Alan, I’ve been in the industry a while, and it used to be a little bit of a lag – you know, a several-year lag before you’d see markets such as Latin America or parts of Asia pick up technology that would originate in the United States. Or process ideas. But things move much more quickly now and you’re seeing global companies with operations in India and operations in China. And so we as a company do a lot of activity at a global level. You know, if you look at how we’re doing meet-ups and where we’re doing meet-ups, they’re happening all over the place. And our partner ecosystem, which is well over 300 partners, covers the globe, because we see that demand.

    Now how we enter any given market varies depending on what’s going to work best in that market. So some markets we address through partners and some markets we actually put our own physical presence in that market.

    Shimel: Yeah, we see the same thing at devopsy.kinsta.cloud, Ken. You know, our readership when we first started was almost three-quarters U.S.-based, and now it’s only about 37 percent, with the rest being global. But it’s more than just spreading through the world. It’s what you said – there’s not as great a lag time. At one point, Latin America was three – we used to tell people, “Oh, it’s three years behind what we’re doing here.” And that’s not the case anymore, certainly.

    Cheney: Yeah, I’ll tell you, the highest volume of leads that we get come from the Asia Pacific region.

    Shimel: Really.

    Cheney: Yeah, so there’s just a tremendous amount of demand coming out of there. I’ll tell you, if we do a meet-up in Bangalore or Delhi, we’ll have 300 people show up to that meet-up.

    Shimel: Wow, that’s fantastic. You know, we’ll talk more about that off-mic. But Ken, a lot of what’s driving strong numbers like 300 people at a meet-up and stuff like that is training and availability of training, right?

    Cheney: That’s right.

    Shimel: And that’s something Chef has always done really well. But you guys recently rolled out – not Pilot, excuse me – what is the name of the –

    Cheney: Chef Automate. The Chef Automate Pilot, yeah. We actually rolled out a whole new online learning site called Learn Chef Rally and it’s gotten very fast adoption and has a lot of users hitting it every day. And as part of that we have what’s called the Chef Automate Pilot, which is really targeted at an individual who wants to really understand Chef over the course of maybe a lunch, right? So that kind of lunchtime evaluation where they want to get a feel for how Chef works and what it does for them. But as a whole, Learn Chef Rally constitutes a whole set of modules that will walk you through the various parts of our technology. So if you want to learn about compliance, there’s an InSpec module and a Chef Compliance module. If you want to learn even about DevOps concepts, you can go and learn about them there on the Learn Chef Rally site.

    And we’ve had such strong uptake. You know, we’ve seen a lot of customers who would like to bring that learning site in-house and customize that learning environment for their own company. There’s been such a strong interest. So it’s a great resource and I encourage people to go look at it.

    Shimel: Sure. Ken, well, the logical question then is, how do they get there?

    Cheney: Yeah, so it’s very easy to get there. You can just go to learn.chef.io and you can get started.

    Shimel: Excellent. That’s a good one. So that’s Chef Rally and it’s highly recommended. It sounds like there’s a lot and I’m sure you guys are planning to add more into that. So Ken, we are kind of in the dog days of summer here but it’s certainly not slow, it doesn’t seem, anywhere. Any other news, events?

    Cheney: Yeah, well we just passed the one-year anniversary of Habitat and I’ll note that, you know, we at ChefConf made some Habitat news. So we announced a Habitat build service and we made improvements to the Habitat scaffolding, which are essentially build packs to make it easier for people to package up their applications, as well as we’re writing a set of enterprise-ready Habitat plans or common languages, common platforms, such as like BigData, Cassandra, Spark and real common kind of web apps. And so Habitat continues to evolve, and just in the past couple of weeks we announced the pre-release of Habitat for Windows. So along with what we had for Linux support, people can now use Habitat to package up their Windows-based applications. And from our view, Habitat is now the premiere packaging solution for containers. It’s the fastest, easiest way to package an application and have it run in a container and be able to manage it across the life cycle.

    Shimel: That rocks. I mean, because certainly, Ken, the one thing that we’re seeing here is the – you know, we talk about the Internet time crunching or compressing time. The pickup on containers? I’m old enough, and probably you are too – remember when VMware first came out, right?

    Cheney: That’s right.

    Shimel: And through virtualization, it went really quick. The move to virtualization went a lot quicker than let’s say the move off of client server or something like that, from peer-to-peer, or peer-to-peer to client server or what have you. But the move to containers – man, I’ve seen several surveys recently that showed container in production numbers upwards of 50 percent of organizations. And I thought frankly this wasn’t true, but it says something. Right?

    Cheney: Yeah well, you know what’s interesting though about that move? What’s interesting about that move, Alan, is that the majority of containers that are running out there are being used almost like a VM. You know, 75 percent of containers right now are running a full OS.

    Shimel: Yep.

    Cheney: And they’re basically just using it as a way to kind of attempt a higher level of abstraction and remove a little bit more of the infrastructure complexity that they were encountering when they were using VMs. So what I think the next wave is going to happen, I think people are going to actually figure out how to actually better package their applications to actually take advantage of what they can do to remove unwanted dependencies and remove a lot of the weight around the application that they’re currently doing today when they just package up the full OS and all of the broad set of unassociated dependencies that they’re packaging right now. So I expect that’s going to be the next wave and we’re there to help them when they go there.

    Shimel: Agreed, agreed. Ken, any shows or conferences coming up, other than of course the DevSecOps that I mentioned, where Chef will be presenting or a part of?

    Cheney: Yeah, well yeah, we will be at VM World, coming up. We’ll be at Microsoft’s big event that’s coming up. And of course as we look toward November we have our own community summits that happen in the fall timeframe. So those are a great way that we bring our community together. So the first one is going to be in London Oct. 10 and 11. So that’s coming right up as well. So expect to see Chef and our brand showing up at a lot of different places in the coming months.

    Shimel: Great. Very cool. Well Ken, we’re about out of time here. 15 minutes goes quick. But hopefully it won’t be a few months before you’re back on –

    Cheney: Yeah.

    Shimel: – and we can pick up where we left off here.

    Cheney: Yeah, Alan, enjoy your travels and thanks so much for the time today.

    Shimel: Not a problem. Ken Cheney, CMO of Chef, here on DevOps Chats. This is Alan Shimel for DevOps Chat and devopsy.kinsta.cloud. Thanks for listening, everyone, and we’ll see you on another DevOps Chat soon.

    — Alan Shimel

  • DevOps Chat: DevOps, Cognitive, IoT & Blockchain

    DevOps Chat: DevOps, Cognitive, IoT & Blockchain

    CJ Paul and Cliff UIn this DevOps Chat we sit down with Cliff Utstein, director of Offering Management, IBM Cloud DevOps and CJ Paul, distinguished engineer and chief architect, IBM Cloud DevOps. Cliff and CJ give us some insight into how some of the biggest trends in technology today—DevOps, cognitive, IoT  and blockchain—are connected. It is a great discussion with some of the people at IBM who are dealing with these subjects day in and day out.

    As usual, the streaming audio file is immediately below, with the written transcript of our conversation below that. Enjoy!

    Audio

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel of devopsy.kinsta.cloud and we’re here for another DevOps Chat. We have a really interesting DevOps Chat today and it’s regarding how DevOps kinda interacts and can help you get started with some of the leading sort of technology trends out there today and talking about things like cognitive and blockchain and IoT, etc. So a lot to cover in our 15-minute show, but we’re gonna do the best we can. I’m joined today by two friends from IBM. First of all, a returning guest to DevOps Chat, our friend CJ Paul, distinguished engineer and chief architect, IBM cloud. CJ, welcome to DevOps Chat.

    CJ Paul: Thank you, Alan. Glad to be here.

    Shimel: Thank you and welcome – glad to have you here. And, secondly, we have Cliff Utstein, and, Cliff, if I mispronounced your last name, I apologize, but Cliff joins us from Boston and he is the director of DevOps product development for IBM Bluemix and cloud. Cliff, welcome.

    Cliff Utstein: Thanks, Alan.

    Shimel: Did I mess up the title or the name?

    Utstein: I actually lead product management for IBM’s Bluemix – IBM’s cloud DevOps.

    Shimel: I apologize. So much for me for following the show notes. That’s what you get. [Chuckles] But, okay, fantastic. So, guys, you know, three big, kind of meaty topics out there—cognitive, blockchain, and IoT—and then how does DevOps help you get started with all of them. Let’s start with cognitive because, certainly, IBM is a market leader in cognitive and it seems like they’re building cognitive into everything. So let’s talk a little bit about that. CJ, I’ve probably spoken about this with you in the past, so, if you don’t mind, let’s start with you. How can DevOps help you get started with cognitive?

    Paul: Well, we find many customers evaluating several of these cognitive services that Watson provides. They are available as APIs in Bluemix, so this is – such as natural language understanding, natural language classifiers, the Watson conversation service, and many others like that. And many companies are looking at how to take advantage of those combination services to build interesting applications, like chatbots, that they can deploy for various use cases. So, as they look to build these applications, clearly, the way you build these applications is important.

    What DevOps proposes now is an iterative model where you rapidly take ideas and get them into code and deliver them out to market and see how effective they are. And then, you know, measure the usage and iterate rapidly from there, so using the DevOps practices and toolchains that we provide, it can greatly speed up a company’s ability, the developer’s ability, to build and deliver these leading-edge cognitive applications.

    Here are some other DevOps Chats you may want to listen to:

    DevOps Chat: Purpose Built Appliances for Containerized Applications with Diamanti’s Mark Balch
    DevOps Chat: Developers and Security with Pete Chestna, Veracode
    Patrick McClory on Building Successful DevOps Organizations

    Shimel: Sure. Cliff, what do you think about that?

    Utstein: Yeah. As CJ said, a lot of organizations right now are looking to build cognitive applications and what they’re thinking about often, with that, is how to move to the cloud, how to improve their overall processes within their organization, and even how to change their culture. And DevOps cuts into all of these—giving an organization a way to go through, really, a set of changes that let them develop a much tighter customer relationship, ultimately, through faster iterations in the development cycle, getting to the customer with their MBT faster, and doing it in the cloud so that they’re able to utilize all the advantages that the cloud offers them, as far as getting to the customer faster and understanding what the customer wants.

    And what’s behind this, as CJ said, often, is a whole set of cognitive needs to improve their apps, based on utilizing these cognitive services, so we see it in the financial services space; we see it in health care; we see it in retail. We see it in a lot of industries, where businesses are looking to incorporate these cognitive abilities into their apps, to build the customer relationship, ultimately.

    Shimel: Sure. Hey, Cliff, if you don’t mind, I wanna dig in a little bit on the whole cognitive thing. You know, with IBM, a lot of people sort of make Watson and cognitive synonymous, right? I mean, it’s the IBM brand, if you will, for cognitive, if we wanna say that. But we’re hearing so much today about artificial intelligence, machine learning, right, automation, all of these things. And automation is obviously closely tied into DevOps. Just to be clear, Cliff, when you’re talking about cognitive, first of all, it is synonymous with Watson and certainly for IBM’s purposes. Is that correct or incorrect?

    Utstein: You know, I think that Watson provides us with a whole set of tools and applications providing cognitive abilities. I think, in addition to that, however, we can look at the cognitive abilities in DevOps as well, in machine learning, to determine some basic things like whether a release is likely to succeed or fail in production. We’ve got algorithms, cognitive algorithms, around that today, to help organizations figure out whether or not they’re gonna have success with a release, based on prior releases, based on patterns that we’re able to interpret within the code as well. So it means a lot of different things, Alan.

    Shimel: I agree. Agreed. I just wanted to clear that up for our audience in there too and I think, you know, and, in my mind, anyway, when I look at the relationship between DevOps and cognitive and cognitive and DevOps, there’s a little bit of “chicken and egg,” in that I think cognitive can help you with your DevOps transformation and move to the cloud and everything that’s wrapped around digital transformation, while, at the same time, that same digital transformation and DevOps transformation can help you, you know, accelerate use of cognitive technologies to make your business better. So it very much is a win-win, two-way street. CJ, what do you think?

    Paul: Yes. Absolutely, yeah. One is actually the building and deploying of cognitive applications itself and applying the DevOps principles; the other is using cognitive technologies within the DevOps tools themselves. Yeah. They’re both very relevant and things that IBM’s been working on.

    Shimel: Excellent. Guys, if you don’t mind, ’cause time is always an issue here, I’d like to move on to the next topic, which is blockchain. So, you know, I just came off of a world tour roadshow around DevOps and other kind of issues, and, wherever we went, blockchain was incredibly hot, was incredibly popular. People wanted to know about it; people wanted to hear what the story was around blockchain. But, at the same time, I had people who were like, “What is blockchain?” Right? They didn’t understand what we meant by “blockchain” and why was it tied into bitcoin and these kinds of things and why should we care. Cliff, if you don’t mind—and I don’t know how much you know about it and, if not, CJ—can we do a level set for the audience about what we mean when we say “blockchain”?

    Utstein: So, you know, I think that might be a different talk, Alan. I think, from a DevOps perspective, what we’re seeing is the need to deliver the processes, the culture changes, the tools to support developers that—especially in financial organizations, that are today looking to incorporate blockchain into their applications. And that’s really been our focus, is helping them do that quickly, securely, with governance and all the controls that a financial organization needs in order to be successful with blockchain.

    Shimel: Good. Fair enough. I think that’s kind of DevOps  CJ, what do you think?

    Paul: Yeah. So blockchain is the Hyperledger technology that underlies offerings such as bitcoin, but that underlying technology, though, can be used to secure financial transactions, right, or different kinds of transactions around the world. So it’s driving a level of transformation in the financial industries, that lot of companies wanting to build new applications to take advantage of this technology. So that’s where, as they try to build these new applications, the DevOps techniques and tools that we’re providing can greatly help them, you know, build those applications and get those applications out there faster. So, essentially, DevOps is sort of the foundation that helps them innovate more rapidly in these new domains.

    Shimel: Got it. So, Cliff, you’re the product guy; I wanted to talk a little—ou know, what are IBM’s customers doing around DevOps and blockchain? Can you give us a couple of examples? And you don’t have to mention names—you don’t have to name names, obviously—but couple of examples.

    Utstein: Yeah, I think—I mean, what we’re seeing, really, is, as CJ said, in the financial sector, we’re seeing the application development really accelerate around blockchain technologies today, and what these organizations are doing is using it as an opportunity to make the changes in their organization around digital transformation. They’re doing it in the cloud, they’re doing it using open toolchains in the cloud, and, obviously, the ones that I’m most familiar with are doing it using IBM’s Bluemix, IBM’s cloud, and our continuous delivery offering with open toolchains. And that means that they’re using a set of modern tools, like Git and other tools in the cloud, to do this rapidly, and they’re iterating very quickly.

    The thing that we’re hearing from our customers is that they’re making changes in production daily, that they’re getting to their customers with changes in a matter of days after the customer makes these requests. And that’s really the big difference that we’re seeing, is how quickly they can meet their customers’ needs in this space, using templates to quickly get their new developers up, using an open toolchain so that they’re using the common industry-leading tools in each of the categories around collaboration, around tests, around source code management, around issue tracking, so that they can deliver that, using those common tools, using the technologies of blockchain to deliver to the customer quickly.

    Shimel: Got it. And so, Cliff, I imagine that’s a big part of your focus and, CJ, you as well, in architecting, is making sure that Bluemix and the IBM cloud—it’s still called “IBM cloud,” right, Cliff?

    Utstein: It is. It’s—I mean, we call it “the IBM cloud” and it means—you know, there’re a lot of elements of the IBM cloud, but “IBM cloud” is a good moniker.

    Shimel: Okay. Just wanna make sure. So, you know, part of your job, obviously, and CJ as architect, is you’ve gotta make sure these underlying tools are there in place for people, as they onboard, as they start making this migration, this transformation. And many of them are, at the same time, adopting DevOps type of customs and culture and tools to facilitate this as well. So it’s almost like you have to stay one step ahead of anticipating what these guys are gonna need.

    Paul: Yes. And that’s what—now we look ahead. We look at what some of the early adopters of these technologies have observed and we’re trying to remove the roadblocks, right, both in terms of providing sample applications, quick ways to get them started with their own enterprise applications, and then, as they get started building these applications—nobody builds an enterprise application as a lone developer; they always work in a team. So we wanna make sure that we enable these teams to be productive very quickly.

    And that’s where, as Cliff mentioned, we support a open-toolchain fabric, unique in the industry, and then, on this fabric, we template-ize the toolchain that these things need to get going quickly, so we can instantiate those templates within minutes and, basically, onboard a team, with both starter code for their applications, as well as the toolchain they need to get it out into production, so we’re pretty excited about that. You’ll see those kinds of capabilities show up in the way you build these Watson applications and the financial applications and the IoT applications on Bluemix and on IBM cloud.

    In fact, what we tell customers is “DevOps is the way you build any application on the cloud, given that all of the infrastructure can be provisioned through APIs—you know, it’s all infrastructure, this code, on the cloud—so you don’t have to wait for your contracts to close. You can just make API code and get your infrastructure and provision your runtimes and deploy your application. So there is no other way to do it but to use DevOps.” And that’s why we are working hard to enable all of these developers to have an outstanding experience on IBM cloud, working the entire developer journey, from how they get started with the sample apps, how they get started with their enterprise apps, and how they build and deploy with toolchains.

    Shimel: So let me just repeat that one line ’cause that was the money line, CJ: “There’s no other way to do it but to use DevOps.” I love it. Cliff, what do you think about this? Are you in violent agreement with CJ? Anything to add there?

    Utstein: I’m in violent—oh, CJ and I are always in violent agreement, Alan. Yeah, we’re seeing—and I think, as these companies move to the cloud, as they take advantage of Watson and blockchain and IoT, it’s critical that they adopt DevOps practices or else they’re unlikely to succeed. It’s gonna take them much longer to get to market, they’re gonna do it with less customer satisfaction, lower quality, and they know it. I mean, the data’s in. I read it on your website, Alan. Go to devopsy.kinsta.cloud; you’ll see.

    Shimel: Absolutely. Guys, we’re kind of running a little bit low on time. We have a few minutes left. I wanted to talk—we had IoT on our list and I don’t wanna shortchange you because it’s important. You know, IoT, to me, guys, is—I mean, there was so much hype around this, let’s say, a year or even two years ago. We went suddenly from IP4 to IP6 because every refrigerator’s gonna be connected, but it’s not just the refrigerators and toasters, right? It’s all of the little gadgets and how many IoT devices are on our cars, even if we don’t own a Tesla. How many—you know, I signed up for a contest yesterday to get one of those free RFID tags that you can put on your keychain so you won’t lose your keychain anymore, and it’ll show you where it is or your wallet or anything else you wanna find. And, to me, you know, even in my house, we’ve gone smart home and I’ve got all these IoT devices now that I can control from my phone. So the hype is real, but, first of all, how much IoT are you guys seeing with the cloud and in the IBM customer base? Either one of you.

    Paul: Yeah. I would say the IoT scenarios—you mentioned smart home as an example, but connected cars are another big driver because now you can buy cars that have built-in WiFi plans, right, that are paid for, for some number of years, by the manufacturer itself. So you can see maps and understand, for example, what the traffic durations are or there’s burglars in an area, even as you do navigation on your car navigation system.

    So lot of these connected devices both pull and push data to the cloud, and that is where a lot of the data collection and analysis applications are actually being built out, to support these devices on the edge, because lot of the compute that backs them up is out in the cloud, right? And so, again, all of these are brand new applications that nobody had before, so they have to build it and iterate on it rapidly and get it out and get feedback from the users and continue to improve it. And there, again, all of the practices and the toolchains are very relevant to any of the teams building the IoT applications.

    Shimel: Sure. Cliff, what do you see on your end?

    Utstein: Yeah, I mean, as CJ is saying, I mean, automative is a big driver right now of IoT and BMW’s CarData platform was created to run on the IBM Bluemix cloud, in fact.

    Shimel: Oh, right.

    Utstein: That was just announced two weeks ago. And it really gives the new platform access to IBM Watson IoT capabilities, so that’s a big deal in the space and they’re talking about 8.5 million BMW customers globally taking advantage of this service, and it’s really about data. I mean, as we talk about IoT, it really comes down to big data and needing a cloud to manage the big data and needing practices like DevOps, if we tie it back to DevOps here. It’s really about practices and giving developers the ability to take advantage of these practices to build that relationship with the customer so that the customer can make sense of that data ’cause that’s what the cloud can do best.

    Shimel: Yeah. I mean, my sense, guys, is that, with all—you know, CJ, you mentioned a few applications. Cliff, you literally put the rubber on the road with BMW relationship—you’re right. But I still feel like we’ve barely scratched the surface between how IoT—connected devices, if we will, interacting with the cloud, are gonna change the fabric of our lives. Right? And I think we haven’t even touched on the medical aspects of it, when you have nanotech running in your body, reporting back somewhere to the cloud about your vitals and your bodily functions and so forth. I mean, it’s gonna change things.

    But, Cliff, you hit on something that I think is really important about all of this. Underlying all of these things is big data and big data analysis and analytics, and that’s where cognitive becomes the game-changer, in my mind, anyway. I mean, what do you think, Cliff?

    Utstein: Yeah, I think that’s it. I mean, I think IBM’s cloud bringing together the platform for big data and cognitive together, with a set of DevOps processes, I mean, is truly differentiated.

    Shimel: Absolutely. Guys, you know, I promised you 15 minutes; here we are at 22. So we’re gonna need to wrap things up here, but, you know, each one of these areas—cognitive, blockchain, IoT—probably, we could have done a podcast on each of ’em, but I’m glad we were able to hit what we did. Maybe we could come back on in another time and part-two this and dive a little deeper ’cause I did wanna touch on the connection between, let’s say, cognitive and IoT, and I think we’ve just scratched the surface. But, for now, we’ll call it a wrap on this edition of DevOps Chat. Cliff, thanks so much. I know it was your first time on; I hope we didn’t scare you away and you’ll come back and join us again.

    Utstein: Thanks, Alan.

    Shimel: Thank you. CJ –

    Utstein: Would love to.

    Paul: Thank you, Alan.

    Shimel: CJ, always a pleasure having you on, my friend. I look forward to seeing you soon.

    Paul: Thank you, Alan. It was a pleasure.

    Shimel: All right. CJ Paul, Cliff Utstein, IBM’s cloud and Bluemix team. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Thanks for joining us and we’ll see you soon—or listen to you soon, on another DevOps Chat.

    — Alan Shimel

  • DevOps Chat: Developers and Security with Pete Chestna, Veracode

    DevOps Chat: Developers and Security with Pete Chestna, Veracode

    In this DevOps Chat we speak with Pete Chestna of Veracode about the roles and opinions of both developers and security pros about how and who should be working on security in the enterprise. Much of the discussion centers on a survey Veracode conducted with consulting firm Enterprise Strategy Group (ESG).

    Pete is always a great interview with a common-sense approach to DevSecOps borne from being both a developer and security pro. I am sure you will enjoy this discussion. As usual, the streaming audio of our discussion is immediately below and the transcript of our discussion is below that.

    Audio

     

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel of devopsy.kinsta.cloud here for another DevOps Chat. Today’s guest on the chat is Pete Chestna, Veracode, a CA company, director of developer engagement. And that’s a fancy way of saying Pete’s out there talking to developers about bringing security, shifting it left, bringing it into the developer universe and making all of our apps more secure. Pete, welcome to DevOps Chat.

    Pete Chestna: Thanks, Alan. Pleasure to be here.

    Shimel: Yep. So, Pete, you and I have, of course, crossed paths before and I’ve seen you present and you’re a knowledgeable, knowledgeable person, in terms of how security is continually kind of making inroads into the developer community and kinda convincing them that security’s everyone’s responsibility, right? That security isn’t just the purview of the security team; it’s everyone’s job. And you’re doing a heck of a job with it, which has, I think, attested to Veracode’s value in the market and its place in the market, so great job there.

    Chestna: Thanks.

    Here are some other DevOps Chats you may want to listen to:

    Node.js Becoming More DevOps-Friendly
    DevOps Chat: State of DevOps Report 2017, Nigel Kersten, Puppet
    DevOps Chat: Why Real Transformation Starts with Culture, Bryson Koehler and Shelbee Smith-Eigenbrode, IBM

    Shimel: Pete, what we’re gonna talk a little bit about today is that Veracode recently conducted a survey of developers and security folks, talking about this very subject. And I wanted to share it with our audience a little bit, if you can. Why don’t we start with what you consider sort of the headline of this survey?

    Chestna: Thanks. So this was done with the enterprise strategy group and the key takeaway for this is, really, again, it’s reinforcing the messages we already bring out to the market, so we need increased accountability. The reason that developers don’t take security more seriously is because they’re held to account for their functionality and not necessarily their security, so, if we bring in metrics and goals into the equation, for developers, we’re gonna see an increased uptick in the way they think about security. It’s about building relationships with your security team, so security and developers need to work together to build that relationship, so, that way, they feel like there are people on each side and not just a function.

    And, really, it’s what I call the “three-legged barstool of application security.” It’s about training, making sure developers are trained—a lot of the times that they don’t wanna develop these tools is because they don’t know what to do with the results. Second is integrate and automate—if you bring it into their toolchain and make it easy for them to use, then they’re more likely to use it. And, lastly, it’s about helping them fix what they find—again, this knowledge gap of, “What is across-site scripting? What is OS command injection?” Help them understand how to fix these and prevent them makes them more likely to adopt these tools and make security a better part of their work.

    Shimel: Got it. And you know what, Pete? So I’m up here in Boston, recording this, and we just finished a DevOps Connect. I had an interesting question from the audience yesterday, and a gentleman said, “Well, our developers kinda get paid or judged on how much code they commit. And to go back and tell them that the code they committed, you know, it had vulnerabilities and they gotta fix it, it really upsets them.” I’m sorry for them, right, Pete? But –

    Chestna: Right.

    Shimel: – to me, it’s kind of—you know, I used to see this problem with running sales teams and stuff like that. You’ve mismatched incentives here. Right?

    Chestna: Oh, absolutely.

    Shimel: You know, and that has to be—and that’s not the developer’s or the security guy’s fault; that’s management’s fault.

    Chestna: Yeah, if we don’t take accountability for what we’re doing, if we don’t hold the developers—so, you know, I always look at the security team. They are responsible for security but the developers need to feel accountable for security. And you’re right; it’s management that needs to say, “We’re gonna measure you on this and it’s gonna be part of how we evaluate you at the end of the year.” That will drive the right behaviors. They’re gonna do what they get paid to do. And if they get paid to produce functionality faster, that’s exactly what they end up doing.

    Shimel: Yep. And so this is apparently something, I think, we need to solve. You know, we’re gonna see real progress in the area. But, look, let’s save that for another day. Pete, can you share some more of the findings on the survey with us?

    Chestna: Yeah, absolutely. So a couple of things that stood out to me, as I read through it, was there’s a increased maturity as far as adoption of Agile and DevOps. There’s only 5 percent of respondents that said they have no Agile in their shop at all, where 18 percent say that most or all of their products are using a Agile methodology. And then it goes on from there—28 percent is more than half. So we’re seeing a really good adoption, at least of Agile. And then if you think of DevOps usually being run on an Agile methodology, only 6 percent of respondents says they haven’t adopted DevOps at all and 17 percent are reporting that they have extensively adopted it, so great numbers, as far as people coming up to speed in doing this. And, as far as making things easier, 45 percent of respondents said that DevOps makes it easier for them to developer software, including security, which is a great finding.

    Shimel: That is—what was the number? 45? Just about half?

    Chestna: Yeah.

    Shimel: Excellent.

    Chestna: So those must be shops that are doing it well because they’re seeing the benefits that you get from experiencing DevOps.

    Shimel: Well, I mean, you know, Pete, you take this, I think, in conjunction with the recent release—I was out in London last week for DOES and the folks at DORA and Puppet released the State of DevOps for this year’s survey and results, and it dovetails nicely here, where DevOps-enabled organizations deal with something—I forget what the number was—15 percent less vulnerabilities or 15 –

    Chestna: Right.

    Shimel: It was some –

    Chestna: It was from the Puppet report.

    Shimel: – eye-popping number of the improvement in the quality of code, vis á vis security. So it seems to make sense, but you know what, Pete? I’m amazed that something that seems so, you know, simple, so elementary, if you will, is still—we’re still talking about only half of organizations, a little less than half organizations doing it. What do you think is holding back the other half?

    Chestna: It’s the culture. You know, people wanna maintain their silos. I see it all the time where the management—again, we’re going back to management, as a problem here—they wanna hold on to their silos and their power. And if you look at where DevOps takes a company typically, if you do it whole-hog and embrace everything, you’re reorganizing, so someone that has a large quality staff reporting to them is now gonna have that broken up and disseminated into other teams, and now they’re gonna be responsible for other functions or they’re gonna have to go find another job. So there’s this big unknown and fear for them of, “What does the future hold if I just don’t do quality and I have to actually produce product?” So this cross-accountability is just—is scaring the hell out of them.

    Shimel: Yeah. Yeah. But you know what? Let’s not put it all on the dev side of things; let’s talk a little bit about the security folks, too. And, Pete, you and I both come from the security world. There are a lot of security people who get very territorial, you know, to say the least, around running scans, being the ultimate deciders of what’s secure and not secure, and they’re just as resistant to change, from a cultural point of view, as dev teams are sometimes. I mean, do you agree or –

    Chestna: Yeah, and they white-knuckle the release, so –

    Shimel: Yeah. [Laughs]

    Chestna: – I’ve talked to a lot of people that say, “Hey, it’s gotta be pen-tested. I have to pen-test everything.” If you’re talking about releasing multiple times a day, there’s no way in heck that you’re gonna be able to do that. So you have to pick your battles and say, “This is important. It touches crypto or this touches authentication or authorization. It has to be pen-tested,” versus, “I can use the easy, least expensive way of SAST and DAST to go and find vulnerabilities and I can trust that those tools will find things.” So it’s that back-and-forth of how much security needs to be in there and how assured do they need to feel before they can sleep at night.

    Shimel: Mm-hmm. And they’re ultimately, Pete—you know, I think, when we look at surveys like this and we talk about the view of the security team versus the view of the dev team, view of management, really, the way to kinda bridge these gaps and bring this all together is really a lot of the kinds of things that you do. Right? You’re out there, talking to the different constituencies around the world, almost constantly—we were talking off-mic about how much both of us have been traveling—but there’s a mission there to bring these tribes together, if you will, and forge a common path and a common way of working together. And I think, if we take surveys like this and we look at the results and we share those results with the two teams, again, it becomes sort of like, “Duh. What are we fighting about?”

    Chestna: Oh, exactly. So, I mean, if I go back to the survey for a second here and look at how people are being measured, 33 percent of respondents say, “I’m being measured on functionality that I released,” versus only 18 percent that are saying, “I’m being judged on security.” So, if you look at that number and say, “Well, what are they doing? Their actions reflect how they’re being measured, so let’s change how they’re being measured and see if that changes what they think about their jobs.” The people that responded and looked at “Does DevOps help me with security, the ability to automate and integrate?” 58 percent of respondents said, “Hey, it allows me to do this integration and automation,” which is one step toward getting them to actually pay attention to those results.

    Shimel: Yeah. And 58 percent is a sizable majority.

    Chestna: Yes.

    Shimel: That is Pete, I don’t know if you have the insight on this, but these were large enterprises, primarily, that were surveyed here?

    Chestna: Yes, most of them were—98 percent were 1,000 or more employees.

    Shimel: Okay. Now were there any particular verticals that were highlighted or anything?

    Chestna: The biggest ones were IT at 23 percent and the finance industry at 21 percent.

    Shimel: Oh, okay, there you go. And those are both pretty DevOps-savvy, if you will, or maybe early—no, I don’t wanna use the term “early adopters,” ’cause finance is very rarely an early adopter, but, I mean, certainly, DevOps has taken a strong foothold within the financial and financial services industry, so.

    Chestna: Yeah, and the thing is driving them is really the regulatory compliance, so 53 percent of respondents said that, “We’re doing app-sec because of regulatory.” Forty percent are saying it’s because of corporate governance. And an interesting stat here was 34 percent said it was because of customers or partners, so the great news is people are starting to pay attention to their software supply chain, to say, “Am I getting secure software to install in my environment?” and they’re asking customers to prove that they are. And, hopefully, that also means that outside customers, like individuals, are also looking at security as an important decision in where they go and where they spend their money.

    Shimel: Yep. I agree. I mean, it is interesting stuff, Pete. So, Pete, where do we go from here with this now?

    Chestna: So I think the next step is to continue the journey that you and I are on, of helping security understand development, help development understand security, tell them that they need to build in accountability. It’s built by relationships, so they have to work together. If security starts to teach developers how to do secure development and explains to them how to fix the things that they’re finding, developers are more likely to engage because it’s not this great unknown of “Hey, I don’t wanna go in and fail. I don’t wanna go in and look like an idiot,” or, “I don’t wanna go in and not understand what I’m doing.”

    So security needs to take their part and companies need to understand that training and development and education around security is a carrying cost of having developers. They were never trained to do it and they have to pick that cost up; it’s not like they can just throw them all away and bring in new developers because the developers that they bring in are gonna have the same problem. So getting that education done leads to better engagement, leads to better results.

    Shimel: Agreed. And you know what, Pete? Just a shameless plug on that note: I’m gonna be out in Singapore at the end of July, at the RSA APJ show, putting on another DevSecOps event at RSA, and we’re working with both the local—so it’s interesting. In Singapore, there’s almost a 900-person-strong DevSecOps MeetUp group, which is huge for that area of the world, and there’s an equally-as-big DevOps MeetUp group. And we’re working with both of these MeetUp groups, as part of this event, and we’re really—I’m hoping to really kinda bring these tribes together and make it happen. Of course, I’d –

    Chestna: Sounds great.

    Shimel: – you to come out. You’re in Black Hat at that time.

    Chestna: Yes.

    Shimel: Are you speaking at Black Hat, Peter?

    Chestna: I’m not. I’m doing customer stuff, customer-facing.

    Shimel: Ah, very good. So you’ll be in hot Vegas and I hear Singapore’s pretty warm now that time of year as well. Well, we continue along our mission of spreading the good word, right?

    Chestna: Yes, sir.

    Shimel: as they say. Anyway, so, Pete, we’re about out of time. I know you don’t have the URLs off the top of your head right now, but we will include them in the show notes for people to download the results of the survey and the report, maybe find out a little bit more, but I wanted to thank you for sharing and giving us a little bit of insight into the results. And then keep up the great work, Pete. You do good stuff.

    Chestna: Thanks. I appreciate your time, Alan.

    Shimel: All right, Peter. This is Alan Shimel for devopsy.kinsta.cloud’s DevOps Chat and we’ll see you on the next chat.

    — Alan Shimel

  • DevOps Chat: Waterfall Will Not Disappear, with Flint Brenton, CEO Collabnet

    DevOps Chat: Waterfall Will Not Disappear, with Flint Brenton, CEO Collabnet

    One of the perks of being editor in chief of devopsy.kinsta.cloud is I get a chance to meet with so many leaders of the DevOps and IT industry. You can really learn a lot by listening to what these folks say. This DevOps Chat is a perfect example. I sat down with Flint Brenton, CEO of Collabnet. Collabnet is not some johnny-come-lately. The company has been helping developers and IT professionals for a long time. Flint talks about the fact that while DevOps is a great path for many organizations, it may not be the right way for every situation. Waterfall is not going away entirely.

    Have a listen to my discussion with Flint and hear for yourself what he has to say on the subject. As usual, the streaming audio player is immediately below with the transcript below that. Enjoy!

    Streaming Audio

    Transcript of Audio

    Alan Shimel: Hey, everyone. This is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. Happy to be joined in this DevOps Chat by Flint Brenton, CEO of CollabNet. Flint, welcome.

    Flint Brenton: Hey, Alan. It’s great to see you again.

    Shimel: Great to see and hear you again. Flint, the last time I think you and I talked was back at the DevOps Enterprise Summit in San Francisco. I guess that had to be October or November.

    Brenton: November. Actually, it was the same week that our new president was elected, if you remember.

    Shimel: Yes. Yeah, a red letter day.

    Brenton: Right.

    Shimel: So, Flint, without getting any further into that, let’s turn the conversation to CollabNet. What—well, first of all, maybe some of our audience is not familiar with CollabNet in general, so why don’t we start with that? Can you give us a little CollabNet background?

    Brenton: Yes, absolutely. So CollabNet is a SAS-based, cloud-enabled development platform focused exclusively on enterprise that delivers application lifecycle management capability for both Agile and waterfall development processes.

    Shimel: Mm-hmm.

    Brenton: The version technology to structure those builds and to maintain high quality and high quality control throughout the process. And then we also provide the DevOps infrastructure to build and deploy automatically whatever gets created in Azure or waterfall, with high quality, on time, and, to the extent we can help, under budget. So that’s really our focus.

    Shimel: Sure. And you know what, Flint? I remember this about CollabNet. You guys have been in business now for a number of years, certainly before DevOps was what it is today, let’s call it, whatever it is today. How long have you been—

    Brenton: Yeah, we’ve been in business—this is our 18th year.

    Shimel: Absolutely. So, you know, DevOps is another technology innovation, if you will, that’s come down the road, but I think what—not unique, but what is one of the special qualities of CollabNet is is that you’re not out here saying that the whole world needs to go DevOps today, right, that everything—we should be all DevOps all the time. But you have customers who are still on waterfall and may very well remain on waterfall for the foreseeable future.

    Brenton: Right. And we really invest very heavily in both waterfall and Agile development platforms and—although the growth rate for Agile’s higher than waterfall in enterprise, we still see roughly 70 [percent] to 75 percent of enterprises using a waterfall methodology. But the fastest growing segment in that area is clearly Agile.

    Shimel: Sure. And I—obviously. But I think what’s important for our audience to recognize is even the biggest DevOps and Agile advocates or biggest—whatever you wanna call ’em, should recognize that there are still projects and places where waterfall might be the best way to skin the cat, to complete a project correctly. And it doesn’t have to be an all-or-nothing type of environment, if you will.

    Brenton: That’s exactly right. You know, the industries that tend to be highly regulated, with a high need for security, compliance, and scalability, tend to lean more towards waterfall development. And, of course, once you started a process where you’ve got an established team that’s been using waterfall for a long period of time, they tend to prefer to continue with that. But it’s new projects, new projects where maybe time to market outweighs the need for compliance and security and scale—those tend to go Agile in an enterprise. But, either way, regardless of development methodology, the things you need beyond the tool chain or the process of building software is fairly similar, right? The way you use version control is fairly similar. The way you use DevOps technologies is also very similar.

    And what we found is customers who are well grounded in Agile and waterfall—typically, in enterprise, they have both—getting your act together in DevOps and making sure you have a strategy, you created a culture to embrace and execute that strategy, then having the processes and tools in place to bring it to reality is critical because you don’t really get the return on investment for anything you develop, regardless of the methodology, until you put the build into production. And that’s what DevOps, at the end of the day, is all about.

    Shimel: Sure is. Excellent. Excellent point, Flint. Flint, let me turn things a little bit ’cause, as I mentioned to you off camera, off mic, 15 minutes here goes pretty quick. Want to talk about some recent news around CollabNet in the industry. I understand you guys were just included in a Gartner Magic Quadrant, correct?

    Brenton: Yes. Yes, thank you for bringing that up. Yeah, we’re very excited about it. It’s always a reflection of the investment our team has made in Agile planning and execution. So we’ve always been considered a leader when it comes to waterfall development, but, as we just mentioned, for enterprise, our enterprise customers are really demanding that we provide both, both equal value in waterfall and Agile. So we invested heavily in the last few years in Agile, and, as a result, we were just included in their Magic Quadrant as a visionary for Agile planning and execution, and we’re very excited about it.

    Shimel: That’s nice. That is great. And I know everyone always wants to be in the upper right, but, really, having my background, being entrepreneurial and having started businesses, I’d almost rather be in that visionary quadrant than the upper-right leader quadrant and certainly in the visionary quadrant over, let’s say, the challenger quadrant, which is the upper left, because I think, with visionary, I mean, the recognition is that you’re setting a—you’re pushing the envelope, right? You’re pushing the vision—hence, “visionary.”

    Brenton: Right.

    Shimel: So congratulations to you guys. I know, in speaking with your team, you have rights for download of the quadrant, so what we’ll try to do is put into the show notes here a link to that where people can download the quadrant report and see if—check it out for themselves.

    Brenton: Yeah, that’d be perfect and I’m sure that your listeners would very much appreciate that.

    Shimel: Sure will. So, Flint, beyond the quadrant inclusion, though, what else do you see that’s happening with CollabNet or in the market in general?

    Brenton: We’re starting now to get a number of customer wins that are embracing our motto of providing a cloud-based service where you can consume our integrated ALM, version control, and DevOps solution either in Amazon or on our own private cloud and, in many cases, a combination of on-prem and off-prem.

    Shimel: Right.

    Brenton: So we now have a number of customers who have completely moved their development process into one of our cloud-enabled environments, and it’s very exciting.

    Shimel: That is exciting.

    Brenton: It’s very exciting. And the great (thing) about that is, if it’s in the cloud, it’s actually easier for us to include, Alan, both open-source and compare it to components that we don’t own or control because then the need to test to get everything in your data center  is lessened and our ability to innovate to your advantage is much greater, so we’re very excited about that.

    Shimel: Absolutely. So, Flint, interestingly enough, I was reading an article this morning—I forgot where I saw it but it was a recent survey where 65 percent of enterprises still keeping the majority of their infrastructure on their own data center, not on a public cloud, not a hybrid situation. Is that about what you guys are seeing but is the arrow pointing up to the cloud? What’s your take on that?

    Brenton: Now that’s a great question, Alan, and it’s absolutely what we’re seeing. So a thing to keep in mind, though, is “What is the variable that’s changing and what is the velocity of that change?” Right? So I would say, two years ago, that 65 percent number was probably 90-plus, right? So, as enterprises get more and more comfortable with the security and compliance options in the cloud, whether it’s in a public cloud or private cloud, they can see the tremendous advantages of driving down the cost of development and actually increasing the speed of innovation by going to the cloud.

    I’ll give you an example. U.S. government, we do a tremendous amount in federal, and so both the Obama administration and now it’s transitioned to the Trump administration has really been pushing the department of defense to do a couple things. One, innovate faster, and so, if you just think about the U.S. government is barraged by cyberattacks from all over the world. Right?

    Shimel: Mm-hmm.

    Brenton: And so your ability as a professional, in NSA or CIA or the FBI, to deal with that is you want a complete toolkit of things you can use, and you want to choose the tools you need to deal with those cyberattacks, but you also need to do it quickly. So if you can use open source, it helps. If you can deploy it in a cloud, it dramatically increase—or decreases the time to deployment. And, three, it also tremendously helps you on the economics side. So even something as highly regulated and structured as the US federal government, there are advantages sometimes in doing things in a public cloud to help, and so we’re starting to see variations of that theme also in industry, primarily around enterprise, where there’s flexibility, increased ability to innovate, and improved economics by moving workflow to the cloud.

    Shimel: Yep. You know, Flint, living in the tech world and you lived the world—you live that life; I live that life—I think sometimes we get  jaded in that we’re in this bubble of, “What’s the hot new thing?” and it’s DevOps and it’s whatever’s next after DevOps, and then sometimes you get a reminder—65 percent still not in the cloud. And you say, “But I thought everyone’s in the cloud.” And I think it does good for us to remember that there’s a big world out there that moves at their own pace and their own—

    Brenton: Right.

    Shimel: Same thing with waterfall. Right? I think people would be—people in our audience from devopsy.kinsta.cloud would probably be surprised to find out how many organizations still either haven’t adopted DevOps or are primarily waterfall shops.

    Brenton: You know, the key, when you’re a solution provider like CollabNet, is you need to meet people where they are. Right? So, if they wanna be on-prem, you need to be able to deliver them superior value on-prem. If they want to move part of their workload to the cloud, you need to be able to help lead them and sponsor that transition at that pace by which they’re comfortable. Right? So I learned a long time ago the key to success in this business is to give people what they want, right? He who can do that best with a quality solution at a great price is gonna win. Right? So that’s just the way it works, right?

    Shimel: Absolutely—and that hasn’t changed, by the way, through all of these innovations, and I think it was true 100 years ago and it’s true today. Or maybe even more than 100.

    Brenton: You bet.

    Shimel: Anyway, Flint, listen, I think we’re about out of time here. I wanna be respectful of your time, so what we will do is let’s have you on again soon when we have some more time and we can delve into this. Are you gonna be at DevOps Enterprise Summit maybe in London?

    Brenton: You bet. Yeah.

    Shimel: Or San Francisco?

    Brenton: Well, I always enjoy speaking with you, Alan. You’re a great guy and you’re—

    Shimel: Thanks.

    Brenton: —you’re a fun guy off camera too, I will add.

    Shimel: [Laughs]

    Brenton: So I look forward to our next adventure together. Thank you for the—

    Shimel: Absolutely. Hey, Flint—

    Brenton: All right.

    Shimel: Flint Brenton, CEO of CollabNet, this week’s guest on DevOps Chat, thanks for joining us. This is Alan—

    Brenton: My pleasure, Alan. Thank you.

    Shimel: Thank you.

    Brenton: All right. Buh-bye.

    Shimel: This is Alan Shimel for DevOps Chat.

    — Alan Shimel

  • DevOps Chat: Aruna Ravichandran, Co-Author, DevOps for Digital Leaders

    DevOps Chat: Aruna Ravichandran, Co-Author, DevOps for Digital Leaders

    Our first podcast of 2017 is with Aruna Ravichandran, co-author of DevOps for Digital Leaders. Of course when not authoring books or helping financially challenged but gifted students attend college, Aruna is a VP of DevOps marketing at CA Technologies. I have interviewed Aruna before on DevOps TV and discussed her career that has seen her go from a million lines of code contributor at HP and Juniper to business line executive.

    Aruna is a very interesting person who also has some great things to share. That is why I think you will find not only this DevOps Chat interesting, but her book as well.  Also, we will be doing a full hour Q & A with Aruna on January 17th that you can sign up and attend for free. If you like this interview, don’t miss the webinar. Also, if you would like to download the book you can here: http://www.apress.com/us/book/9781484218419

    In the meantime, as is usual on our DevOps Chats below is a streaming audio of our Chat with the written transcript below. Enjoy!

    Alan Shimel:                Hey everyone, Alan Shimel here with our first DevOps chat of 2017 and we’re lucky to have Aruna Ravichandran, a VP DevOps Marketing at CA Technologies. Aruna welcome.

    Aruna Ravichandran: Thank you Alan. Thanks for actually having me. I’m excited to be here with you.

    Alan Shimel:                Well, you are leading of 2017 so we’re going to set the bar high right away Aruna and hope to live up to it.

    But Aruna, truth be told, we don’t have you on today in your VP of DevOps role: you’re here as Aruna the author today and we’re going to talk about a book that actually came out I guess towards the end of last year but it’s still out there and we’re going to be doing a webinar on it later this month, and I wanted to really talk to you about that a little bit.

    The book is called DevOps for Digital Leaders. Correct?

    Aruna Ravichandran: Yes, that’s correct.

    Alan Shimel:                And why don’t – just from the get-go why don’t you give our listeners a little bit of an overview of what the book is about.

    Aruna Ravichandran: Sounds good. So this book is called DevOps for Digital Leaders, it’s all about how one can reignite their business with a modern DevOps-enabled software factory. I embarked on this journey on writing this book almost about a year-and-a-half ago along with two of my co-authors Karen Taylor as well as Peter Waterhouse.

    We looked at all the different books within the market – there is no dearth for books in the market when you think about DevOps – but what we saw was that even though there are so many different books in the market nothing really talks about some of the pain points which we constantly encounter customers asking us when we talk to them.

    Some of the pain points which customers constantly ask us are, “I want to be able to start this journey called DevOps. How do I start? What should my journey be? Where can I start? How do I develop? What should be my maturity model?” And so that’s one question which we constantly get across the board.

    Second pain point which we have heard from customers is, “How do I actually measure the success of DevOps? What kind of metrics can I use? How is success actually going to look like which I can report back to my management chain that whatever initiative I have embarked on with DevOps is now actually successful?”

    So we talked to several – over 100-plus customers – we learned from their experiences on what metrics are actually used and what is actually built practically in the industry and shared those in the form of use cases as well as actual metrics in the book.

    So the book primarily focuses on DevOps adoption in terms of a journey as well as what are some of the key metrics one can actually use in order to embrace DevOps.

    Alan Shimel:                Great. Aruna you hit on a couple things that are kind of near and dear to me. One is something that I’ve spoken about and talked to people now for a while which is too many people – you know, DevOps is so hyped and so many people are positioning DevOps to be, you know, it’s this great, white unicorn that’s crapping out rainbows for everyone but it doesn’t always work like that, right?

    There are failures, there are challenges, there are hurdles, and not everyone who just wants to do DevOps can wave a magic wand and become a DevOps factory or a modern software factory. So I’m glad to hear that this is kind of something that you guys are exposing in the book.

    The other thing is, you know, in almost three years of doing devopsy.kinsta.cloud now I find that our listeners, our readers learn the most from listening to how their peers have dealt with stuff: so case studies, case scenarios and these kinds of things. So the fact that you had access to hundreds – literally hundreds if not thousands – of customers who CA Technologies – CA has worked with – really gives us some great insight.

    Can you give our listeners a little bit of a taste for the kind of – I know you call them case scenarios – and they’re kind of case studies, right? – can you give us a little flavor for what those are like?

    Aruna Ravichandran: Yeah, absolutely. So if you look at the book it’s organized across the entire software factory. Let’s say if you think about customer deployments DevOps basically goes all the way down from planning to requirements to development, testing, release, and then into operations.

    And so what we did was we talked to – we interviewed several different practitioners who are existing CA customers, sometimes we even talk to non-CA customers – understood the role DevOps plays in terms of culture and collaboration as well as the toolsets which they’re actually leveraging in order to implement DevOps within their companies.

    And we looked at – we _____ the use cases around the whole software delivery to the chain. So if you look at the book – even though we talked with several thousand customers – you know, we couldn’t basically put all those case studies within the book, so what we did was we broke up the book across the entire software delivery chain and there is a chapter dedicated for every aspect of the software factory starting from planning to development to testing to release to operation and we leveraged one customer example on how they actually implemented DevOps best practices along with the underlying toolset and what are some of the metrics or the results they actually got in terms of being able to show what success actually looks like.

    Alan Shimel:                Got it. So Aruna I wanted to touch on another aspect of DevOps adoption that you hit on in the book, and that is the idea that not everyone started their DevOps journey at the same time or are going at the same speed or at the same rate, right? Some organizations are relatively mature in their DevOps adoption and DevOps practices: others are still talking about starting. So is there something for everyone in the book or do you need to be sort of on-your-way DevOps expert to really get value?

    Aruna Ravichandran: No. So, you know, like I said because we knew that there is no clear-cut framework, right – like if you think about I-_____ there is a very prescriptive framework in terms of where you can actually start and how you can actually end. With DevOps one can start many different ways.

    So what we actually did was we looked at some of the best practices a lot of the customers have actually implemented and built a framework in terms of a maturity model and we shared that as best practices.

    So if you think about accelerating the maturity we talk about, you know, three different examples of how customers could actually start. The first way is to basically build an end-to-end release management system; and the second one is to how can you operationalize with feedback loops going all the way from Dev to Ops and vice versa.

    And the last one is how could you actually optimize the continuity stability pipeline?

    So we shared some of the best practices in terms of where one can actually start and how they can actually modify their processes to give them a lifecycle regardless of where they want to start. They could start in Dev and end in Ops; they could start with Ops and make changes to Dev. But we shared some of the best practices in terms of maturity model which customers can actually implement.

    Alan Shimel:                Excellent. Aruna, again, we only have 12 minutes or so on these podcasts but we’re going to spend about an hour – 45 minutes plus 15 minutes in questions – on an interactive Q&A webcast with you on this subject.

    And I just wanted to, in our remaining time here, remind everyone or let everyone know that the webinar is scheduled for January 17th – so about two weeks from today or so – a little less than two weeks – at 2:00 PM Eastern Time. And within these show notes – if you’re listening to this on Sound Cloud or iTunes – within the show notes there we’ll have a link to the webinar. And if you’re reading along or listening on devopsy.kinsta.cloud we’ll have a link to the registration there as well. You can get to the registration on devopsy.kinsta.cloud – go to the webinar section and of course it will be listed there.

    But importantly Aruna I wanted to mention the book itself is free, correct, for download?

    Aruna Ravichandran: So the software version of the book is free. If they want to get the hardcopy they can buy it through Amazon or through our publisher which is Apress. I also want to call out and say that if they buy a hardcopy version of the book we are donating all the proceeds – the royalty from the book are being donated to a nonprofit corps Foundation of Excellence – the Foundation of Excellence’s mission is to award university scholarships for exceptionally talented but economically underprivileged high school graduates in India in order to embrace stem carriers.

    And so they can either go through the softcopy of the book or they can download the hardcopy and that all of their contributions are going to be donated to the nonprofit.

    Alan Shimel:                That’s great Aruna. Fantastic. I also want to mention that for those who register and attend our webinar we are going to give out ten signed copies – signed by Aruna and her co-authors – to ten folks who attend the webinar. I have to mention that those are US-based folks only as the logistics of mailing hardcopy books make it prohibitive to send them across the oceans. But ten US attendees will win signed copies of the book and everyone who attends will get a link to download the soft version, and of course you can buy the hardcopy version – the hard-book version on Amazon or Apress. Again, we can register that at devopsy.kinsta.cloud.

    Aruna, we’re almost here at the end but just to give some of the people – some of our listeners a little tease of what we’ve got going on. I know there’s some CA-sponsored DevOps research that’s due out shortly and that kind of reinforce this idea that organizations that do DevOps are doing better. Can you give us a preview or you’re not allowed yet?

    Aruna Ravichandran: I can give a little bit of preview. But what I can say is we did our research with one of our analyst vendors and partners with over 1,200 participants around DevOps and what I can say is that 87 percent of DevOps adopters have reported an improvement in customer experience.

    There is a lot of rich statistics which we uncovered as a result of that particular survey and we will be able to share the results from that particular survey report on January 11.

    Alan Shimel:                Great. Maybe we can speak about it a little bit on the webinar for January 17 as well – or incorporate it into –

    Aruna Ravichandran: Absolutely we will.

    Alan Shimel:                That sounds great. Well, Aruna, we certainly look forward to the webinar on January 17, but more, you know, as importantly, congratulations on authoring or co-authoring what sounds like a great book, and kudos actually for your donating the proceeds of the book to a worthy cause: I think it says a lot about who you are and what are the kind of reasons behind that, so thank you.

    Anything else before we wrap up?

    Aruna Ravichandran: Nope. I’m very excited to partner with you in order to share our experiences around writing this book and the journey, and hope that this book will be insightful for all of our DevOps practitioners who are embarking or are already on their way within DevOps.

    Alan Shimel:                Okay. Well, Aruna Ravichandran, co-author of DevOps for Digital Leaders, thank you so much for appearing on this episode of DevOps chats and we look forward to our interactive Q&A webinar on January 17 at 2:00 PM with you to continue our discussion. Thank you.

    Aruna Ravichandran: Thank you Alan.

    Alan Shimel:                Thank you. This is Alan Shimel for devopsy.kinsta.cloud and we’ll see you soon on another DevOps chat.

    — Alan Shimel

  • DevOps Chat: DevOps & CD with Tim Butel, XebiaLabs

    DevOps Chat: DevOps & CD with Tim Butel, XebiaLabs

    devopsy.kinsta.cloud caught up with Tim Butel, VP of Products at XebiaLabs. Tim discussed some of the latest trends in DevOps & continuous delivery (CD) with us. He also gave us a great update on what XebiaLabs has been up to recently and why organizations including Gartner and others consider XebiaLabs a leader in the category.

    Tim also gave us some great insight into how he has progressed in his own career. How can someone listening to this try to set out on a similar career path? Tim’s journey may prove helpful to you.

    As usual, below is the streaming audio of our conversation and below that is the transcript of our conversation, Enjoy!

    Alan Shimel: Hey, everyone, Alan Shimel, devopsy.kinsta.cloud here, for another DevOps Chat. Today’s DevOps Chat’s guest is Tim Buntel, VP of products at XebiaLabs. Tim, welcome.

    Tim Buntel: Thanks so much, Alan. It’s a pleasure to be joining you today.

    Shimel: Yep. Well, no, it’s our pleasure to have you here. So, Tim, I know you’re fairly new, though not really new new to Xebia, but how long have you been on board there now?

    Buntel: Yeah, so it’s coming up on about six months now, so long enough to have had a couple releases and seen where we’re going as an organization and start to chip in, but can’t take too much credit for all the success of the company yet.

    Shimel: No. Okay, fair enough. And then, Tim, VP of Product. So you’re—give our listeners what exactly does that entail in terms of your responsibilities.

    Buntel: Yeah certainly. So, you know, my team brings together product management, user experience, and all of the folks who are basically bridging the needs of the market to the rest of the organization. So we’re looking strategically at where we want to invest in new features in the products, we’re bringing requirements back to the engineering team, we’re designing the solutions for the features, and then we help bring that back out to the market. So interacting with the analysts and press, interacting, you know, in the support capacity to sales and that sort of thing. So really being that conduit between the market and the customer’s needs and all of the activities that are happening in the organization.

    Shimel: Great. And Tim, you know, we might have some people out there who are a little younger, starting out in their careers, and they hear, wow, this guy is VP of Product at a company like Xebia. Can you give you listeners, give us a little bit of background, so what sort of qualifications, what experience did you bring to this position that kind of, you know, makes you able to succeed at it?

    Buntel: Hmm. Yeah, I mean, product is a great role for folks who really want to help be the advocate for their customers. So in my case, my whole career has been in Dev tools and building businesses that create product that other software engineering companies, you know, sell and use. So I ran the developer tools business at Atlassian, I’ve worked for Microsoft and Adobe, I’ve done a couple of startups that are in the Dev tools space myself.

    But the most important thing was originally I came from a development background myself. So as a developer, I was able to understand the challenges that development organizations faced. So often when I talk to professionals who are in this space, you know, maybe you are a DevOps engineer or you’re a software professional and you like solving problems, and you have a keen sort of interest in the people, right? So talking to people, understanding what their problems are, and then being able to creatively come up with solutions to those problems, that you can turn into a product so that you’re not only solving one person’s problem, but you can turn it into a product that solves that problem at scale for a market. Those are really the qualities that are most important for the job. So understanding the space and the domain—understanding, you know, in my case, what it means to build software—and then wanting to work with other creative people to find solutions to those problems, that can translate into a road map of features in your product portfolio.

    Shimel: Excellent, excellent answer, and I hope our listeners or anyone who might be interested in that topic takes that to heart, Tim. I think there was some great advice and lesson there. So let’s turn a little bit, Tim, though, and talk about Xebia, right, and to kind of lay the groundwork, to you, what is XebiaLabs really all about? What is the secret sauce of XebiaLabs, if you will?

    Buntel: [Laughs] Yeah. I mean, I think for me, the most important thing about us is that we’re really focused 100 percent on continuous delivery. We’re an independent company and that’s all we do. So every day we wake up and we figure how can we help other software organizations, generally they’re enterprise IT teams, how can we help them deliver better software faster, with less risk, right? So we combine many years of experience in that area. We were looking at deployment automation, as much as seven years ago now, I guess, so really before the term DevOps was even broadly adopted, we were solving these problems for large enterprises. And to this day, we continue to do that. So we are able to solve really large-scale enterprise problems because it’s 100 percent of our focus.

    Shimel: Excellent. And so that being said, Tim, now that we know sort of what Xebia is about, I guess fair to say what attracted you to this position? You have a long resume of success with some very, very successful companies, obviously. What was it about Xebia that said, man, this is where I want to be?

    Buntel: Yeah. Well, it’s really the culmination of a lot of the pieces that I’ve been working on in my whole career. So if you look at a software engineering organization today, many of the products that I’ve worked on constitute elements of that technology landscape that they have, right? So everything from issue tracking systems and collaboration tools at the beginning, through source code control and build tools and deployment tools, all the way to the end, to monitoring and user feedback, right? This is a great assortment of individual products, but it also results in a fairly chaotic landscape. So if you’re an organization trying to apply all of that at scale, keeping track and orchestrating all of that together has consistently been a challenge, right?

    So for me, this opportunity to step in and say, okay, the next really important challenge in doing continuous delivery at scale is to orchestrate all of those pieces, and that’s what we’re really focused on at XebiaLabs right now. So XL Release, for example, is release orchestration automation tool that does just that. So we can help organizations automate and manage that process for even the most complex pipelines, and for me, that was a great next step, right? So I had worked on some of these individual pieces that were solving very specific parts of a development team’s challenge, and now I’m able to step back and offer a solution that helps sit above all of that and really make all of those pieces fit together. It’s like a conductor in a symphony, you know, being able to get the most out of each individual musician. That’s kind of what we’re doing for all of these other great parts of the continuous delivery pipeline.

    Shimel: Excellent, excellent, excellent. So, Tim, why don’t we—we’ll continue on the Xebia topic here for a while. What’s new? What’s new, what’s exciting coming out of Xebia these days?

    Buntel: Yeah, there’s some great work that we’re doing. You know, we continue to get great recognition from the analysts and press, we’re getting some great coverage from Gardner and Forrester recently, which is really exciting for us. And what we continue to hear both from them and from our customers themselves is that because we’re focused entirely on the continuous delivery piece, we’re able to offer some insight into our users in a way that, you know, individual point solutions aren’t necessarily able to do that. So a large emphasis for us is on this kind of reporting and insight, being able to analyze the performance of your continuous delivery process and kind of your DevOps organization. That could be through reporting, it could be through analytics, helping organizations find out where bottlenecks might be in their process. So it’s not just managing things, but it’s helping guide you toward ways to improve the efficiency of your program, and even to help folks measure the ROI of that.

    So lots of organizations are trying to adopt DevOps and continuous delivery, and in many cases, it’s difficult for them to know what’s the ROI of that. So a big emphasis on our tools lately is on that aspect. So helping you get insight into your continuous delivery process, and we’re doing that in a way that’s extensible and supports integrations with pretty much any technology that you’re likely to find in the enterprise DevOps stack.

    So that’s one piece, the insight and analysis part. The other piece that I think is a real strength of ours, that’s very exciting for me, is the breadth of participants in the process that are successful with our products. So a lot of solutions that are out there helping organizations with continuous delivery are really focused on the most technical people in the process, right? So they’re very script-focused, they tend to be very technical, and really, in the enterprise, the people who are participating in continuous delivery or DevOps initiatives more broadly, they’re coming from a lot of different backgrounds. You might have, you know, less-technical business owners, you might have risk or compliance professionals, and a host of managers and other stakeholders besides the real technical teams.

    And one approach that’s been really centered to our product development recently is to make sure that the products are approachable, they have a great user experience, they are easy to use, they’re easy to understand, regardless of the degree of technical expertise in the user, while at the same time still satisfying all the needs that the most technical parts of the team have. So you can fully automate and fully script all of our solutions. We’ve got full API access and CLI capabilities as well. But the spirit of DevOps as a social process as much as a technical process can only be successful when the products are appropriate for folks with a range of different experiences. So that’s another really key focus for us now.

    Shimel: Yep. What about the bigger—Tim, what about the bigger DevOps market, and how Xebia is sort of playing in that. We’re starting to see, you know, DevOps Express, for instance, was announced two weeks ago at Jenkins. But, you know, I think that’s a symptom of a bigger—I don’t want to say disease, that’s the wrong word, but a symptom of a bigger thing, which is sort of interoperability, right? No one DevOps tool is gonna do all your DevOps for you, right? So what – you know, what do you think about that kind of trend, if you will?

    Buntel: Sure, certainly. You know, in fact, I can point to something that XebiaLabs has been running for the last couple of years now, probably, that really illustrates that beautifully. That’s our periodic table of DevOps. I don’t know if your listeners are familiar with it, but you can find it on our site, and it’s a, you know, a play on the periodic table of the elements, that’s cataloguing all of the different technologies that are typically present in, you know, a DevOps or continuous delivery stack. Everything from ticketing systems through STMs and builds and provisioning tools and all that.

    And it’s community-sourced, so folks vote on the technologies that they use and the things that are most important to them. And we have a new tool now that’s part of that, that allows you to define the pieces of technology that are part of your enterprise IT environment, and it’ll help display kind of what your DevOps environment might look like, based on the combination of all of those technologies. But my point there was that, yeah, exactly as you said, it’s such a cluttered landscape and it’s growing at such an explosive pace, right? There seems to be a new open-source technology that’s looking at a different piece of the puzzle that comes up almost weekly, right?

    So the challenge that we see for professionals that are in this space, especially in the enterprise, where you might be managing the development initiatives across different geographic locations and teams who are trying to be empowered to select their own technology is how do you centralize that and manage that while still balancing the control that you need as an enterprise, with the autonomy that you want to give your individual development teams to pick and choose the technologies that are best for them. our approach for it in our product is to really focus on integrations. So we have, you know, both of our products really emphasize integrations first, so that we can build integrations as they come to all of these emerging technologies, as well as the established and even older technologies. Everything from mainframe to the most recent sort of container or container management systems, we’re able to integrate with because we’ve built our products in this loosely coupled integration-based way. So that’s certainly something to look for if you’re considering how to construct your own continuous delivery or DevOps, you know, sort of landscape. Make sure that the products put integration at the center of how they’re able to hook together.

    Shimel: Got it. So, Tim, believe it or not, we—I told you we’d do this for 12 minutes, and we’re at 15.

    [Laughter]

    Shimel: It happens. Just one last question, and if you have an answer for it, fine, if not, it’s okay, but I usually always like to ask my guests if you had to recommend a book to our audience to read, a must read, what book would you recommend? It can’t be “The Phoenix Project,” by the way. We’ve already got that one, but go ahead.

    Buntel: [Laughs] Yeah. Well, yeah, well, you know, on my desk right now I’ve got sort of the following on “The Phoenix Project,” right? We have the new “DevOps Handbook,” from Gene Kim and Jez Humble, and we’re getting a lot of interest from our customers in that book, and, you know, we talk to Gene a lot and he has some really great insight. So I’m pretty excited—I’m about halfway through that, and there’s some really terrific case studies and great, practical, you know, kind of illustrations of how this actually works in real world technology and organizations out there. So that’s a great one for me, the latest.

    Shimel: Yeah, yeah. It’s interesting, a very different sort of focus than the first one. But anyway—

    Buntel: I love that—I love that there’s a good focus on metrics in this one as well. That’s something that I’m personally really interested in, is, you know, this ROI of DevOps initiatives, and I think he’s got some great case studies in there that help measure that.

    Shimel: Well, Gene is a metric nut.

    Buntel: That’s right.

    Shimel: So anyway, Tim, we’re at the end of time, really, we’ve got to wrap. Tim Buntel, VP product XebiaLabs. Thank you so much for being this episode’s guest on DevOps Chat. Hope to see you soon, and we’ll catch up again, all right?

    Buntel: Thank you so much, Alan, and look forward to talking to you again sometime soon.

    Shimel: Okay. This is Alan Shimel for devopsy.kinsta.cloud. See you on the next DevOps Chat.

    — Alan Shimel