devopsy.kinsta.cloud

Category: DevOps Chats

  • 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: How Cyxtera Uses DevOps to make AppGate SDP Better

    DevOps Chat: How Cyxtera Uses DevOps to make AppGate SDP Better

    In this DevOps Chat, we speak with Kurt Glazemakers of Cyxtera. Kurt is the CTO of the Software Defined Perimeter group within the security and analytics group at Cyxtera. Kurt discusses how his group uses a DevOps approach to making AppGate SDP better and how that, in turn, makes it better for DevSecOps-enabled organizations.

    In case you are unfamiliar with Cyxtera, it is the company that resulted from the acquisition of 57 data centers and the co-location business of CenturyLink (which then used that money to complete its acquisition of Level 3), plus the acquisitions of Cryptzone, Catbird, Easy Solutions and Brainspace. The company brands itself as the “secure infrastructure company” and is now one of the leading co-location players globally. Managed by most of the former senior management team at Terremark, which itself was acquired by Verizon (Oh, what a tangled web we weave in the tech world), Cyxtera is now something like a $2.8 billion business.

    During our chat, Kurt gives us some great insight into how DevOps, automation and CI/CD have helped make Cyxtera’s product better. As usual, the streaming media of our conversation is below, followed by the transcript.

    Audio

    Transcript

    Alan Shimel: Hi, everyone, it’s Alan Shimel and you’re listening to another DevOps Chat. Today’s DevOps Chat has a distinctly DevSecOps/security bent to it, and I’d first of all like to welcome my guest, Kurt Glazemakers of Cyxtera. Kurt, welcome to DevOps Chat.

    Kurt Glazemakers: Hey, Alan. Hi.

    Shimel: Thanks for being here, Kurt. So Kurt, let’s start off with this first. What’s your title over at Cyxtera?

    Glazemakers: I’m the CTO for our Secure Access product families, so I’m basically managing the whole development themes and the product for our Secure Access product family in Cyxtera.

    Shimel: Excellent. And among the Secure Access products that Cyxtera is offering is something called AppGate.

    Glazemakers: Yes, that’s correct. 

    Shimel: Give our audience a little background. What’s AppGate about?

    Glazemakers: So AppGate is a tool that’s based on some of the fundamental principles of zero trust, to provide clients, wherever they are – in the office, in the airport, maybe in a Starbucks – secure access to their core applications and in such a way that the applications are securely accessed wherever you are and from whatever device you have. That’s basically in a nutshell what it does. It _____ a wide network _____.

    Shimel: Got it. And Kurt, you know, bigger picture, Cyxtera, give me if you can, our listeners a little background there.

    Glazemakers: Well yeah, sure. So Cyxtera is pretty new in the market. We’ve existed exactly one year and 25 days today, so it’s pretty new. And it’s an acquisition of 57 data centers that we acquired from CenturyLink, and where we added security software in order to provide secure _____ and hosting _____ _____ .

    Shimel: Excellent, excellent. So is AppGate – I imagine it’s not offered just to your datacenter customers, or is it?

    Glazemakers: No, actually AppGate came from one of those software acquisition teams, so we actually are widespread. We have widespread customers all over the world, actually. But most of the data center customers have a need for it, because they need to access their own data center _____ _____ requirements. Maybe they have access needs in the cloud, like the _____ clouds of this world, like the 80S or the ____ of this world. And with AppGate you can actually accommodate all of them with one solution. And with our footprint in the data center we can even offer it as a secure access service to our customers. So that’s a combination of the software and the data center footprint, which makes it very interesting from that perspective.

    Shimel: Got it. So we’ve got the groundwork laid, Kurt. Let us now jump into what you and I really want to talk about, and that is that, you know, Cyxtera and the AppGate team have been on their own DevOps journey, their own DevOps transformation in how you’re actually developing and continue to develop AppGate as a product. And what’s really kind of unique about it – it’s like one of those Russian dolls where it’s a doll within a doll within a doll – is you’re using DevOps to help develop a product that helps DevOps. Right? Other DevOps _____.

    Glazemakers: Yes, that’s actually correct.

    Shimel: Tell us.

    Glazemakers: Yeah, so what AppGate basically does, it provides secure access to applications, but the applications are dynamically discovered and added to the network, which is a real DevOps case, right? If you spin up an environment and you want to connect to that environment, even if it’s only lost for like a few minutes, AppGate is able to detect that and basically provide access in the moment that the environment is live. And when it’s gone, all of the access rules are gone as well. So it is nakedly a DevOps-driven security technology, which helps a lot of or actually most of our customers already in a public cloud or DevOps style of company, as a majority. Also we have enterprise customers, but this has actually been very well adopted in the DevOps _____. Yeah, so it definitely is a doll in a doll from that perspective, for sure.

    If I go back to where we started, I started these tools about four years ago. And the reason why DevOps for us was so important is, first of all, it’s a network security product, which is very, very complicated in testing, because it requires a lot of security skills, a lot of networking skills and also software testing skills, which makes it very hard to basically perform the amount of testing in _____ hours, to give quick feedback to the user side or to the developer, in this case. So one of the things we’ve done in the very first place is we really spend a lot of time on creating our own tools, and that actually took even more than a year or a year and a half, to transform what, at the time when I entered the organization, was a more traditional way of developing with a developing process, a QA process, a delivery process. And that process was too slow and didn’t get or give the right outcomes.

    So the first thing we’ve done – we spent about one and a half years on only developing the automations and the DevOps _____ _____ case. So yes, that’s where we spent a lot of time and actually that’s also helped us in gaining a lot of efficiency in the dev team after _____ _____ _____ in this case.

    Shimel: Excellent. So Kurt, you know, we’ve spoken to several – more than several. We’ve spoken to a lot of organizations that have kind of undergone their DevOps transformation. If you can, share with our audience, how did this come about? Was it top-down, bottom-up, middle-out? You know, whose bright idea was it to do DevOps here?

    Glazemakers: Yeah, okay. I think you need actually a little bit of both, right? So when I entered the company, I had some experience in the past and I really wanted to bring it to the same level, because first of all, the QA profiles are very hard to find and they don’t have the same throughput than if you do it in a proper DevOps way. So I definitely wanted to put guidelines in here, but you cannot do it if you don’t have buy-in from your own devs right now. And these devs were immediately onboard and we started actually as a _____. So basically I would say this is a top-down and a bottom-up approach at the same time.

    But that definitely brings challenges, because if you go from a traditional way to a new way, it means that certain people probably will not be a fit in the reorganization, right? So if you have too many people that have never been a coder, that actually brings challenges on their skillsets. So that was not the easiest way to progress in the organization, but once everyone saw the benefits, I think we really shifted from a traditional-driven organization to a full DevOps and really a _____ _____ _____ organization. We did it in that year and a half I was talking about. So yes, that’s the guideline. But you need buy-in from both your developers as well as the management team, in this case.

    Shimel: Excellent. And now, Kurt, since you’ve moved to a DevOps sort of framework here, have you guys done any sort of ROI or any sort of analysis as to what – I mean, because one of the things that we always see with DevOps is it just feels that it’s better, right? We’re doing it faster; quality seems a little higher. But have you actually done any benchmarks or metrics that really get to that?

    Glazemakers: Yeah, that’s actually a very good question. Actually it’s always hard to measure exact benchmarks, but if you look from an overall perspective, before, we were literally doing maybe one release every year, and that shifted almost to a multi-year release when this was adopted, which is a huge difference in this case. And the way we release is typically we have some quarterly release that contains all of the new features and then a monthly release which contains smaller fixes and patches. But what the biggest outcome was for us in this case is, by having a quarterly release and these smaller releases, it’s very easy to follow up with your customers on requirements.

    Especially in the beginning when AppGate was the complete new concept. So it’s _____ _____ _____, and you need to convince customers. At that very, very early stage, “Yes, it’s great, but I need this feature or whatever before I can work.” And if you can actually deliver that by the end of the quarter and even prove to the customer it actually works, that definitely helps driving sales and getting the numbers in, in the quarter. So I would say from that perspective it’s not only about releases but the fact that we were so dynamic and were able to convince customers. To inject a last missing feature before they could sign a deal is probably the most visible item that even _____ _____ _____ by sales or management. Because you are actually fulfilling needs from a customer at a much faster pace in each case, which results in better financial results and more happy customers as well 

    Shimel: Excellent. Excellent. So what’s been the feedback? You know, as you said, it makes for happier customers and everything else, but let’s concentrate on your own internal development team. What’s the feedback been from them?

    Glazemakers: In the beginning, a little bit skeptical, because you need to do all this move and the work and also you don’t involve the right group files. The nice thing is, what happened is, when they start to see the power of a properly-done DevOps file – and actually we have a little bit of a benefit with our product, because we’re not only leveraging DevOps as the _____ _____, making sure that we have all of these automated tests _____ _____ feedback, but we’re also using always our latest code base to basically upload the codes and to work with it. So even the code right now, I’m actually using the latest version at this moment, through a secure _____, to basically provide _____ _____. So you see that you immediately get feedback from that perspective.

    So the first thing that we really saw beneficial for the devs is that they get very, very quickly feedback, to see how the software performs. But secondly, also when we were _____ _____ the organization – you get a lot of new talent in and the new talent is typically a little bit shyer, because if they commit something and it breaks a process, then you get – that’s not how you want to start in a new company. And with this DevOps style, where people cannot commit code before it went to the test _____ and before it can be merged and all of those things, you have first of all a very strong development process, which is not followed by developers, because they hardly feel there’s any process. And so it gives the developer at the same time a lot of freedom and a lot of trust in whatever code they produce.

    And those three elements are incredibly key to raising the amount of efficiency, because people are not blocked because someone has entered the wrong code that actually breaks the builds. We have a lot more freedom to basically optimize or _____ _____ certain codes in the products. And last but not least, also from a security perspective, you need very, very tough certification sometimes, even if you are producing for government agencies and those kind of things. And that automation also provides a lot of feedback there, positive feedback, for the certification process, because everything is automated and enforced by the DevOps system as well in this case. 

    Shimel: Mm-hmm, excellent. So Kurt, I told you the time goes so fast. We’re almost out of time. But I wanted to talk a little bit about the other side of the house, which is, how are customers using this to help their own DevOps initiatives and their own DevOps development and deployments?

    Glazemakers: Yeah. Yeah, that’s actually a very good question. Yeah, what you have with DevOps environments is, when you’re deploying in DevOps environments, you basically always typically want to deploy and actually forget about it, unless there is an issue when you want to go in. And this is typically administrative access for the development outside the system. And in a real production environment, in a DevOps environment, you really, really want to have strict, strict controls of that. And we have a lot of customers, for example, that maybe _____ _____ _____ that actually have this kind of discipline. And what we were able to provide was when they – even when it’s their own dev environment and they test, or if it’s a production environment, we can actually enforce different layers of access in this case. Maybe for the public environments you need two-factor application and a company-approved device in this case, or a security device that has all of the endpoint protection software and stuff like that running. And maybe for the DevOps environment itself, where all they’re doing is pre-tests, we might be a little bit less restricted. So normally like a normal device, “Okay, it’s just _____ _____,” and you’re able to access without – with just login and password, as an example.

    The nice thing is, what our software does, it can actually provide both of these things at the same time. And also, when the environment is being sped up, the metadata that you provide by creating the environment can be used as the security mechanism. And this is really where we bring a lot of value for customers. Because if you have a DevOps environment that changes all of the time – changes IP addresses, changes operating systems and all of those things – even if they’re lost for maybe 10 or 15 minutes, we can automatically detect those and be able to provide _____ _____ if needed. If they have an open ticket or whatever, we can all combine those elements. And once that is received, we also have a proper _____, the records for which developer has access with the system, even if the system doesn’t exist anymore.

    And that has been a great value for DevOps, especially in the financial world where DevOps becomes now _____ _____ _____ interesting. Financials are seeing the need that they need to develop at a higher pace, so they’re embracing DevOps. But at the same time they are very, very highly regulated, and that doesn’t change. And what we can do with our software is really provide the same or even sometimes better control of these regulations at the same time they keep their agility on the DevOps process _____ _____ _____.

    Shimel: Got it, got it. So Kurt, as I mentioned, time does go fast. We’re running out here. But just last question – what’s the future look like with this?

    Glazemakers: Well I have no idea what it will look like, but the way I see the adoption right now, the way I see the need for DevOps and actually the DevOps embraced in many companies these days, I’m pretty sure that the old way of securing clouds or virtual environments, using a primitive _____ defense or _____ _____, it’s too dynamic ______. There are too many hacks going around. And so from our approach, I would say this is definitely a completely new way of securing DevOps environments and, they’re also the first signs of _____ DevOps are on the horizon right now. And this is a fit. I think the first product that really takes into account whatever security _____ _____ _____ DevOps environments is immediately enforced on the network, all the way down to the user device. And that basically extends whatever you’re programming in your DevOps environments, to make sure it’s always secured down to the device of the user itself.

    And I think that is going to be a huge driver of better security, but also in a much more dynamic security type of approach, which – DevOps has done a lot of great work on deployment and infrastructure. The network and security elements didn’t go as fast, and I think this is probably one of the next new waves that will drive that and maybe be even more secure than traditional environments using the dynamic approach _____ _____

    Shimel: Okay. Excellent. Well, that was a great kind of insight, Kurt. I appreciate it. We’ll be looking – you know, a year? What did you say, a year and 30 days or so?

    Glazemakers: Yes, that’s exactly – a year and 25 days. That’s how old Cyxtera is right now.

    Shimel: Well, continued success and we’ll be watching Cyxtera’s growth. Thanks for being our guest today on DevOps Chat, and we hope to have you back on again soon.

    Glazemakers: Thank you very much as well, and have a great day. 

    Shimel: All right, Kurt Glazemakers, CTO for Secure Access for Cyxtera joining us today. This is Alan Shimel, and you’ve just listened to another DevOps Chat. Have a great day.

    — Alan Shimel

  • DevOps Chat: SRE w/ Stig Sorensen of Bloomberg

    DevOps Chat: SRE w/ Stig Sorensen of Bloomberg

    Many people say that site reliability engineering (SRE) is “putting the Ops in DevOps.” In this DevOps Chat, we speak with Stig Sorensen of Bloomberg’s SRE team. Stig tells us how SRE is helping Bloomberg keep pace with the fast moving world of news and information.

    Great discussion with a real-life practitioner about how SRE is being deployed in a real-world company. As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Audio

    Transcript

    Alan Shimel: Hey, everyone. It’s Alan Shimel and you’re listening to another DevOps Chat. We’ve got a really good DevOps Chat lined up today on a really hot topic, and it’s SRE, site reliability engineering. And my guest is Stig Sorensen, who heads up – a member of the SRE team over at Bloomberg. Stig, welcome to DevOps Chat. 

    Stig Sorensen: Thank you very much. I’m glad to be on.  

    Shimel: So let’s get formalities out of the way. Stig, give our people your title and background here so that we can get started.  

    Sorensen: Okay, so my name is Stig Sorensen. I am the manager of the production visibility group at Bloomberg, responsible for building our CMDB tools and also building telemetry assay as a platform. I’m also one of the main evangelists for rolling out SRE as a role and as a – a new movement across Bloomberg. 

    Shimel: And Bloomberg is, of course, no small company, so rolling out this new role, this new way of looking at Ops and so forth, is – is of course not a – you know, it’s not something we should take lightly or think it’s easy. 

    Sorensen: Well, that’s very true. It’s – across our 5,000 engineers, it’s – that supports everything from our commercial website to – to market data feeds, to obviously our main product, the Bloomberg Professional Terminal which hundreds of thousands of the key influents around the world rely on. And, with various states and various different tech stacks, it’s actually quite – quite a challenge. 

    Shimel: Excellent. So, so Stig, why SRE, why now at Bloomberg? 

    Sorensen: So SRE in, like, what we do isn’t really new to Bloomberg. It’s always been sort of the engineers that own production and sort of own the – the availability of production, and own the process around it.

    What we’re sort of trying to do now is sort of really more divide the responsibility between the application engineers and the SREs such that we can have people that are experts on – either of them, but it’s sort of unfair in today’s complex world for everyone to know everything from how a – how an instrument trades on the street to figuring out how to – how to run and manage a high availability system. Right? So it’s more fitting it into infrastructure and making people experts. 

    Shimel: So an interesting point you bring up, Stig, and you said, we’ve always been doing this kind of thing. And it’s true. A lot of what we now today are calling SRE isn’t necessarily brand new in terms of task and responsibility. It – it may be there’s more of the packaging and some of that mixed in.

    When – when did Bloomberg, let’s say, start referring to this role, to this, you know, needs as, you know, quote/unquote “SRE”? 

    Sorensen: So we sort of started small about two years ago and it’s really sort of – really caught fire in, I would say, the last year where we really made it sort of a more firm-wide. It’s always been pockets of where it’s sort of been done, but then we really, like, part of the puzzle is really sort of internal branding as well in terms of labeling the – not labeling the people, but identifying who is there creating the right environment for these people to learn, to share ideas. Right?

    I think, as you said, the – it’s not necessarily the new thing to do. What’s new for us is sort of really trying to do it in a more – more standard way and a more persistent way across the – across the firm. 

    Shimel: Yep. So Stig, you know, 5,000 engineers. How many are, you know, quote/unquote “on the SRE team”? 

    Sorensen: So they – we don’t actually have a centralized SRE team today. We sort of rolled it out in a way where we aligned the SRE teams with the application teams. The reason for that is really a lot of – in order for the SRE teams to be successful, the applications also have to change. Sort of separating the responsibility too far away makes that harder.

    So we sort of put them parallel, side-by-side, two equal teams with the different responsibilities and – and that’s really sort of how we kick start the teams. Most of the SRE – a lot – quite a few of the SRE teams are seeded from – from the application teams and a lot of, like, the – the core infrastructure teams and so on.

    So all-in-all we have about 75 people that are in sort of the – in the sort of teams that we have sort of – the teams that are SRE teams. As I said, we have a lot more people doing it across the firm, but they’re doing it as a part-time – part-time job. 

    Shimel: Got it. And so Stig, you know, SRE – this concept of an SRE – as you said, though they – we’ve been doing these kinds of things forever, the idea of calling them SRE and labeling them as such is relatively new.

    Is there any particular training or skill sets that you’re asking people to – to make sure they’re, you know, proficient in in order to be quote/unquote “an SRE”? 

    Sorensen: That – I think – I think sort of – the answer is that we are hiring and we’re trying to hire many, many more. They sort of come from two different camps. It’s either people within operational or system admin background that’s sort of picked up programming and moving that way, or we have application engineers with an – with a more active view towards systems and towards availability – because we see SREs as software engineers just doing something – building a different type of software.

    And I sort of jokingly tried to sort of classify SREs versus application developers in a way, sort of – I see application developers as inherently optimistic, they think everything will work all the time, and SREs are sort of the opposite, they think everything will break all the time. And that sort of relates – I think it’s more of a mindset than necessarily the skills. Skills you can always learn. And then I think some – as long as you have the right mindset, the right aptitude to do it, that – well, that’s what’s key to us. Right?

    And I think there is – I think there’s way more SRE jobs than actually people that have done SRE before out there now. So we can’t go out and try to hire the – the ready SRE. We need to figure out how we get smart people with the right aptitude and training them.

    And people mention training, we sort of try to do it in sort of like a lot of meet-ups, a lot of sort of internal meet-ups, external meet-ups, attending conferences to figure out what’s happening in industry, talking at conferences such that we also show what we’re doing.

    And I think it’s – I think it’s really sort of a lot of on-the-job training, working with the application team, working with other SRE teams, and you realize that you’re not alone. There’s always – there’s always someone doing something very similar to you. You don’t need to invent the wheel every single time.  

    Shimel: Yeah, and Stig, we should not underestimate the importance of what you just said there. With a new field like SRE – and we saw this in DevOps, early on in DevOps – because there’s no sort of codified best practices, right? There’s the book from the Google team, and there’s other stuff coming out now but there really isn’t a – a best practices. There’s emerging practices. And so the idea of peer-to-peer sharing and – shared learning is – is really important to continue advancing, you know, the state of the art, if you will.

    In addition to my DevOps dot com duties, I’m also one of the co-founders of DevOps Institute and this is exactly what we – the fact pattern that we saw in DevOps. And it’s the same fact pattern we’re seeing in SRE and frankly it’s one of the reasons why we are working, and expect to have out soon, an SRE course that kind of starts, you know, pulling together all of these emerging practices and having a common body of knowledge around it. 

    Sorensen: I think that’s great, that – that we’re sort of trying to standardize these things, but – because a lot of it also becomes sort of – you have to be flexible when you roll it out because not every application or every system can be rolled out – can – can get an SRE team and roll out in the same way because there – there’s different maturity of the systems, there’s different problems. Right?

    Like, in terms of, like, do you focus on monitoring and a production environment or do you focus on more sort of the classic DevOps things and how you get things into production. Like, you really have to look at it from a holistic point of view. The goal of the SRE team is to improve availability of production. There’s multiple ways to do it. You could pick one and make it better, you’d probably – you’d probably improve it. Right?

    And the – thinking – like, it has to do everything to make a difference is also probably not the right thing to think about. 

    Shimel: Yeah. Absolutely. So, Stig, let me – let me kind of pivot here a little bit and let’s talk about – what’s in it for Bloomberg with SRE? Why are they supporting you? 

    Sorensen: Well they – it’s – I think it’s really just looking at the services we provide. Right? Like, we’re providing real-time financial information to 300,000 of the most influential people around the world and it’s not really just about availability, it’s also about performance and latency of this – the data going around the world. Right? We – we process something – what, like 100 billion market data picks a day and one-and-a-half million news stories a day. Right? So it’s – so in order to keep all these pipelines going, it is actually quite a big job. Right? And I think just – just making sure that we are available and don’t influence the financial markets by not being there. 

    Shimel: Yeah. I mean, that – you know, and that brings home the, you know, we’re not – sorry, Bloomberg doesn’t sell widgets that no-one cares about. Downtime and performance there is – is, you know, teamed up or, you know, ingrained with financial market performance and reporting. You can’t afford – you can’t afford downtime. You can’t afford, kind of, mess-ups.

    But Stig, we spoke a little off-mic about this and it’s a topic I want to bring up is, you know, at Bloomberg, you guys have been doing this SRE thing now and you think it – you’re making progress and it’s good, but we really haven’t done any sort of formal ROI analysis or, you know, similar type of work. Correct? 

    Sorensen: Yeah, no – that’s very true. It’s – it’s probably one of the biggest challenge in terms of, we have support and everyone believes it’s the right thing to do. You have the gut feel that this is – we have to do this to make it better or to be – or to keep the service going we’ve always had.

    But I think it’s sort of a – for us it’s – for us, like, measuring – _____ measuring availability is actually not black and white. It’s not like, how many – how many failures you had on a website. Right? Because if you are a certain market player and the real-time market data is delayed by a few – by one millisecond or hundreds of milliseconds, it could make a big difference for you. Right? And it’s – is that complete failure or partial failure? And, sort of, all these things in between.

    It’s sort of something we’re – we’re really working on to try to define better metrics around it such that we can track our progress effectively to see if – if we had – if we – if we are succeeding. It’s – if you go by the gut feel, it only lasts so long but at some point you need to really ask yourself, you need to make sure that the return is there 

    Shimel: Absolutely. Stig, I mean, and let’s be clear. This is not a Bloomberg issue at all. I – you know, we haven’t really seen it across the board yet. You know, formal ROI type of analyses for SRE, but as you said, it – you know, it obviously makes sense or, you know, logical to think that it’s good for – for organizations and I think this is why we’re seeing so many organizations starting to adopt this.

    Another thing I wanted to touch on, though, Stig, was the idea of, again, paralleling the DevOps experience, originally everyone said, oh, DevOps is great for unicorns. It’s great for Google, it’s great for Facebook, it’s great for the Twitters of the world, but it doesn’t really work on the horses. Right? On the just regular, large enterprises.

    SRE, well, yeah, that’s a Google thing and it’s great for Google but is it going to work for Bloomberg. Right? Or similar kinds of things. And, you know, you’re living proof, if you will. But every road, Stig, there’s – it’s – you know, I call it the DevOps cha-cha. It’s never linear, one step in front of the other and it’s just, you know, smooth sailing. There’s always a failure here, a lesson learned here, a step back, two steps forward, one-two, one-two-three.

    Give us, you know, I’m sure you could give us plenty of successes. Give us a failure or two that you guys really learned from. Lessons learned. 

    Sorensen: Cool, yes, it’s – I think sort of in – the lesson learned in failure of the transformation was really, I think – some of the teams that was – that was labeled SRE was given too much operational work such that they didn’t necessarily have enough bandwidth to get themselves out of the quagmire they were in. And that sort of created, like, a new pattern in terms of that, like, SREs are operations, and they’re not. SREs are developers. But developing things to get rid of operations work, but if you don’t have time to develop, you’re never going to get out of it.

    So I think that’s probably about the biggest lesson learned in terms of – in terms of the building the culture and getting sort of the – the optics to be right internally. And sort of in the same way, I mean, sort of like, it was also, sort of, SREs within the application teams and not having dedicated teams was also quite a – sort of an anti-pattern that we saw a bit where it’s easier to steal the SRE’s time to do application work. And then again, we don’t actually move forward. So the – so that’s sort of probably the biggest failure.

    I think also we need to make sure that we have a good set of base tools and base things that – that can be shared between the teams such that _____ everyone needs to – needs to build everything from the ground up. And we probably – we probably started sort of in silos where sort of parallel things were built but it improved. It improved – it improved the production quality but it didn’t necessarily make us go faster in terms of rolling out SRE and so it – we sort of had to step back and sort of standardize a bit more of tools and make sure we had central ownership of some of these tools rather than individual teams owning them. 

    Shimel: Excellent. Stig, we’re coming up on the end of our time here. I wanted to kind of just ask you, so, you know good progress, off to a heck of a start, a fine beginning. Where do you see the future of SRE at Bloomberg specifically and in the greater market, let’s say, if you had a crystal ball, over the next three to five years? 

    Sorensen: I think – I think internally here, right, like we’re – we’re trying to grow significantly so for us to just be able to – to both convert people internally from an application to an SRE and also hire the people.

    And I would hope for us and for larger companies like us where there’s a transformation, that it becomes – becomes more standardized such that we can have a centralized org that is the SRE org, and have sort of more of a – where we can – where we can scale – scale and support more teams whereas now it’s really one-to-one and – not necessarily one-to-one in terms of people but one-to-one in terms of teams.

    And I would hope the industry in general also starts to think about the people that do not run on the big cloud providers and sort of actually own everything from the ground up, like us, and I would hope that more companies that are like us get into this such that –

    [Inaudible due to radio noise]

    – that it would be more pools and more things to support us. Right? 

    Shimel: Sure. Sure. Well, Stig Sorensen of the SRE team at Bloomberg, I want to thank you for being our guest on today’s DevOps Chat, and, you know, this is really – this whole SRE thing is certainly an area where we are watching closely. Maybe we could have you back on in a couple months and get an update. 

    Sorensen: I would love to, that would be great. 

    Shimel: All right. Stig, thanks again. This is Alan Shimel for DevOps dot com and you’ve just listened to another DevOps Chat. Have a great day, everyone. 

    — Alan Shimel

  • DevOps Chat: Post-DOES Workshop w/ Gary Gruver & Helen Beal

    DevOps Chat: Post-DOES Workshop w/ Gary Gruver & Helen Beal

    Post-DOES WorkshopGene Kim’s DevOps Enterprise Summit UK is just a few weeks away, June 25-26. While DOES UK this year is shaping up to be a must-see event, there are also some great events taking place around DOES. One is sponsored by Electric Cloud (also a founding sponsor of DOES). It is a post-DOES workshop, featuring classes taught by Gary Gruver, John Willis and Helen Beal.

    The workshop session lineup includes “DevSecOps,” by John Willis, “Leading the DeOps Transformation,” by Gary Gruver and “DevOps Essentials,” with Helen Beal. Helen’s DevOps essentials and Gary’s executive leader workshops are both half-days, so you can attend both. Each of these are great learning events as well as a great way to network with your peers. If you are in London on June 27, be sure to check them out.

    As usual, immediately below is the streaming audio of our conversation, followed by a transcript so you can follow along.

    Audio

    Transcript

    Alan Shimel: Hey everyone, it’s Alan Shimel and you’re listening to a special edition of DevOps Chat. We have three folks on our panel for DevOps Chat today, and each one of them, actually, are really kind of special people to me within the DevOps community. And let me introduce them to you right off. First and foremost, ladies first.

    I want to introduce Helen Beal. Helen of course is DevOps fantastic at Ranger Four. But also, Helen was one of the first people I met in the DevOps community over in London and has been a friend ever since. Also has a position with the DevOps institute – an advisory role at DevOps institute as well. So Helen, welcome to DevOps cChat.

    Helen Beal: Thank you very much, it’s a pleasure to be here as always talking to you.

    Shimel: Thank you. My second guest really needs to introduction in the DevOps community. He has three – count them, one, two, three books around DevOps as well as many years of leading DevOps teams at HP and Macy’s and now consulting for many, many different organizations and helping them with their digital transformations and DevOps journeys, none other than Gary Gruver. Gary, welcome.

    Gary Gruver: Hi, thanks great to be here, nice to be speaking with you again.

    Shimel: Nice to have you here. And then certainly, last but not least – one of my good friends in the DevOps world, he runs marketing at Electric Cloud, which is also of course the founding partner of the DevOps enterprise summit (DOES) with Gene Kim and ITREV– Sam Fell. Sam, welcome.

    Sam Fell: Thank you, Alan. Happy to be here.

    Shimel: Okay, first thing I want to talk about today is we’re getting close to DOES London, which I believe is what? June 25 and 25 over at the O2 in London.

    And I know you’ll all be attending there and of course we can – Electric Cloud is again one of the founding sponsors and we can get all that information over on the IT revolution site. But part and parcel with Does London this year, I wanted to mention two special events taking place on the heels of Does London.

    One is a special post-Does workshop which, Sam, you and the Electric Cloud folks have driven. Why don’t you give us a little background here on what you guys are doing and why?

    Fell: Yeah, great – thanks, Alan, I appreciate that. So Gary – you mentioned, he has had all this experience helping these large  companies with their digital transformations. When we started our user conference back in 2013, Gene Kim came and spoke, Jez Humble came and spoke.

    And we were talking together, we said these are exactly the kind of people – these old horses that are trying to do these transformations that we want to try and attract to a large conference, which is sort of what the genesis of the DevOps enterprise summit. The folks that show up at that show, a lot of them are in a tough spot.

    They know they need to transform. Their business wants them to transform, they don’t know how to go about doing it. And so having a community of people that are available to talk to and learn from, admit mistakes to in a safe way, to know that you’re gonna get advice and counsel, it’s a fantastic show that the team has put together. And you can see by the success of it that the community really embraces it.

    So our thought last year with Gary was why don’t we take somebody who has helped companies with these transformations and go to DevOps enterprise summit and listen to those stories and see what people are going through and then directly after that you get in a room with an expert coach who can say, now, let’s apply that to you. Let’s apply that to your situation. All those stories that you’ve heard, how does that work for you?

    And last year we had just a fantastic time and so we decided to do the same thing this year at Does London. We’ll be doing the same thing at Does Los Vegas in October as well. And it’s just an opportunity for people to really put in practice and make real a lot of the things that they heard at the fantastic DevOps Enterprise Summit.

    Shimel: Fantastic, Sam. And it is, it’s a great workshop. Gary and Helen – before I jump over to you, Sam – I forget I apologize. For people to register for the workshop, what’s the cause? What’s involved? Where do they go?

    Fell: So it’s a heavily subsidized workshop. Helen, the DevOps institute, Gary, John Willis – these guys are giving their time in order to provide this for the community. Electric Cloud is helping to pay for the room and all this other stuff. So the cost is pretty minimal. I think it’s £195.00 for our early bird.

    We don’t have that many tickets eft but there are some tickets. There’s a group rate as well. So you know, non-expensive and it’s an opportunity for you to really rub elbows with people who are always wanting to learn how to do these types of things. And as you mentioned, John, we do have these couple different workshops.

    John Willis is doing Dev-Sec-Ops hands on technical workshop that same day. So we’ve got two tracks that we’ve got set up basically. I don’t want to spill the beans on what Helen and Gary are going to be talking about, but the John Willis workshop  we’re really excited about that. He’s gonna be showing people with a live pipeline how to incrementally improve it. how to bake security into your deployment pipelines.

    And one of the types of things that you can do to enable your teams and your developers to ship secure codes. Fantastic stuff.

    Shimel: Yeah, no, that’s gonna be a great hands on workshop for anyone interested in DevSecOps. We’ll have more info about DevSecOps in a little bit. But first, let’s turn to Gary. Gary – what is your workshop going to be about here?

    Gruver: I think I’m gonna follow your lead. Let’s go with Helen’s first with lady’s first and get to that and I think that’s the order that we’re going in with the day. Why don’t you lead off with Helen and then I’ll follow up.

    Shimel: Chivalry is not dead. Helen – go ahead.

    Beal: Thanks, Gary. So I’m going to be doing the half day DevOps institute course – the essentials of DevOps which essentially kind of what it says on the tin, the fundamentals or the foundation and relevance of DevOps and things like the three ways and coms and how it fits with Agile and IT send and Lean, PK studies, linking it to this integration.

    And continuous delivery. How they lead from one another. So that’s it. It’s a course really for people that are quite new to DevOps and they should expect to leave the course, really with an understanding of where DevOps has come from, why it’s important and what sort of business benefits people can anticipate from using DevOps practice and principles.

    Understanding some of the vocabulary that those of us that kind of live and breathe DevOps are quite familiar with. So things like the theory of constraints and CD and things like that and hopefully with some kind of action plan of what they can take back to their desk the next day and start making some DevOps differences in their own organization.

    Shimel: And it is the DevOps essentials course it’s really sort of a big time version of the full DevOps foundation, which Helen – you were instrumental in refreshing for this latest– I think it’s released three of DevOps foundation?

    Beal: Yeah, it’s very nearly ready. So it’s been updated with lots of additional case studies, we’ve updated things like the surveys too, the latest versions of the state of DevOps surveys. I know there’s another one coming out. I don’t think we’re expecting it for another few months, and actually part of what we’ve been doing this update is following our own principles. So we’re actually aiming for a much more incremental release cycle as we move forwards rather than in frequent big updates.

    I’m sure we’ll all be on board with that. And then, newer things have been coming through like liability engineering and more stuff around services and containers and those sort of things. Focused on safety culture, learning organizations and some of the things that John and Gene can cover in their beyond the finished product audiobook, also featured in there.

    As is some of the material from Nicole’s and Jane’s book – accelerate. And some references to that. And then we’ve removed some of the stuff that kind of isn’t really around anymore in the DevOps World.

    So things like NoOps – think it’s really gone away now. Rocket DevOps has been very overtaken by DevSecOps. So it’s a good solid refresh and hopefully the foundation will be able to keep refreshing it more frequently as this is such a fast changing world that we’re in – this DevOps world.

    Shimel: It certainly is. Okay, that’s fantastic Helen. And I encourage listeners that may be in the London area that week, if you’re near to DevOps or you really haven’t taken any formal DevOps sort of education or classes, you know, listening – goes to Does is a great way to learn from real life examples. But really this is a great class to give you a nice foundation in DevOps. Gary, how about you?

    Gruver: I’ll be doing my executive workshop that I do with most organizations when I go in and work with the executives to really help people put together their plans and figure out how do they approach it. The people that are gonna be at. Does are gonna be hearing a lot of different ideas, and a lot of perspectives on what they should be doing and I’ll hopefully be trying to help them put that in context.

    My big thing I champion is there are different approaches you need to use when you’ve got large tightly coupled systems than you do when you have small teams that can independently develop and qualify and deploy code. We’ll be going through a lot of those differences. We’ll be going through the role of the executive in terms of leading the transformation.

    A lot of this can be empowered if you have loosely coupled small teams but if you’ve got large groups of people who have to work together to coordinate the deployment pipeline in terms of being able to develop, qualify and release as a system, then you need to have the executives playing a pretty active role in coordinating the work across those teams and prioritizing the improvement. So we’ll be going through that.

    How do executives get the team all on the same page? And then how do you get them to a common definition of what they’re gonna go do and agree to that? So my analogy is a pipeline ____ described an elephant feels like most discussions I start with organizations that are starting to go down their DevOps transformation.

    And what I work to is a process and approach to give them a common view of the elephant and get people all rowing in the same direction. And helping people understand that the types of things they can and should do are different for large, tightly coupled systems versus loosely coupled systems. And then we’ll go through and we’ll help them understand where they should really be starting their transformation.

    Which is different for a lot of different organizations. And I feel that starting point is really important, because this is a lot of energy. It’s gonna take a lot of effort to transform how you do software development.

    And you really want to pick the changes that are gonna have the biggest impact on your business first off so you can create that positive momentum. I think if you just go down the path of doing DevOps without picking those things that will have the biggest impact, you’ll start doing it, you won’t see the benefits, and over time the organization will kind of disengage and you’ll lose momentum on your transformation.

    So a lot of what we focus on is trying to highlight those key lynchpins that you can really start making the big differences and how to go analyze that for different deployment pipelines in your organization.

    So it’s really that. I’ll be there. But there will also be a lot of your peers in the room. So it’ll be a good opportunity to take the things that you learned at Does to reflect on them and talk with myself and your peers about what you’re thinking about doing.

    And learning from it. And I would say that I’ve been doing this for a long time, and what I tell people is that just gives me more opportunities to have made the mistakes that you’re gonna make.

    And so if I can help you avoid the mistakes I already made so you can go make some new ones, learn from that, that’s kind of my goal. My experience is this stuff is such a breakthrough for the business that we’ve gotta have more people doing it. But how can we help people best we can so they realize those same benefits.

    Shimel: Excellent. Gary – you know, one of the things I think sometimes people get confused or question is when we talk about this is aimed at executives. It’s sort of a loaded term. In a large organization like a Macy’s, executive might mean CIO, it might mean VP of IT. in other organizations it may mean a director level. Can you give us a better definition or how you define you know, the executive who is gonna get a lot of good out of this workshop?

    Gruver: I think they all will. I’ve done it all the way from the CIO and I do execution workshops down to – to the leaders that are responsible for a tightly coupled deployment pipeline and then some organizations that might be a director or senior manager that’s over development and ideally, it’s nice that you can bring your partners in QA if it’s separate, and in operations if it’s separate. Maybe your security people, maybe your audit people.

    And come together as a team after Does. So if you’ve got a group of people that have gone to it and gone to a lot of different presentations, having them come together on that will be helpful. So this is the group at whatever level in the organization you think will be leading the transformation, or driving the changes. It can be – typically the CIO when I do the executive workshop is more to inform them of their role in it. Then at some level, we get down to a specific deployment pipeline.

    And the deployment pipeline may still be 1000 people if you’ve got a large tightly coupled system, like we had at Macy’s.

    Which requires large numbers of people working together, or it may be small. And if it’s small, you can do a lot of the things that you’ve seen unicorns do. And if it’s larger, the same principles apply but the practices are a little bit different.

    Shimel: Excellent. Yup. Great. So guys, we’ve covered a lot of ground here. Let me do a quick review. Sam, what day is the workshop?

    Fell: The workshop is the day directly after DevOps enterprise summit. Wednesday June 27.

    Shimel: It’s June 27.

    Fell: That’s correct. Right before… DevSecOps days on the 28th!

    Shimel: Yes, and Sam – I will put in our show notes a link to the URL about the workshop and registration. But where is it being held specifically?

    Fell: It’s conveniently located in exactly the same location as the DevOps Enterprise Summit which is the InterContinental – O2 in London. So if you’re in London, very convenient area to get to also. So come on by.

    Shimel: Excellent.

    Gruver: And you don’t have to have gone to DOES or the DevSecOps. If you’re in Europe and you wanted to stop by.

    Shimel: Excellent point. It’s not a pre-req if you’re looking for some good, hands on DevOps training and networking and education, this workshop is a standalone event. It’s fantastic as well. So let’s cover the three different workshops actually being conducted that day though. Number one is we’ve got none other than John Willis himself leading a real hands-on DevSecOps. Is Anders working with John on that one, Sam?

    Fell: Anders will be in there, yeah, he’ll be hanging around. But this is really John’s show. And this is his passion. And he’s driving the technical aspects of this workshop where people are really gonna be able to get their hands dirty with the technology, have a pipeline. Put some vulnerable code through it, and deploy it and then figure out how do we put automated steps in place and how do we sort of put the – get the developers thinking the right way to make sure that that kind of stuff can happen and what are the practices that need to be put in place. So really, for folks who want to try and get that level of specificity of how to do it, not just the high level, interesting, interesting workshop for people.

    Shimel: Absolutely. We’re all hearing a lot about DevSecOps. Gary made reference to DevSecOps. I think Helen did as well. And we talk about this DevSecOps rugged DevOps etc. This is really gonna be hands on. so it’s great whether you’re a DevOps person or a security person. Then we have Helen who is delivering the pre-req 101 DevOps essentials, based on the latest upcoming version of DevOps foundation from the DevOps Institute. And Helen, people who take essentials – do they get any kind of credit or anything towards a foundation or being able to take a certification or anything like that?

    Beal: As you said earlier, it’s basically a cut down version of the DevOps foundation course and that’s a certified course. This isn’t a certified course, so I’m sure if people wanted to follow up with the DevOps foundation, we could sort something out.

    Shimel: Fantastic. And then certainly, last but not least, aimed at DevOps leaders and executives, Gary is gonna be in essence, delivering what many organizations are paying thousands and thousands of dollars for. His course on kind of leading the transformation. That’s taken right from one of your books, Gary. I apologize. But really, dollar for dollar, what a great line up, what a great deal for anyone who is looking for DevOps training and education. I also wanted to quickly before we run out of time here, I wanted to mention that the day after the workshop is the first DevSecOps days in London.

    Again, headlined with John Willis. I think, Helen, you’re speaking there as well. Correct?

    Beal: I am, indeed. Yes.

    Shimel: Give us a little preview, what are you talking about?

    Beal: So John saw a talk I think I did in Belfast or somewhere – maybe last year. It might have been all day DevOps, can’t remember. Anyway. But basically we’ll be talking about DevSecOps engineering as a concept. As you probably know, the DOI at DevOps institute is just about to release a new course for DevSecOps engineering. So we’ll be talking about that role and what the requirements are to be successful in that area.

    Shimel: Yup. And DevSecOps days also promises to be a fantastic day. Sam and the Electric Cloud folks – we’re grateful for your sponsorship. Electric Cloud is one of the sponsors there. I will put in the show notes where you can get more information on DevSecOps days as well. But you can go to DevSecOpsdays.com and that’s the long and short of it right there. Guys, a couple of minutes left, let’s wrap up.

    Helen – beyond all of the great stuff you’re doing with DevOps institute, what any good news? Any new things going on with Ranger Four?

    Beal: One of the nice popular things that we’re doing at the moment is one of my favorite things conveniently as well. Which is our version of Phoenix project simulation game. That we kind of developed with our partner Gaming Works out in Amsterdam. So it’s a one day business simulation so experiential learning rather than classroom learning. We’ve got a free, public version of that coming up in London on the 19th of July. It is quite close to being fully booked.

    But if people want to find me on Linked In or would like to come along, we do have a couple of spaces left.

    Shimel: Excellent. And I’ve done the Phoenix Project simulation game, I love it and I’m sure you guys will deliver a rousing version, highly recommend. Gary, how about you?

    Gruver: Oh, I’m just spending more of my time with individual companies, learning from their journeys and trying to help them avoid the mistakes I’ve made and help them to learn from new mistakes they’re finding so I can help point it out to other people so that people can accelerate their journeys and be more successful. So that’s where I spend most of my time is just coaching different teams that are trying to transform their software development delivery processes.

    Shimel: You know what, Gary – what we should have mentioned though – for maybe folks listening out there who may want to engage your team to help them, where do they get information?

    Gruver: They can just go to garygruther.com – my website. And they can also go there and download a free copy of my latest starting scaling DevOps and enterprise, the electronic copies are there. I self-published that so I can give it away. Authors don’t really make money on books. So it’s out there, so I can give it away.

    If you read the first three chapters and then click at the end, you can get the rest of the chapters if you just give me your name, your title, where you work and where you live so that if I happen to be in the region – I keep thinking I’ll use that as a marketing tool. I haven’t sent anything out to it yet, but I’m still collecting names of the people that read the book because it feels like a good contact for me.

    Shimel: And of course, you’ve updated your privacy regulations to be GDPR. Anyway, Sam let’s see – DOES – you guys are the founding partners of DOES, you’re doing these workshop, you’re helping us with sponsoring DevSecOps days. What are you doing in your spare time?

    Fell: Next week we’re gonna be at Velocity San Jose if anybody is in the area, we’d love to have you stop by and see us. Yeah, we’re just looking forward to seeing everybody out in London. And it’s gonna be a super fun filled week. I mean, it’s a whole week of DevOps. I could not be happier. I’m super excited about it. really appreciate all the work that everybody is doing to try and make this community event a success. And looking forward to being in London.

    Shimel: As am I. I will be at all three of these events as well and you hit it there, Sam. Both the workshop and DevSecOps, these are community events. London has a fantastic DevOps community. Looking for your support, and I think it’s gonna be a great week for DevOps. So with that being said I think we’re about out of time here. Helen – as always it’s a pleasure to hear your voice and have you on the show with us. Look forward to seeing you in person.

    Gary, always a pleasure, my friend. I’m sorry, Helen – I stepped on you there.

    Beal: I was just gonna say, thank you very much for having me on and really looking forward to seeing you guys as well.

    Shimel: Great. Gary – as always, a pleasure.

    Gruver: It’s always a pleasure to get a chance to speak with you, Alan, and look forward to helping out the DevOps community.

    Shimel: Very cool – and Sam, what can I say that hasn’t already been said?

    Fell: I don’t know. You could say “goodbye?”

    Shimel: Okay – in that case, goodbye. This is Alan Shimel. You’ve just listened to another DevOps Chat. See you all in London for DevOps week.

    — Alan Shimel

  • DevOps Chat: The Kitty Hawk Venture & Continuous Testing w/ Aruna Ravichandran

    DevOps Chat: The Kitty Hawk Venture & Continuous Testing w/ Aruna Ravichandran

    A great new book on DevOps is coming out called “The Kitty Hawk Venture.” In the vein of “The Phoenix Project,” it is a novel about one fictional company’s journey specifically with continuous testing. Based on a real-life airline company, the book is great case study and learning experience around continuous testing and its importance to the entire CI/CD and DevOps experience.

    The book is written by Jeff Schaeffer, general manager of the Continuous Testing business unit at CA Technologies; Alex Martin, CTO of Continuous Testing at CA Technologies (and former CTO of Rally Software); and Aruna Ravichandran, vice president of  Gobal Marketing at CA Technologies and author of “DevOps for Digital Leaders.” Beyond the book, there is a companion ebook on continuous testing, as well as other related content.

    In this DevOps Chat, we speak with Aruna, who is a frequent guest on our chats, about the book, continuous testing and the overall DevOps market. It is an excellent chat and, as usual, Aruna’s passion for what she does and DevOps shines through.

    For those not familiar with our DevOps Chats, the streaming audio of our conversation is immediately below, followed by the transcript of our conversation.

    Audio

    Transcript

    Alan Shimel: Hey everyone, it’s Alan Shimel. devopsy.kinsta.cloud. You’re listening to another DevOps chat. This is gonna be a really great chat. I have one of my dear friends in the DevOps industry joining us. Aruna Ravichandran Ravichandran, VP of Marketing DevOps at CA technologies. But more than that, now a multi-time author as well as a code engineer and a bunch of other things. She’s had an amazing, amazing life and career. Aruna Ravichandran, welcome.

    Aruna Ravichandran: Thank you, Alan. I am very excited to be here with you today talking about my latest book.

    Shimel: Yup. So it’s a new one coming out, hopefully in July I guess is the current timeline. And it’s called, “The Kitty Hawk Venture.”

    Ravichandran: That is exactly right. So you know, I think we chatted about a year ago when I wrote my first DevOps book. It was called, “DevOps for Digital Leaders.” And what we decided to do based upon the substance of the book is to basically to take a leaf from the Phoenix Project and write this book in terms of a real life story about one of our customers. I can’t name who the customer is. And the book is actually called, “The Kitty Hawk Venture.”

    And it’s a novel about continuous testing in the world of DevOps in order to help customers as they’re going through their digital transformation journey. So it’s not written as a continuous testing handbook.

    But it’s basically a real life example which happened with one of our customers and tells the story of the journey they actually went through in terms of how they actually transformed their testing discipline, lines of automation down to continuous testing and how they actually addressed some of the bigger challenges they actually had internally across the board.

    Shimel: Got it. So Aruna Ravichandran, I promised you and I promise our audience, no spoilers on this. So I don’t want to go too much into the actual story of the book, let’s keep it at a high level and say that it is about continuous testing and it is based on a real life customer experience. Maybe an amalgamation of customers.

    But you know, Aruna Ravichandran, you mentioned your first book, “DevOps for Digital Leaders.” So this is then your second book on DevOps.

    Ravichandran: Yes, it is. But this time I’ve actually focused on one of the emerging disciplines within DevOps. the first book was primarily focused around DevOps as a discipline, some of the challenges customers actually face.

    Where do they actually start. Because you know, there is no hard and fast rule in terms of DevOps. you can start with continuous integration. You could start with continuous operations. Or you could start with continuous testing.

    The book was primarily focused around end to end DevOps and gives some amount of coaching to the end reader on where to start, what’s the maturity model, what are some of the metrics, how do you measure the substance of DevOps.

    It also talks about several different customer examples on the journey they actually went through. But and speaking from that, we saw that a whole bunch of our readers are interested in learning more about an emerging discipline around continuous testing. So this book is primarily focused on continuous testing as a discipline and why it’s a very important area within the world of DevOps.

    Shimel: Yup. Now, Aruna , though, you hear it in your voice when you’re speaking to our audience here – it comes through loud and clear. this whole area of DevOps – continuous testing specifically with the book. It’s something that you are passionate about. I get it, you’re a VP in the DevOps group. You should feel an affinity. But this seems to go beyond your title and your job. It’s truly something you have a passion for.

    The book is almost 200 pages from the early view I saw. You don’t write 200 pages, you know, blah, blah, blah. You’ve gotta have sort of a burning passion. What is the passion that’s driving you?

    Ravichandran: So the passion that drives me is my customers. As I talk to my customers in the DevOps space, I am very passionate about solving customer problems. And as I talk to my customers, especially customers who want to make an impact, who are on their digital transformation journey, what I learned was testing is a discipline which has existed for several different decades across the board, the very first time when this actual code was actually implemented.

    But what you – what I actually found is that people have testing practices. But it’s mostly around islands of automation. Very, very few customers actually are doing end to end testing, which I call continuous testing.

    And even though you have islands of automation, what I actually find is that testing still continues to be manual. I did a poll of a whole bunch of enterprise customers across the board, and I was shocked to find that testing still appears to be 70% manual across the board.

    And given all of the – this is my personal reason for why I am very passionate about continuous testing, because I think that DevOps has gained a tremendous amount of precedent, but if you don’t embed continuous testing as a discipline across the software development life cycle, you really cannot go through DevOps.

    So continuous delivery has a lot of what do you say affiliation with the market. More and more people are getting educated on how to basically go through the CICD pipeline so that it can go from code to production in minutes. But what they realize is that if you don’t have the testing discipline embedded across the SCLC, going through the pipeline doesn’t buy you anything.

    And so that’s why this is a very important topic which I am very passionate about.

    Shimel: I mean, Aruna Ravichandran, on some level it’s almost – and I think I’ve heard you say this, continuous testing is almost the missing link. Right? In the continuous delivery, in the software development life cycle delivery chain. Right?

    For a lot of – you know what I mean? Companies, they focus on configuration management, on CICD, even on security. But that continuous testing is – it’s right there. It’s a lynchpin. The other thing I wanted to just quickly mention about it is continuous testing isn’t just a pre-delivery —

    Shimel: It’s truly continuous.

    Ravichandran: You nailed it. I would 100 percent agree with you on everything you stated. It is the missing link within DevOps. continuous testing is a practice of testing across every activity in the software development life cycle with the hope that you can uncover and fix unexpected behavior as soon as it’s ingested.

    So it’s about embedding testing as a fundamental and ongoing aspect of every activity through the application life cycle, going all the way from requirements down into production, while facilitating the pre-exact mechanisms what happens in the world of DevOps to where you can actually fix the problem throughout the life cycle.

    Shimel: Let me return to “The Kitty Hawk (Venture),” here again if I can for a moment. You mentioned earlier you took a page out of Gene Kim’s Phoenix Project book in that this isn’t similar to other books you’ve written and that I’ve even reviewed. That are your typical sort of business textbooks, right? You follow an outline and a table of contents and it goes. “Kitty Hawk” is more like you say – a novel, I think is the right word for it.

    How does that make it different for the reader? Or the listener if it’s an audiobook? For someone reading the book.

    Ravichandran: Yup. So for example – this book “[The] Kitty Hawk Venture” is actually based on the main character in the book is Leigh Freemark and she’s a senior director for quality assurance at a company called Runway Air. So the vertical we actually chose was an airline company.

    The way this book is actually written is it talks about the journey of what they actually went through from a transformation journey. So they experienced a major glitch in terms of quality and which caused a substantial amount of negative reputation for Runway Air.

    So this book actually walks through Leigh’s journey, the journey of her own personal mission of making quality first as a big part of her agenda.

    And the way this book is written – we have so many technical books which basically come into the market on DevOps and on testing, so on and so forth. So we wanted to basically – we took a leaf from “The Phoenix Project,” and we also took another leaf from “The DevOps Handbook,” which is the second book which was recently announced by Gene Kim.

    So this is basically written as a novel which tells you the journey which Leigh Freemark went through with Runway Air, but at the end of each chapter we give guidance in technical terms, of what was the actual continuous testing journey Leigh actually went through.

    Right? So that’s why I said, it’s written as a novel but at the end of each chapter we also have like a handbook around the continuous testing discipline on what changes people actually need to make in order to fully embrace continuous testing as a discipline in the book.

    Shimel: And even beyond that, Aruna Ravichandran, from what I understand and correct me if I’m wrong, you guys are planning on coming out with sort of an eBook companion to “Kitty Hawk” on “The Definitive Guide for Continuous Testing.” Is that correct?

    Ravichandran: That is exactly right and so we just actually published it and it will be out very soon. It’s called “The Definitive Guide to Continuous Testing.” And here, we walk our users through 11 different disciplines on continuous testing.

    Ongoing all the way on small teams [sound drops] _____ to how basically they can go through the transformation journey on continuous testing. And at a very high level, I walk you through eleven disciplines and you will see that completely in the novel because that was the journey which Leigh Freeman actually went through in the book, is the first discipline how do you basically and it will – the – you know, all of your testers.

    It could be a developer who is actually doing unit testing or it could be someone who is doing API testing or it could be load testing. Or it could be reproduction testing. All testing in production, you need to be able to have your environment set up. How do you quickly virtualize your environment becomes a very important part of the mix.

    How do you basically break on your environment, how do you actually create your environments very, very quickly is one of the first disciplines. The second discipline talks about testing management right? So regardless of what testing you’re doing having the right data at the right time is very critical. So how quickly can you generate your data?

    And given the world of GDPR right now, you know, which basically went into a test in May, people have to be even more critical about generating test data. You want to make sure that your GDP are compliant. And so having the test data at the right time is critical but also being compliant with a whole bunch of mandates out there is even more critical. The third discipline talks about test automation. How do you basically fully orchestrate the application pipeline.

    So that if the scripts actually fail, you can orchestrate how you can actually achieve continuous testing. The fourth one is around pipeline orchestration. This is the backbone. Everything is tied to it. everything must be integrated with your entire automation stream. You need to understand how it works, how to interpret the results and how do you make quick decisions in order to find out which part of testing is actually a bottleneck?

    And this is what we actually call pipeline authorization. The fifth one focuses on the various different competences, right? If you are testing, the world is going more towards an API economy. So how do you actually bring API testing discipline so that you reduce the reliance on UI testing? Especially for business logic testing.

    The sixth one is around performance and load testing. Right? So you can’t think about performance and load testing toward the end of the testing life cycle. You need to think about shifting left performance and load testing so that you can enable development teams to actually think about this much more earlier on.

    The seventh one is the around the new emerging practice around security testing. So this is where everybody talks about DevSecOps, it’s all about shift left security. How do you enable developers to actually embed static code analysis as a part of their unit testing?

    How do you basically get them to think about security testing by making it easy for them? By having it integrated as a part of their ID environments, whether it’s intelliga or it’s xless or visual studios, so on and so forth. So security testing is the seventh one.

    The eighth one is accidents of test driven development and behavior-driven development. So you take the accidents criteria for each user and create that to ensure that those were actually met. Right? So this keeps testing focused within sprints and ensures developers develop what the business actually expect.

    The ninth one is around automated test generation. And this is the activity of manually designing and writing manual tests of automated tests which is the biggest bottleneck.

    They are the computing magazine data surveyed very recently and they asked, which is the biggest bottleneck across your software development life cycle? 63% of the practitioners actually said that testing was a bottleneck. And why was testing a bottleneck? Because it takes time.

    Think about it, you have actually created 200 test cases for your regression suite for a vertical feature you are going to launch. Let’s assume you’ve caught a major defect and you fix the vertical defect, it means that you have to go back and recreate all of your regression text suites.

    And if there was an automated way that you could take your requirements and as things changed in production you can recreate your test suite, that will be a tremendous amount of savings for anybody to actually not have to create the test cases manually which then eliminates the bottleneck which we actually have.

    The tenth one is around requirement engineering. You must include all of SDLC stakeholders into your continuous testing journey. This means finding a better way to communicate and collaborate right from the requirements phase. The earlier one includes requirements engineering into continuous testing initiatives, the smoother that continuous testing journey will be. Because team members will be working with the same understanding right from the beginning.

    And the last but not least – the eleventh discipline talks about feedback loops. This is the heart and soul of DevOps, it still continues to be the heart and soul of continuous testing. These are critical to ensure that you can have successful continuous testing.

    Shimel: Excellent. You know, Aruna Ravichandran, sitting here looking – I want you to talk about quality, I don’t know if we have time. Maybe we’ll do it on another show. But the 11 disciplines, you did a great job laying them out here. I’m just wondering if someone listening says to themselves, oh my goodness, where do I begin? This is daunting. There is eleven of them. What is your advice to someone just starting out, listening in here – do I do eleven at all at the same time? What do I start with? What – do I take the path of least resistance? How do I get started with this?

    Ravichandran: So I break it up into six different areas, so this is a question you get asked for DevOps and you get asked the same question around continuous testing. So if I have to give guidance on techniques on how to actually adopt – it’s also a cultural transformation too.

    So the first one is, you know, you need to figure out a way to improve the relationship between the tester and each developer. So keeping the team small and creating inter-team collaboration makes it very easy to actually report and actually share the results between the tester and developer.

    So that would be one important tactic which needs to be adopted from a cultural transformation perspective. Number two, is like I said, people actually have automation within testing, which is what we call test automation. But they really haven’t automated the whole thing. So I would say continue to make automation a priority.

    So figure out where people are spending a lot of their time – it could be around building a regression test suite, because they tend to be manual. So how do you automate? So keeping that automation mindset is important. Figuring out where you’re spending cycles of your time in terms of doing manual tasks is important. So making automation a priority is important.

    Map out within your SDLC and identify your automation opportunity. Number three is make it small – right? Like get small. Break it down into smaller increments so that it’s easier to test after every aspect of the SDLC. So break down increments after coding. Break it after design. This makes it easier to automate the test and it also makes it much more easy to deploy and integrate as a part of continuous delivery.

    The fourth one is you want to keep track of everything. Use metrics. Start-up criteria. Right? So your defect density rate is high, figure out how can you reduce the defect density rate. Continuous testing is all about immediately identifying if things are working or not. How do you basically rinse and repeat if it’s working, or how do you actually pivot and change if it’s actually not working.

    The fifth one is getting the right continuous testing tools. Tools play a big role. So we talked about also transformation, we talked about processes and practices, and also having the right tools is important. Figure out the tools that help you develop tests and analyze continuously.

    Pick the best of breed tools that work together in a way that incorporates very easily into your continuous delivery environment. Choose tools which have community based support, that have open source plans that everyone shares the challenges and solutions and have interesting and lead to interesting use cases.

    And last but not least, the number sixth one, is develop a system to display your results. So do deep dives into the results, because that shows you that if you have your code not working, where the gaps are. define your KPI and your acceptance criteria and make them quantifiable. Create dashboards to track those KPIs, including a baseline so that you can actually track with the sequence changes. So these are some of the disciplines I always share with my customers as well as my clients.

    Shimel: Excellent. And now with everyone listening on here. Aruna Ravichandran we’re almost out of time, one more question if you have a second.

    Ravichandran: Absolutely. I do.

    Shimel: So I don’t know if we’re letting the cat out of the bag. If you can’t talk about it, politely say so. But you’re about to roll out something we hear called continuous testing academy? Launching this summer?

    Ravichandran: Yup.

    Shimel: So what’s that about?

    Ravichandran: So the key thing – going back to the question you asked, this continuous testing is like an emerging discipline. People want to know what do I need to do, how do I need to start? How do I get there. And so last year I launched the – I saw that there was a tremendous amount of need in the market around JMeter.

    And so I launched JMeter academy in order to basically to provide input to the community so they could actually train themselves on JMeter. But this year, knowing that continuous testing is gaining tremendous amount of momentum, I’m going to launch a continuous testing academy.

    This is going to have a basic module, it will also have an advanced module. And people will actually have the opportunity to go through the entire module and get themselves certified. We’re also going to launch a certification and you will have the opportunity to become continuous testing certified by DevOps institute. So this is our way to give back to the community in order to basically get people understanding on how they need to evolve their continuous testing practice in order to make a bigger impact in the DevOps world.

    Shimel: Excellent, again, Aruna Ravichandran – great job. You are just, I mean, literally, what a dynamo. All over the place. Doing so many different projects. All with DevOps and continuous testing as a theme there. Congratulations and hats off to you. One of my heroes. Anyway, we’re about out of time. Thank you so much, Aruna Ravichandran, for giving us a preview. Once Kitty Hawk is available to the public, I’d love to have you back on and perhaps we can chat more about it, sound good?

    Ravichandran: Yep. That sounds awesome. As always, Alan, it was excellent talking to you. I love your energy, I love your passion. And looking forward to partnering with you more as we basically enable our customers and prospects to continue on marching further along in the world of DevOps.

    Shimel: Well stay tuned for some announcements, we’re working on it. Aruna Ravichandran, I will be in touch. Aruna Ravichandran Ravichandran, a VP product marketing, marketing DevOps, CA technology, multiple times author, and really DevOps enthusiast. Thank you for being our guest on DevOps chats today. We’ll speak to you soon. This is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps chat. Have a great day everyone.

    — Alan Shimel

  • DevOps Chat: Trends in Cloud Service Management – ML/AI, ITSM, DevOps, ITIL & SRE w/ Sinead Glynn

    DevOps Chat: Trends in Cloud Service Management – ML/AI, ITSM, DevOps, ITIL & SRE w/ Sinead Glynn

    In this DevOps Chat, we speak with Sinead Glynn of IBM about some coming trends in Cloud Service Management, ML/AI, ITSM, DevOps, ITIL and SRE. A lot of buzzwords in there, but there is also some good information here. Sinead is a great interview.

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

    Audio

    Transcript

    Alan Shimel: Hey, everyone. It’s Alan Shimel and you’re listening to another DevOps chat, and – here on DevOps dot com. Our guest for today’s chat is Sinead Glynn, Offering Manager, IBM Operations Analytics, IBM Hybrid Cloud. Sinead, did I – did I get that right? 

    Glynn: Yes, you did, Alan. Thank you. And thank you for having me.  

    Shimel: Thank you. It’s our pleasure to have you. So Sinead, you know, IBM titles are always kind of very descriptive but why don’t you give our audience a little bit more here. What exactly is your role with IBM? What do you work on? What do you do?

    Glynn: Sure, yes. Yes, so I’m an offering manager here with IBM. Offering managers would be known as product managers in other companies. We focus on offering because it’s more – it’s more than just a technology discussion. We kind of go broader and look at the full solution.

    In terms of my own area of specialty, it’s around the operations management and the broader management capabilities from an IT perspective, so it’s your centralized IT operations teams, your DevOps teams, and the management capabilities that they need.

    In terms of the offerings I specialize in and the area I specialize in, I have a background myself in development and, in particular, the development of machine learning and cognitive technologies. So my own focus is in terms of bringing those capabilities to market and, you know, explaining how that – they benefit the IT operations teams and the DevOps teams. 

    Shimel: Great. So Sinead, you know, machine learning and its, you know, its Siamese twin, AI, seem to be on everyone’s lips these days whether we’re talking about Dev, DevOps, Ops, security, testing, or big data, or hybrid cloud, or cloud private or whatever, everyone has a story around ML, machine learning. 

    Glynn: Yep. 

    Shimel: But we’re really here today to really focus in on machine learning as it relates to cloud service management. Right? You know, I – my personal belief is that over the next five, ten years, machine learning and artificial intelligence, AI, is going to have a profound input – impact on a lot of different things that we do. But at a high level, Sinead, talk to us about, you know, what kind of impact machine learning is having on cloud service management specifically, and why it’s sort of become an essential piece of your cloud service management.  

    Glynn: Sure, yeah. So I suppose, you know, there’s two dimensions or two primary dimensions to cloud service management. There is the complexity of what you’re managing, you know, hybrid cloud was something we all talked about, you know, 12, 18 months ago that has morphed into multi-cloud. So, you know, management organizations, they’re handling their kind of traditional systems of record and they might have a number of public clouds and a number of private clouds that they’re using.

    So there’s the – there’s the complexity dimension and certainly machine learning provides the ability to manage that complexity when you don’t have the ability to suddenly grow your teams. So you can’t add people.

    But the other – the other dimension is how you manage. So it is that change in the process and the change in the culture that is required to be successful when you’re doing cloud service management. So, you know, it’s that move from, you know, months or even a year of preparation for a new application to be rolled out, it’s very much that agile versus traditional model and that, you know, DevOps stroke Lean versus your ITIL view of the world.

    So it’s enabling at the roles and it’s enabling those roles to be successful in cloud service management in terms of how you manage, not just what you manage. 

    Shimel: Fair enough. So, you know, Sinead, I – I’ve – we both have been in this – in this business for more – a couple of years. Me longer than you, probably – you’re much younger. But, you know, we’ve seen sort of the rise of – of IT service management and things like ITIL, and, you know, traditional ITSM, and they’ve kind of ruled the roost here 15 years or more, 20 years or more. Right?

    And now all of a sudden we’re seeing, you know, things like DevOps and Lean IT, and even sort of some of what we take from Agile. Right? From the Dev side of the house. You know, almost Agile for Ops if you will. And they – you know, and they’ve all been kind of chipping away at that ITSM model.

    And then most recently, of course, we’ve introduced this term of SRE, site reliability engineering. And now this, along with things like machine learning, really seem to be changing, you know, traditional ITSM at – at its core. I mean, it’s really kind of rewriting the book or – I mean, really forcing us to reexamine some of our ITSM, you know, core values and principles, ways of doing it. What do you think about that? 

    Glynn: Oh, absolutely. You know, ITSM was very much focused on – or is, it’s not a was thing. Is very much focused on operational excellence about, you know, being that gatekeeper to ensure that only high quality applications are deployed and very, very process-centric and control-centric, typical kind of waterfall type methodologies, and that was very effective before the real transition in terms of how business is running.

    So business – business must have digital engagement. Business must have agility in order to innovate, in order to keep your clients and grow your client base. And that, you know, operational excellence stroke, you know, very process-centric risk adverse way of managing just – just doesn’t work. So that’s where, in line with – in line with that digital transformation, the DevOps practices and the Agile Ops has to emerge with it.

    And, you know, from an Agile Ops perspective, that’s much more about how can technology help me be agile while still managing the risk and delivering exemplary service? How can technology help me rather than how can I be very process-centric.

    Shimel: Yep, and Sinead, though, I – you know, I almost feel compelled to caution the audience that I don’t think your saying, IBM’s saying it, I’m certainly not saying that ITSM is dead. You know, it’s more like ITSM is dead, long live ITSM. Right? And, you know, it’s just – it’s changing, it’s morphing, it’s evolving with – with, you know, new things like AI machine learning, but also with new frameworks like DevOps and Agile for Ops and Lean and so forth.

    And this kind of gets at the heart or _____ of SRE. But another fundamental, I think anyway, another fundamental shift in this is – and I’ve heard you talk about it – we – we had the pleasure of doing a video at – I think it was IBM Think a couple months ago – is the kind of the – not the changing customer but the changing kind of world view that – that we need to have over in Ops, and that is the – the, you know, the changing into a skilled service organization rather than the center of the universe. 

    Glynn: Absolutely. So, you know, it’s – it’s moving the mindset from, I’m the center of the universe, I control everything, you know, with process and controls, et cetera, to, I have to support the required agility in the business. And in order to support the required agility in the business, I need to be much more about being a skilled services organization.

    And just on the topic of, you know, is ITIL dead or, you know, it’s usually a coexistence. So, you know, we frequently see, particularly in larger organizations, you know, your traditional IT Ops remains and they need to have a – you know, they may need to have visibility and control across both the traditional and the cloud environments, whereas the software reliability engineer, they tend to service maybe a number of DevOps teams, supporting them in their agile work practices and they’re very much focused on automating rather than throwing people at it.

    So it’s very much – maybe 50 percent of the time is worked on – or spent on kind of traditional operations and 50 percent is really looking at, you know, how I can scale this better. How can I automate this better and how can I support? So it’s really that services view.

    And there is a transition, you know, there isn’t really clear lines. They might emerge over time but there is – there’s really kind of two types of organizations frequently emerging in the larger organizations and – and it’s because the larger organizations typically have been around for some time. So there’s already a tradition of that – that centralized IT operations.

    From a technology provider perspective, there’s a challenge because everyone is trying to do the same job ultimately, you know, deliver exemplary service, but because of the cultural differences and because of the skill differences, they have slightly different views in the world.

    So it’s the same thing – they’re managing but they need different views in the world. And I guess our challenge is to ensure that they – the right experience and the right insights are made available to the right types of users to do their job most effectively. But definitely there is that transition towards the site reliability engineer and their needs. 

    Shimel: Yeah, I’ve heard – I’ve heard people say that, you know, this whole SRE kind of role becomes the Ops in DevOps but, you know, in listening to the way you talk about it, Sinead, again it – it reinforces a continuing maturity sort of view of the world. You know, as a dad or as a parent, you know, every child is the center of the universe. Right? The child believes that they’re the center of the universe. And I think part of the maturation process and growing up is realizing perhaps you’re not the center of the universe. Right? But you are, you know, there’s a big world out there that you’re part of.

    And I think that kind of really – when you think about it that way, that’s – that’s the journey for Ops. Understanding they’re not the center of the universe and they’re a part of this bigger world. And – and – but they still have a – a vital role to play, a very important role to play and – and I think that SRE role is in there. 

    Glynn: Absolutely, absolutely. 

    Shimel: So, you know, we have this webinar coming up on June 21, 2018, and it – it is, you know, along the lines of cloud service management and – but it really comes from, you know, I’ve seen anyway, a – a changing view of cloud from IBM itself. And, you know, IBM’s not a small company so when their – when their world view shifts, there’s usually good reason for it. Right? And it tends – and it tends to change a lot of others’ world view as well.

    And you mentioned it rather casually earlier. You said something like, “Well, we’ve gone from an emphasis on hybrid cloud to a multi-cloud.” You know, dropped that in there. But, you know, that’s – that’s a profound – you know, that – there’s really something here. 

    Glynn: Absolutely. 

    Shimel: Talk with our audience a little bit. What do you mean by that? 

    Glynn: Absolutely. I suppose in the – in the early days, you know, there was a focus on, we have cloud. It’s fantastic. Come buy our cloud. Let me show you what our cloud can do. And I guess through many interactions and learning process, it’s obvious that, you know, no one cloud does all jobs. So it’s about picking the right tool for the right job.

    So what we see is that the complexity in the environments that are actually being chosen. So it’s a multi-cloud strategy. It’s not a, I’m going to put everything into one particular vendor, or, you know, I’m going to move all of my workloads exclusively to cloud. You know, they – it’s much more granular decision. Certain parts of the business, you know, usually the systems of record, they may be kept on existing infrastructure and continue to be managed there, whereas the systems of engagement may go to public clouds, they may go to private clouds, depending on your security and data requirements.

    What businesses are doing and what smart businesses are doing is, depending on the type of application modernization they’re driving, they’re selecting the right strategy. Which is great for business, it’s a heck of a challenge for your centralized IT operations because of that complexity. So they need machine learning and adaptive automation to help them manage that complexity, to do their more traditional roles in a much better way, particularly when there isn’t that long handover.

    You know, apps are pushed out, particularly in cloud, the scaling out of those apps on the infrastructure is, you know, highly dynamic and, you know, when you’re trying to troubleshoot things, you need to get insight. So you need to have insight and analytics and machine learning to help you understand because there hasn’t been – you know, there hasn’t been a communication that this has happened. So all of those technologies are required.

    So that’s the – the multi-clouds _____ traditional IT Ops, they, you know, the infrastructure is – is agile, there are multiple clouds that they need to be able to see, and then you have some parts of the organization, maybe growing parts doing your DevOps type practices. And they have slightly different needs. You know, the – the DevOps persona just need to see their own project or the – the applications. The SRE engineer probably services more than one DevOps team.

    So they – they have different views and we’re very much focused on ensuring that the management capabilities that we have, particularly around the machine learning and the analytics, that, you know, it’s providing those insights to help those groups do their jobs effectively. So it’s definitely multi-cloud, Alan. It’s not – it’s not hybrid. Not just hybrid. Yeah. 

    Shimel: I – I agree with you. I think that was a good explanation. While we’re doing definitions and glossary terms, let me break – throw another one at you and that’s IBM’s what you’re calling adaptive automation.

    We’ve touched on it, we spoke a little bit about it, but let’s make sure we’re clear for our audience. What do you – what do you mean by that?

    Glynn: Okay, well, I suppose traditional automation and, you know, obviously something that’s been around for 40 years, I don’t know, I think we need to go back – that’s about, you know, I know something, there’s a condition, I kick it off on and that condition happens again. Whatever you’re doing. So it’s very much a rule-based or a condition-based automation, absolutely very effective and very valuable.

    But in – in the cloud world where things are dynamic, we need to think much more about adaptive automation and there are, I suppose, different types of adaptive automation. Does the type of adaptive automation, you know, if we think about, just as an example, the types of machine learning and analytics that would do things like event grouping. So that’s, you know, looking at real-time – real-time machine learning to reduce the number of events in your environment through machine learning, et cetera, et cetera. So that’s kind of a real-time adaptive automation.

    You take it further and you can look at things like maybe proactive automation where you’re using, you know, machine learning to actually learn what is normal and – in your environment and proactively tell you when things have gone abnormal. So that’s more about being able to predict that things are going to happen rather than react elegantly to things that are happening in real time.

    And then taking it further, Alan, I mean, there’s a big push – and obviously IBM is leading this in terms of cognitive capabilities, so not just looking at machine learning on the machine data in your environment, but going beyond that and using machine learning perhaps on your human data, your knowledge corpus, and really imbuing those workflows – workflows with, you know, cognitive – to help humans make those decisions even faster.

    So there’s different levels of it. Practically, you know, folks tend to start off in that reactive way, using kind of, I suppose, automation in real time to reduce the number of events and to trigger maybe standard automations. And then it’s about moving beyond that to really start gaining the value from the machine learning. 

    Shimel: Got it. It’s a great time to be alive in Ops, isn’t it Sinead? Right? Think about – you know – 

    Glynn: I – I think so, yeah. I think so. And I know we – you know, I know some might fear things like automation and machine learning and analytics but I’m fully confident that the complexity of the environments we’re managing is rising much faster – you know, it’s getting so complicated you do need automation and machine learning to manage it. 

    Shimel: You need it. Right.

    Glynn: Yeah, so, you know, I think it is. It’s an exciting time. Yeah, skill set changes, most definitely, but, like, if you – if you look at even, say, something simple like microservices, so, you know, everything is moving to microservice architectures, as far as can tell at least, and yes, that makes the job of development much easier and much more reuse, et cetera. But the – you know, the job of Ops gets a lot harder because it’s a lot less predictable, there’s a lot more data, you know, there’s – how do you see the wood for the trees? How do you pinpoint the, you know, there’s these obscure names on things, et cetera.

    So you need insights, you need help to do the job you did, to do it much better. So, and again, it’s always about supporting that digital transformation.  

    Shimel: Sure. I mean, and it’s really necessity is the mother of invention. Right?  

    Glynn: Absolutely. 

    Shimel: No one – no one does things as much as we’d like to think, you know, no-one does things because they’re cool or, you know, just – you don’t do new for new’s sake. You do new because there’s an advantage to it and so much of what we’re seeing around machine learning and automation and these new frameworks and so forth is a response to the complexity, to the changing nature of the way we’re doing business in IT. 

    Glynn: I wholeheartedly agree. And I have personal experience of this because I’ve been doing this particular role for some time, particularly on the development side, and you know, I would say hand-on-heart, we were probably to market too early with some of this. 

    Shimel: Yeah. 

    Glynn: You know, and – you know, a few years ago it used to be an experience of, wow, that’s really cool, but I don’t need it. It really was, you know. 

    Shimel: Exactly. Right. 

    Glynn: And it was, you know, quite surprising, particularly because I – myself, at the time, I was in development so I was very, why – why do you not see this? It’s like, what’s wrong – but you’re right. 

    [Crosstalk] 

    Shimel: Well, and it is so cool. Right? 

    Glynn: Exactly. It’s very cool, but not needed. 

    Shimel: So that was, like, you know, that was something else that – Sinead, I learned early on, I – you know, my history is I’ve done a number of venture-backed startups in technology over the last 25 plus years and, you know, a hard lesson that I think every entrepreneur learns is you are never going to be successful selling something that’s nice to have. Like, no-one buys things that are nice to have. They look at things and say, wow, that is cool. It’s nice to have. 

    Glynn: Yep. 

    Shimel: But they don’t write checks until it’s a must-have. 

    Glynn: Exactly. 

    Shimel: And – and that’s really the key. Sinead, we’re almost out of time, here. We’re probably over time already, but before we go, I want you to just give our listeners a place to go. They’ve heard – they’ve heard kind of a little bit about what you’re doing and what IBM is doing around this. Where can they find out more? Where can they engage with your team and – and, you know, start living this and doing – you know, they’re probably all – many of our listeners are faced with this very reality. How can they engage with IBM on this stuff? 

    Glynn: Absolutely. Well, just from a – I suppose from a Google-search perspective, there’s an IT Operations Analytics page. So if folks do a search on that, you’ll be brought in, and folks can reach out to me, of course, as well. We’ve an IT operations management page as well. For me, I – you know, it’s very hard to separate one from the other because we’re moving more and more towards that, you know, that AI-driven operations. That’s becoming essential – not a nice bolt-on to have and – on your operations management.

    So certainly that’s the place. Again, if you go to IBM Marketplace and you look for IBM Operations Analytics you’ll find the details of the machine learning technologies around the, you know, the events and the performance that I’ve mentioned, and indeed, you know, the cognitive stuff.

    But probably just to reach out to me, Alan, is a good start. And I can certainly point them in the right direction. 

    Shimel: Great. Okay, so let me ask the magic question. How do they reach out to you? 

    Sineed:Certainly. Well, my e-mail address is Sinead.Glynn@ie.IBM.com. 

    Shimel: And that is S-I-N-E-A-D dot Glynn G-L-Y-N-N at IE dot IBM dot com. 

    Glynn: That’s me.

    Shimel: Got it. Sinead – Sinead, thank you so much for – for being our guest here today. I know I told you it was just 15 minutes and we – we’re probably double that. But I think it was a worthwhile conversation and I’m sure our audience will find it very interesting. 

    Glynn: Okay. 

    Shimel: Our webinar on this, by the way, devopsy.kinsta.cloud webinar sponsored by IBM is on June 21, 2018, at 1 p.m. Eastern – it’s actually Eastern Daylight Time, not Eastern Standard Time. Right? Because we’re in daylight saving time. And 1 p.m. East Coast time.

    So you can log on from wherever. If you go to DevOps dot com and under webinars, you could register for the webinar there. We’ll – we’ll have a link for it in our notes.

    Sinead, thanks for appearing. Hope to have you – you know, the webinar I’m sure is going to be great but maybe we can continue this chat another time on another DevOps Chat. 

    Glynn: Certainly, certainly, Alan. And thank you. It’s always a pleasure. 

    Shimel: Thank you. All right, this is Alan Shimel for DevOps dot com, DevOps Chat. You’ve just listened to another chat. Have a great day everyone.

    — Alan Shimel

  • DevOps Chat: DevOps for Databases, a DBmaestro Update

    DevOps Chat: DevOps for Databases, a DBmaestro Update

    DevOps is coming to databases. While there are several companies who have been dedicated to this over the last few year, by all accounts DevOps for databases has been catching stride as more DBAs and organizations realize the benefits of DevOps for databases.

    In this DevOps Chat we sit down with Yaniv Yehuda, co-founder, CTO of DBmaestro, to discuss what is driving the increased awareness and what is coming to the market. Yaniv is always a great interview with lots of good insight. Enjoy.

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

    Audio


    Transcript

    Alan Shimel: Hey, everyone. It’s Alan Shimel, DevOps dot com, and you’re listening to another DevOps Chat. Welcome to DevOps Chat today to our – a repeat guest. We’ve – he’s been a guest on DevOps Chat several times. Yaniv Yehuda, co-founder, CTO at DBmaestro. Yaniv, welcome to DevOps Chat.

    Yaniv Yehuda: Hey, Alan. A pleasure being here again – pleasure being here today.

    Shimel: Yes, thank you. Always a pleasure to have you, my friend. Yaniv, what we’re going to spend a little time talking about today is, you know, as DevOps continues to mature and we see it moving beyond, you know, the orthodox Dev and Ops only to encompass, you know, more pieces of the IT stack, it’s becoming, you know, increasingly obvious to people that having the database and the DBA as part of the DevOps team, as part of the – you know, under the DevOps umbrella – is a must have.

    And I guess this is something that is kind of elemental, if you will, to the DBmaestro folks. It’s what you’ve been preaching now for, how long?

    Yehuda: For several years. Several years already, yes. Absolutely. Absolutely. No, so I’m in perfect agreement here, you know. It – if you’re trying to start and practice the new or modern process as – may that be DevOps, variations of agility, trying to practice CI/CD – at the end of the day, you need to take care of everything. You can’t just do two thirds or half of the equation. You – it’s like having a car that, you know, you have three wheels spinning at one speed and one spinning slower. So it doesn’t make sense. You really need to cater for everything in order to be efficient, in order to be repeatable.

    And recently, you know, talking about DevOps, it’s really expanding. People now really want to cater for security at the same – at the same rate. Because you’re trying to – to shorten feedback loops, you don’t want to deal with stuff too late, so it’s – it’s mainly DevSecOps and this is what we’re seeing from our customers, the need to take care of security, they need to take care of the database, they need to take care of – of agility and productivity together. So with security.

    Shimel: Yes. Yep. Now, but Yaniv, when we start talking about, you know, DevOps for the databases, DBAs, and so forth, one of the things – right, the database market is a fairly mature market with more than several players in it. Right? You have your  Oracle, DB2, Microsoft SQL, then you have sort of the open source crowd, like the MySQL and the MariaDB, you know, and so forth, and then of course you have the NoSQL group or the so-called NoSQL group which have come on, let’s say, in the last six, seven years.

    I would – is there – from DBmaestro’s point of view, let’s say, is there a difference which database you’re using or they – they’re relatively the same across the board?

    Yehuda: So discussing, like, from a customer challenge point of view, it’s all of the same. It’s all variations of the same challenges. For Oracle you might be pushing, I don’t know, structural changes and – and index creation or even DMLs just to tune the data and for NoSQL you might be deploying an update or a patch that needs to be implemented in each one of the databases but you have a thread of them. It’s – it’s like shards and – and, you know, replications that – and you actually need to take care of a lot of instances.

    So in all cases, you need to have a process to implement changes whether, you know, it’s one type of a database or another. And, you know, it’s just the same problem from different angles.

    Shimel: Yep. Is there anything – let’s say NoSQL. Right? Is there anything specific to NoSQL from a DBmaestro point of view?

    Yehuda: So first of all, we’re about to ship a MongoDB edition for our software.

    Shimel: Okay.

    Yehuda: And I think, talking about specific databases, you tend to see different aspects of – as I said, different aspects of the same thing. I’ll give you an example, a quick one. So many times, when you talk to DBAs and database developers and DevOps people, they want to move fast. And, you know, people say, move fast, break things, and be effective, be productive, but at the same time you need to be careful what you break because some things are just harder to fix.

    So, you know, if you drop a table from production then all break – all hell breaks loose but if you do things that would just take too much time to fix, even if it’s reversible, it’s not a good thing. So you need to come up with a way to move fast, break whatever is breakable, but not break Humpty Dumpty because it’s going to be hard to fix.

    And this is where we introduce a lot of safety nets into the process. So these safety nets might be more database flavored and – and I’ll give you an example. So let’s say you have a team of developers who wants to be agile and they want to run quick, they have their datalines, they have their tasks that they need to provide, and they need to go to the DBA and ask him to do stuff. If he actually has to go to the database and log in and run strips and do stuff, it’s – it takes time.

    You know, I’ve talked to DBAs who had – you know, a few days of tickets to go through and execute what people want to do. And it’s nothing that really benefits anyone because it’s all about just having the right credentials to the correct place and knowing who asked for what and should he be able to run that.

    So we’re automating all of these things in order to make sure that you can run fast, but about the breaking stuff, you break what should be broken. And I’ll give now the example about, like, Mongo versus Oracle.

    So for instance, we have what we call organizational policies and this is really the – helps balance the amount of work with the need to control what goes forward and not destroy things. So for instance, you have policies for Oracle or SQL or DB2 that says you cannot drop a table. Why? Because, you know, you might lose the data. Or you cannot rebuild an index on production in the middle of the day. Obviously why.

    But when you go to something like Mongo, then it’s all about fine tuning these policies. So if you’re trying to, like, create an index with background faults, that means that when you’re going to try and rebuild it, it will be a nightmare. So it’s all about stopping it at the first time when they – when the person puts in the command and saying, “Listen, you have an attribute missing from what you’re trying to do,” in order to live with that safely later on.

    So it’s all about catering for the, like, problem areas of each database and providing the benefit so people can run and if there’s something that they’re doing wrong, they will get very quick feedback, so that’s, you know, all about trolling the feedback loop just like DevOps and Agile are trying to achieve, and this is very much database-specific – so to your question.

    Shimel: Excellent, excellent. Yaniv, let me – let me turn a little – well, before we do, I wanted to just get maybe a – give our audience a quick update on DBmaestro. You mentioned a new MongoDB version coming out, but what else do we have?

    Yehuda: So actually we’ve – we’ve released a DB2 edition – I’m saying edition, it’s actually everything within the same product. It’s DB2 Sport, so DB2 for the mainframe z/OS and for the open systems – Linux, UNIX, Windows – we’re about to ship Postgre support and MariaDB so this is on top of Oracle and – and Microsoft SQLs that are already out there in the market for quite some time. And, you know, Mongo, as we’ve mentioned before.

    So what we’re doing is we’re not, like, sitting in a lab and dreaming, you know, we should do this at – we’re actually, in daily conversations with our customers, getting a lot of feedback, you know, working with the people who need to crack their own tests and trying to make sure that DBmaestro actually helps them in the most efficient way.

    So, you know, I’m proud to say that – you know, we have quite a big vision of where we’re going but a lot of it is fine-tuned with what’s happening in the market so it’s not just lab dreaming and wishful thinking.

    Shimel: Absolutely. So I – I don’t know if your being here told us everything though. I think I heard somewhere about an award or something.

    Yehuda: Oh yes. That is – this is quite, quite new. It’s actually today. We’ve just been announced that we won the Stevie Award for – we won a Bronze award for the best new product. So of course we’re very proud of this and probably will be boasting about this for quite some time now.

    But actually, with – you know, it’s – it’s very encouraging because we’re getting a lot of great feedback. The feedback that I like the most actually, more than awards and, you know, the stuff that you put on the website, is just customer feedback. You know, when you – when you see a person telling you, you know, “I used to wait three days for the tickets to go forward and now the developer is pushing changes five times a day, 10 times a day.”

    This is all I need. This is, like, what we dreamt when we wanted to – to do what we’re doing, to make sure that the database can play the modern processes, that people can practice, you know, the database stuff safely because, you know, if you’ve been talking to, like, DBAs two, three years ago. I think talking to them about automation would be a big, scary thing because, you know – you need to know what you’re doing, you need to make sure that you don’t introduce any risks. And at the end of the day, this is something that you just can’t do manually. You need to be repeatable and the only way to be truly repeatable is to automate stuff and to keep improving it.

    If you do something manually, at the end of the day you’ll make mistakes and, you know, as – as a certain big bird once says, you know, everybody makes mistakes. Oh yes they do. And this is it. You need to make sure that DevOps plays to the values of what you’re doing and – and this is what we’re putting for ourselves as targets. You know? Help people be more agile, be more productive, but not at the expense of safety. So more safe at the same time.

    And that, you know, if it can give you the ability to be also compliance-worthy at the same breath, yeah. Sure, why not?

    Shimel: I agree – you’re preaching to the choir over here, Yaniv. So let me – I wanted to bring up another topic, Yaniv, and this may be a little close to home for you, a little too sensitive, but, you know what, obviously I follow the DevOps market very closely now for a number of years and, you know, I think back to three or four years ago when, you know, the biggest question we got on DevOps dot com was always, “What’s the definition of DevOps? What exactly is DevOps? Is it just a marketing word?”

    And then when we – you know, when it was just Dev and Ops and the idea, when you would talk to someone about, you know, database for DevOps or DevOps for database, excuse me, DevOps for databases, there were a lot of – I don’t know what you want to call them, cynics or just – they were a little bit – a little stiff, who said, “Oh, that has nothing to do with DevOps.” Where do – within the DevOps community itself, how much – how has the attitude changed where DBmaestro and the whole, hey, DevOps is for databases too, has become more accepted within the DevOps community?

    Yehuda: That’s actually – you’re just describing my history here. So for a long time I have been trying to educate and tell the story as I think it should be told and, at the beginning, you know, when we were just bootstrapping and didn’t have the product that we’re so proud of today, cynics were even more extreme and it was, like, DBAs on one side, developers on the other side, a big wall in between, people tossing things over that wall.

    And actually, if you go back two years, two years back I think, this is no longer the case. People are implementing DevOps not just to be modern. They don’t have a choice. Gene Kim once said, you know, it’s DevOps or die. You don’t have to do it but you don’t also have to survive.

    So today – in today’s business, everybody’s trying to run fast. If you’re not running fast, that means that you’re running slower than your competition and nobody wants to afford that.

    You know, you had a webinar, I think, with ABN AMRO a couple of months ago. I was just delighted to sit there and listen to how they described what they built. It’s just – it’s just amazing. So – so – you know, it’s a carefully thought out process that takes out all of the junk time out of the process and makes everything efficient, whatever can be automated is automated, and, you know, it saves a lot of time. It makes the whole company more efficient.

    And then you reached a point where, you know, you’re looking at what you’re doing and that is working – I’m not talking about specifically them, but in general – everything is working but you’re not as efficient as – as you could be because every time that you go to the database side, you go back – you fall back to the manual processes – the single steps, God forbid, the DBA that goes – and side commands in production to make the change go forward.

    You know, the funny thing is when I’m recruiting people to the company, I’m telling them what we’re doing and they said, “This is amazing. This is what we’ve been doing all our lives wrong and this has always been a headache and you’re just solving it.” So that’s – that is certainly something that has drastically changed and I think the last two years has been an accelerated – I would say, accelerated approach to the whole thing that – it cannot be left aside. You cannot just do application, you cannot just do database, by the way, as well.

    You have to introduce a testing automation. You have to build with your infrastructure automation. So may that be containers or virtualization depending on what – where you’re coming from. It all has to be combined in order to reach that Holy Grail of efficient automation.

    Shimel: Got it. Excellent. You know, it – I think it’s a good thing for the DevOps community as a whole but it’s interesting, Yaniv, you almost have to be an evangelist to the DevOps community at the same time you’re evangelizing to the database community because I don’t know if they raise their hand and say, I want to be part of that DevOps thing too. Right? They – they need to be shown the way and evangelized and converted, if you will.

    Yehuda: So on this we do see a changing approach. It used to be, like, trying to convince why they should care. Today it’s not – I’m happy to say, it’s no longer the case. Some customers we have, you know, DevOps champions that push us forward. In other organizations, it’s the DBA or the DBA manager because they see what’s happening. They see the projects around them in the company.

    They don’t want to be left out and there’s – you know, there’s really no gain in – in doing a mundane job. Let’s do the fun stuff. Let’s – let’s improve logic, let’s fine-tune the database. Let’s do the stuff where, you know, computers can’t – can’t still, at the moment, solve the problems for us and leave that, you know, the mundane – mundane back-work or whatever to automated process.

    Shimel: Yep.

    Yehuda: And it’s not just DBA. You know, today you talk to – to, you know, all of our European or the ones who – who need to cater for GDPR. They have a set of new problems they need to cater for. It’s not just, you know, automation. It’s not just DevOps, they need to now make sure that they manage their roles and responsibilities and auditing and obfuscation of data, if you’re taking, like, data from production, now there’s no private data inside and how you do that process. So you want to have holes.

    You have automation for many reasons now. It’s not just efficiency. It’s creating the good process and sticking to it because if you have a great process but it’s just a manual process, each time you do it, you’re doing it slightly different. And this is exactly where I think the whole ARA market is spot on. This is why we’ve – I think we’re seeing the changes we’re seeing in the market in the  last couple of years.

    Shimel: Agreed. Excellent. Yaniv, you know what, I apologize, we’re way over our time here. So we’ll wrap it up. Before we wrap up, any last thoughts – anything you want to share with the audience?

    Yehuda: No, I think – I think, as you said, we did – took a bit more time so I think we can wrap it up.

    Shimel: Okay. Well, look, I wanted to mention that DBmaestro will be at Gene Kim’s DevOps Enterprise Summit in London, I think June 22nd to the 24th, maybe it’s the 23rd to the 25th. Something like that, towards the end of June. So if you were planning on attending DevOps Enterprise Summit, London, please stop by and say hello to the DBmaestro folks. And then Yaniv, you’ll also be at Cloud and DevOps World in London in June as well. Correct?

    Yehuda: Correct, correct. Yep.

    Shimel: Excellent.

    Yehuda: So, as I said, going – meeting our peers, meeting our partners, meeting our customers – just talking.

    Shimel: Excellent. All right, Yaniv Yehuda, CTO, co-founder, DBmaestro, frequent DevOps Chat guest, thanks for being here today with us and continued success.

    Yehuda: A pleasure being here again. Thank you. Bye-bye.

    Shimel: All right. This is Alan Shimel for DevOps dot com and you’ve just listened to another DevOps Chat. Have a great day, everyone.

    — Alan Shimel

  • DevOps Chat: DOES London Session, ‘Compliance and Audit Readiness: The DevOps Killer?’

    DevOps Chat: DOES London Session, ‘Compliance and Audit Readiness: The DevOps Killer?’

    The DevOps Enterprise Summit (DOES) is coming to London at the end of June. DOES London boasts an incredible lineup of speakers and presenters. One DOES London speaker is Ann Marie Fred, who will be presenting, “Compliance and Audit Readiness: The DevOps Killer?” In this DevOps Chat we caught up with Ann Marie to find out more about her presentation.

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

    Alan Shimel: Hey everyone, it’s Alan Shimel, devopsy.kinsta.cloud and we’re here for another DevOps Chat. Today’s DevOps Chat is one of a few we’re doing as a run up into the DevOps Enterprise Summit in London coming up later in June.

    Our guest today is a featured speaker at the DevOps Enterprise Summit (DOES London). It’s Ann Marie Fred of IBM, and Ann Marie, of course, I’ve forgotten your title because it happens but would you mind sharing with our audience?

    Ann Marie Fred: Sure. I’m a Senior Engineering Manager and I work in the commerce platform so that’s IBM’s commerce engine for selling things online.

    Shimel: Fantastic. And Ann Marie this is not your first time speaking at a DOES event, correct?

    Fred: That’s right. I spoke in 2016 in San Francisco and I really loved the conference: I had a great time and I learned quite a lot there so I’m definitely looking forward to London.

    Shimel: Fantastic. So Ann Marie you know I always ask this of people who if you haven’t been to a DOES event and you’re into DevOps or you want to be into DevOps or so forth it really is such a great camaraderie – it’s a great place to be. And for me it’s really about two reasons. Number one, I think the presenters or the speakers at DOES are second to none. You get really, you know, really great insight into real DevOps transformations at organizations throughout the world and whether it be a so-called vendor like IBM or even Electric Cloud or Tasktop or one of these or a practitioner in a large – as Gene calls them – horse – you know a large enterprise, not a unicorn – it’s fascinating to see.

    Because even organizations like IBM so much of their own DevOps offerings are based on eating their own dog food – on their own DevOps transformation, if you will. You know what I’m saying?

    Fred: Absolutely. So yeah, we teach other people how to adapt DevOps but we’re also constantly learning ourselves and it’s great to sort of be together at a conference with people from other large companies who are running into similar problems.

    Shimel: Yep. And you just hit the second thing. Beyond the great speakers the camaraderie of being able to network with people who have similar problems to you. And I think that goes right to the nitty-gritty of human nature, right? You know, not misery loves company but we like to understand we’re not the only one who are facing these challenges or thinking about these particular ways of doing it and it’s great to hear from other people who in similar situations are doing really interesting things.

    And I think that’s really – that really is what I think makes DOES I think a special conference.

    Shimel: Yep. That being said though Ann Marie your talk in London this year is entitled “Compliance and Audit Readiness the DevOps Killer.”

    Fred: That’s right. It does have a question mark after that but –

    Shimel: You know, I’m sorry. The DevOps Killer? I’m giving my inflection. But tell us what exactly do you mean with this one?

    Fred: Yeah, well, you know we always had compliance and audit readiness as a thing that we care about but with the run up to GDPR we had to put a lot of focus on it. And in addition to GDPR we sort of took that as an opportunity to make sure that we had our ducks in order with other things like accessibility, IT security, open-source checks.

    You know, the thing that we always tell people they should do – they wanted us to get to the point where we’d actually documented in a consistent way how we were doing them. And so it was a lot of work.

    Shimel: Well, I mean just – we have some folks on listening who are not up on GDPR but obviously GDPR is the privacy and personally identifiable information rule that is EUI but really when we say EUI because the world is so interconnected it’s going to affect almost everyone. And it goes into affect May 25, so by the time you present at DOES London we’ll already be one month into the official rollout of GDPR.

    So to be fair Ann Marie people have known about GDPR and when it was going to go into affect and what was in it for going on two-plus years now, correct?

    Fred: Mm-hmm. Yep. Yeah, I was going to say I think it took a good year for us to start to figure out what the implications of the thing were.

    Shimel: And you’re not alone – you know, a good year. I think, believe it or not – you know we cover a lot of DevSecOps whether it be on devopsy.kinsta.cloud or on our Security Boulevard site and I think there are a lot of people who even right now are a month out and are saying, “Gee, we better get serious about this,” you know? So a year isn’t so bad.

    But let’s talk about – first of all – let me back up a second. You know what? Some people still view compliance and readiness almost as separate and apart from traditional security, let’s call it, and as we were talking about it off mic in my mind I’d love for us as a whole – as a world – to move to the point where compliance readiness, cybersecurity are really intertwined with quality, right? If you’re releasing quality software, quality applications, quality services it’s compliant by design and compliant by practice. It’s secure by design and secure in fact. And until we get to the point when this stuff is part of our quality I don’t know if we’ll ever be successful. What do you think about that statement?

    Fred: For us? Yeah, exactly. For us part of this whole initiative was – I mean we use exactly those terms, right – secure by design – and what does it mean to be secure by design and what is an example of what you would do to be secure by design and are you doing that and would you sign a document stating that you feel like you’ve done what you need to do to be secure by design?

    So we’ve done a lot of prep work, I would say, and like best practices sharing to make sure that we’re not all inventing the wheel here, you know?

    Shimel: Well, let’s be fair. I don’t want to take credit for the term “Secure by Design” either. I think that comes right out of the GDPR and your reference to people having to sign off that it is secure by design that’s also in the GDPR, correct?

    Fred: Yep. Yep. And you know you have to have it documented somewhere so we all have these compliance folders. Yeah, so a lot of my talk is about how do we get from knowing nothing about GDPR and having pretty poor documentation in some cases to a state where we’re confident as a company signing legal agreements with other companies saying that we’re GDPR compliant ourselves, right?

    Shimel: Yep. So Ann Marie we’re talking about ten minutes and its time to really now – let’s zero in on this talk you’re giving. The DevOps Killer. Why is it the DevOps Killer?

    Fred: Well, it takes time to document all of these things and it takes a lot of manual effort the first time you do it. And one of the challenges that’s unique to DevOps and continuous delivery is that unless you make a special effort you might not even know what all the services are in your organization, right?

    Shimel: Mm-hmm.

    Fred: If people can just spin up a service in the cloud without a second thought have they told anybody that that service exists so that you can ensure it’s compliant, right? So that’s kind of step one. And then it’s almost inevitable that it’s going to be manual the first time but how do we make sure that we don’t have to rerun the entire manual check every single time we deploy the software? You know, how much of this can we actually automate?

    In some cases we can actually write tests for these things, so – because nobody really wants to keep paying that manual price.

    Shimel: No, for sure not. For sure not. So one of the things – I was talking to someone yesterday or the day before and I mentioned that one of the things we seemed to have moved away from in DevOps – and I’m glad we did – was the frequency of release and the speed, right?

    So, “I release 12 times a day,” “Oh, I’ve got you beat. I release 25 times a day,” “I release 100 times a day. And somehow the more releases I did a day the better at DevOps I was.” Right? And always said speed kills, you know? And what’s the right speed or the right release rate for your organization – whatever it is, right? And that is very different than the next organization.

    So in my mind it – yes, not just compliance but security in general can be a drag on release velocity, if you will. But there are good drags and bad drags, right, and it’s interesting, we did a survey a while back Ann Marie and you know developers – when we filtered it by developers – developers said, “What’s the biggest drag on getting your releases out faster?” They said, “Security,” overwhelmingly.

    And then the next question was, “Do you want that drag? Or in essence is that drag the right thing to do or what do you count on to ensure the quality?” And they said, “Security.” So sometimes being the drag but making sure things are done right and compliant and no one’s going to wind up – you know, the fines on GDPR are pretty stiff – is just part of the business cycle that we need to figure into things.

    Fred: Yeah. I mean we compared – internally we compared GDPR to __2K problem – the Y2K problem – that’s what I mean.

    Shimel: Yeah, __2K is another one.

    Fred: Yeah. But the Y2K problem. And we had to investigate every single service that we have and figure out which ones process personal data – and it’s a pretty broad definition of personal data – and then for each one of them make sure we’re compliant. And then now that we’ve done that once how can we still continue to deliver changes to production? I mean, yeah, some services are managed to deploy several times a day and some are every other week but nobody wants to redo the entire audit every time, so what processes can we put into place to make sure that we just don’t break things?

    You know, usually it’s a combination of every time you have a new feature here are the questions you have to ask yourself. And every time you do a code review here are the questions you have to consider, right? And then that combined with some regular reviews – maybe annually, for example – is I think the most pragmatic way to ensure that you’re actually doing what you need to do.

    Shimel: Absolutely. And you know that’s a good word to use when we think about compliance and audit and time drag – it’s about being pragmatic. Another concept Ann Marie that I heard – where the heck was I? – I think it might have been – I was out at the RSA conference about two weeks ago and we were doing a panel on Dev Sec Ops and stuff and the concept was sort of minimal MVP, right – Minimally Viable Product – Minimally Viable Security – so, look, there’s a pragmatic balance to be struck in terms of how much testing, how much security we do prior to release but we’ve got to at least define what’s the minimum that is going to keep us above water and understanding that in a DevOps way even after we release we can iterate feedback loop and iterate and continue to improve our security and compliance and audit readiness, you know, and that’s part of DevOps too, right? It’s never fully baked: you’re always continuously improving.

    And so the concept of a minimal viable compliance and audit readiness posture that would allow you to green light something being deployed versus 100 percent is something to consider. What do you think about that?

    Fred: Right, exactly. I mean you could take this to the extreme and you could say, “Every single place where an IP address – which is by the way personal data – shows up in my system it has to be encrypted in a way that the data can never be decrypted again.” You could say that but then you wouldn’t be able to maintain your system, right?

    Shimel: Yeah. It would be a monster.

    Fred: Right. So, okay, that’s not the right answer. So now it’s about, “Okay, what controls do we need to put in place to make sure that a random person off the street can’t get our logs?” and that that information is protected enough that we don’t think we’re going to get hacked and if there was an attack on our system that the scope of it would be very limited and they wouldn’t be able to do much with the data that they got, right?

    So yeah, it’s all very – there’s a lot of judgment involved in this and what’s your risk tolerance?

    Shimel: Agreed. So Ann Marie believe it or not – I told you the time goes really quickly – we’re coming up on – well, we’re probably past our 15 minutes – so we’re going to need to kind of start tying a bow on this.

    For people listening – and they’re listening to this before GDPR is in affect – it’s not too late. But for those who have just procrastinated too long what’s the best advice you can give them right now?

    Fred: Whoa. Well, I guess I would say don’t be afraid to start, right?

    Shimel: Right.

    Fred: It’s better to do the best you can –

    Shimel: Than do nothing at all.

    Fred: – than to be completely overwhelmed and say, “I can’t even think about how to start on it.”

    Shimel: And you know what? That is excellent advice though because that is the problem. So many people get paralysis by analysis, right, or they’re just so – you know, they look at this monolithic GDPR and all the articles and everything and they’re like, “Oh my goodness, we’ve got so much to do.” But it all starts with the first step. And from what I’ve been told Ann Marie no one – the E_U is not levying any fines or anything any time soon but you’ve got to start somewhere.

    Fred: Yeah. If I were to say, you know, two things that we expect quickly – I think just basic IT security – like having basic IT security processes will cover you for quite a lot of it. And the other thing we expect to be hit with very quickly is the data subject access request –

    Shimel: Yep.

    Fred: and deciding how you’re going to handle those requests because they’re going to come in fast and furious I think.

    Shimel: Yeah, I agree with you. And, you know, I think you’ve just got to get started with it.

    Anyway, so we’ve got that Ann Marie. You are speaking – in case anyone going to DOES is interested they can find it – I think DOES has published the entire schedule now – but you’re speaking on Tuesday, June 26?

    Fred: Yep. That’s right.

    Shimel: And I think it’s out in – at 2:35 PM which is 14:35 over in the UK and in Breakout Room B as in boy. So anyone listening who’s going to DOES come check out Ann Marie’s talk at DOES London and maybe say hello afterwards or before.

    Ann Marie I’m sure it’s going to be a great talk. We’ve heard you speak before. And thanks for joining us today on DevOps Chat.

    Fred: Yeah, thank you Alan, it’s been fun talking to you.

    Shimel: Absolutely. Ann Marie Fred, IBM and a DOES London speaker here on DevOps Chat. You’ve just listened to another chat. We’ll see you soon. Until then, have a great day everyone.

    — 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: The Modern Software Factory and CD Pipelines w/ Scott Willson, CA Automic

    DevOps Chat: The Modern Software Factory and CD Pipelines w/ Scott Willson, CA Automic

    This DevOps Chat features Scott Willson of CA Automic talking about CD pipelines and the modern software factory. The concept of a software factory may be new to some, while others may have heard the term but not really thought about what it means and still others may be very familiar with the term and practice it at their own job. But the idea of a software factory utilizing a pipeline for continuous delivery is at the heart of DevOps.

    This is a really great chat that I enjoyed participating in with Scott. I hope you find it as such too.

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

    Audio

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another episode of DevOps Chat. Today’s chat features my friend, Scott Willson, of CA Automic. Scott has been a frequent guest on DevOps Chat and the reason is he actually has real, usually, good stuff to say and he’s an interesting fellow to speak with. Scott, welcome again to DevOps Chats.

    Scott Willson: Thank you, Alan. As always, glad to be here.

    Shimel: Pleasure to have you here, my friend. So, Scott, we are going to delve into something today that maybe a lot of people in our audience are really familiar with and will like the drill-down, but there may be people who hear the terms but they’re not quite sure what it means. And so what I wanna talk about today are pipelines and especially when in terms of continuous delivery pipelines and how this fits into a concept – really, CA has coined it and led with it, but it’s the modern software factory, right, for enterprises. It’s a factory methodology, almost like an assembly line, if you will, of developing and deploying software and all that that entails.

    So why don’t we start with basics, Scott, if it’s okay. What is – when we talk about the CI/CD pipeline, how would you explain that to someone?

    Willson: Excellent. So the CI/CD pipeline is basically just the concept or the metaphor of taking any change, right, and this is any change that a developer has coded – a configuration change, a change to the data, and, currently, any change to an environment configuration – needs to go back to a starting point and then kind of run the gauntlet, as it were, where it is vetted, it’s tested, warranted, and then made available in production environments. And there’s a whole sequence of things that need to occur, and that sequence is referred to as the “pipeline.” And pipelines are often broken up into stages, from a logical perspective, but in those stages are specific tasks that have to occur in sequence, to have your software, ultimately, be ready to be safely deployed and delivered to production environments.

    Shimel: Yep. It sounds great. Now, Scott, one of the things we’ve seen is, for instance, with Jenkins 2.0, the concept of pipelines and CD pipelines has really, I think, taken on a new gravitas, if you will, within the market. People are now getting serious about it. What about at Automic? And, beyond Automic, the rest of CA even? Where does this whole pipeline thing fit in?

    Willson: Excellent. So, you know, Jenkins really is a continuous integration tool. It’s meant to run a sequential set of all-or-nothing tasks – I mean, “all-or-nothing,” that if step three of five were to fail, then the idea is the whole build would be marked as having failed. And they realized that, “Well, you know, maybe we ought to extend this to a continuous delivery thing, ie. move ourselves out of just building software and trying to push it to other environments. Now, of course, there are some challenges with this, so lots of vendors, including CA Automic’s ONE automation platform – and there’re several other vendors – have jumped in the space to help orchestrate the continuous delivery pipeline, continuous delivery kinda picking up where CI ends.

    And that’s really where the CA Automic release automation comes in, where it is set to orchestrate and automate that pipeline from where CI stops, where the build basically ends and deposits thing in a secure repository, and then it helps move it all the way through to production. And the thing that CA, as well as other vendors who have entered this space and provide tooling for release automation, is that you’re trying to focus on having the same automation mechanics run in every environment, from dev all the way to production.

    And, indeed, that is one of the formal tenets of continuous delivery – to use the same automation mechanics. If you don’t do that, you’re still throwing things over the wall, right? And you’re missing an opportunity to test and QA and vet the automation mechanics themselves so that you can have high level of confidence that they will work in production because they themselves have been tested out dozens of times prior to that new release or that new change that’s being published.

    Shimel: Fair enough. Fair enough. Now, Scott, I guess this sort of begs the question, in order to understand, right, how powerful this concept is, can you give us kind of a little historical perspective? You know, what happens before pipelines? Before this concept of a software factory?

    Willson: Well, right. Things were kind of done manually. You would use Jenkins to run your builds, not just to compile your little change, but to recompile all the other pieces that it integrates with. You know, integration. The integration part of continuous integration. And make sure that changes that have been made aren’t going to break the aggregate app. And so, once that was done, it was really handed off to QA, and QA would do their thing. There were all these manual handoffs. Spreadsheets were being used to track the progress or charts. Microsoft Project and other PM tools were used to help migrate and manage, rather, the path to production, with a lot of manual instruction sets.

    I, previously, worked in a previous life, where production environments or staging environments would be handed a set of instructions that operations team had to follow. As you can imagine, there were always problems. There was always some little step, some little configuration thing, that was missed in those instructions. And so there would inevitably be errors. And so it was just very error-prone and failure-prone, actually, I would say, so CD is the evolution of this, of trying to move things in an automated, repeatable, predictable way, and a safe and secure way as well. And that’s kind of what brings us into this market.

    And I would say, you know, I was going through some of my old notes. A lot of people don’t know this, but, prior to Automic being acquired by CA, Automic was the one who really started this ARA market. And we had approached Gartner and Forrester, trying to explain to ’em that there was actually a need for this market, and I won’t reveal which analyst, but, you know, a conversation like, “Well, what is this thing you’re talking about? This need to automate?” And we said, “Well, we like to call it ‘application release automation,’ ” and the term stuck with the analysts. So what the analyst call “application release automation,” funny enough, actually came from us, as we were starting down this journey. And, in fact, when I started, I had – with Automic, and I was part of the group that helped build this whole thing out, is that – it was funny – you’d go to do meetings and I heard, again and again, all over the world, literally globally, Alan, I’d hear this comment – “Wow, we didn’t know anything like that existed.” So this is kinda where we started.

    Now, within two years, that changed. Within two years, there were several competitors, Nolio, UrbanCode, which both, like Automic, were acquired. And the world just kind of understands this whole concept nowadays, of continuous delivery automation. But, when we started out, this was new. And, you know, Automic actually was at the forefront and named this market, so I thought that was – that’s kind of cool to know.

    Shimel: Absolutely. Absolutely. You know, Scott, I was just sitting here, thinking, you know, we’re both around in this business a long time, and so, in the late ’90s, dot-com days, I helped start a company called “Interliant,” and we were one of the early ASPs. Right? And we did Lotus Notes hosting and PeopleSoft hosting, Oracle apps, some other defunct software that’s not around anymore, but this was before cloud. And we had to customize every installation, every – you know, ’cause the apps needed to be customized. And I’m just thinking back to how we were developing and deploying back then. And, you know, it seems like 100 years ago, not 20 years ago, first of all, but it’s amazing when you think about the changes we’ve seen in such a short time.

    Willson: Yeah, but you know what? It’s funny, Alan. So I remember those days as well, the pain of working weekends and doing massive deployments, but what’s funny now – we see all the things that have changed, but a lot of things are still remaining the same. In a lot of the large enterprises I visit, Alan, they’re doing this DevOps thing, the continuous delivery thing, with their new cloud-native-based apps or even they’re taking a big app, like their online banking app for a bank I won’t name, and they’re rewriting it in Node.js. Okay? Great. They do this since it’s in the cloud. They’re able to do all these new things – Agile, DevOps, continuous delivery – but they still have all this infrastructure in apps in the background, what I call “classically architected,” right? Your IIS, JBoss, WebSphere, WebLogic, so forth, client servers. You then also have your legacy – your mainframes and maybe large, packaged systems, like Sable and so forth.

    So, even though they’re doing a lot of things – we’re hearing a lot of messaging towards the new ways to do stuff – a lot of enterprises I visit still haven’t gone on that journey ’cause they haven’t quite moved so many things in the cloud and they’re still doing the way things, Alan, you and I saw done in the ’90s.

    Shimel: Mm-hmm.

    Willson: In some ways, a lot of it’s kind of this panic. This fear of like, “Well, you just never know, man. If this thing goes down, there’s so much money at risk and at stake,” that they’re slow to change. And I would tell you that, in the years since I first started my journey during all the stuff, some eight or so years ago, that it’s – even just last year, it was kind of – I don’t wanna say refreshing, I don’t wanna say surprising, but it was certainly eye-opening to see how many large enterprises fundamentally still do things the same way they did in the late ’90s.

    Shimel: Yep.

    Willson: And they’re asking, “How do we go forward? How do we do this?”

    Shimel: Agreed.

    Willson: So it’s not a given, all this new stuff, Alan, is what, I guess, what I’m trying to say.

    Shimel: No, it’s not a given. It’s not a given. But you also have to ask yourselves, Scott, right, fundamentally, is it a survival threat or threat to the survival of these companies who don’t kinda get with it, right? And what you see with that, Scott, is, look, there may be some industries and some companies and some businesses who, frankly, it’s just not that important. Right? Important. And they could do what they want and if they don’t get with it, they don’t get with it – that’s okay. And you need to – you know, and they may never adopt these ways of doing things and it may not really be a huge effect, but I think, for the overwhelming majority of these organizations, I mean, they really start falling behind the eight ball here, if they don’t get with it, and I think that’s what we’re seeing play itself out in the market today.

    Willson: Absolutely. It’s a danger if you don’t adapt. If they don’t improve their customer experiences, they could absolutely find themselves going out of business. I remember reading a lot about Bill Gates in the mid-90s and how he was just really maniacally focused and concerned with the concept that he could be out of business within just a couple to three years. And, when I was much younger and reading this, I thought, “Wow, that’s a good lesson to learn, one, but, two, I think he’s a bit over-exaggerating things.” Well, he wasn’t. Turns out, big companies, as we’ve seen since the year 2000, have vanished, and it’s very important that organizations who haven’t begun this move begin to modernize their way of delivering software. They just have to.

    Shimel: Got it. Got it. And I think we’re seeing that play out, right? Where it’s kind of “DevOps or die” or whatever you wanna call it. Anyway, Scott, we’re just about out of time. Before we close up, anything news coming out of Automic you can share with us?

    Willson: Well, obviously, we’ve got new stuff coming out, but I really think the new thing – it’s not that new, but one of the things I’m very excited about in joining CA is just this whole concept of a modern software factory, where – and joining CA, the Automic team is an integral part of this strategy and what they’re trying to help these large enterprises do, right? ‘Cause the enterprises, as I said, it’s just not the cloud-native stuff. They have all the classical and legacy stuff that they want to onboard for continuous delivery too and they’re struggling.

    And this whole thing about this modern software factory, I think it’s a bit more of a focus on the tooling, right? It’s another layer to DevOps and to continuous delivery, is looking at assembling and organizing the tooling to get all of your platforms moving at continuous delivery speeds. And it’s definitely possible, but I’m very excited and passionate about this modern software factory and where we can help CA take it. And I think that’s really a good mindset to have, is, yeah, this whole idea of you just plug in your inputs in one end, where your destination’s on the other end, and have things just happen and get you to the promise land.

    Shimel: Yep. I hear ya. All right. Well, Scott Willson, thanks for being this episode’s guest on DevOps Chat. Hope to have you back soon. I know you’re working on some stuff, Scott, and, at the right time, we’ll have you on here to brief the world on it, but, until then, it’s always great catching up with you. Lots of success over at CA and Automic and we’ll talk to you soon.

    Willson: Sounds good, Alan, and, at this time of the year, I will just say, good luck on your bracket. [Laughs]

    Shimel: Yes to everyone out there. Okay. Hey, Scott Willson, CA Automic Software, your guest today on DevOps Chat. This is Alan Shimel and you’ve just listened to DevOps Chat. Have a great day, everyone. We’ll see you soon.

    — Alan Shimel