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.
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.
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.
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.
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.
There may be nothing more difficult in a DevOps transformation than aligning the business with its technology organization—and vice versa. Dealing with skills gaps and information gaps, while addressing communication breakdowns and cultural hurdles can keep even the most seasoned practitioners and leaders up at night. How do we align disparate business units accordingly? What practical tips can people take and implement along their journey?
These are topics we immersed ourselves in during a live video podcast ahead of the DevOps Enterprise Summit (#DOES18) in London. I was able to sit down with Carmen DeArdo of Nationwide and Jayne Groll of DevOps Institute to take a deeper dive into the DevOps transformation patterns and practices. This discussion centered on a major theme of DOES18 this year: business and technology alignment for the modern enterprise.
We hit on many important issues that I think we can all learn from and apply in our organizations respectively. One of the things we’ve learned over the course of the years is that, in DevOps, the focus is heavily cultural, but it has to be squarely on nurturing and getting buy-in across the organization. But at the same time, we need to be orchestrating our strategic alignment initiatives between the disparate functions and organizations within the business. That’s a tall task.
Watch the full video replay below, and/or read through the full transcript to see what key points were made and how we can adopt best practices to move our businesses forward.
Carmen and Jayne will both be speaking at DOES18 London this year and I will be leading video panels that you can see exclusively on DevOps TV / devopsy.kinsta.cloud. Hope to see you there!
Alan Shimel: Hey, good day, everyone. Thanks for joining us. This is Alan Shimel of devopsy.kinsta.cloud. And I’m here to talk to you all today with a few friends of mine about the upcoming DevOps Enterprise Summit in London. This will be a live panel discussion ahead of the London DOES event, which, by the way, is June 25th to the 26th at the Intercontinental Hotel, sometimes called The O2. Our panel today, I’m happy to say, are two really good friends of mine. Well, one is one of my business partners at the DevOps Institute: Co-founder and CEO of DevOps Institute Jayne Groll, and a speaker at DevOps Enterprise Summit London. Jayne, welcome to our hangout today.
Jayne Groll: Hi, Alan. Hi, Carmen. Thanks a lot. Really looking forward to it.
Shimel: Okay. So Jayne has already sort of introduced our next guest there, another good friend of mine, a recognized DevOps leader for many years. He really kind of kicked off a lot of the kind of groundbreaking DevOps work that we’ve seen at Nationwide over the years. Also a great Pittsburgh Steelers and Pittsburgh sports fan, Carmen DeArdo. Carmen, welcome.
Carmen DeArdo: Welcome Alan. Welcome. Hi, Jayne. It’s always great talking to you.
Shimel: Thank you. So all kidding aside, both of you are kind of experts and leaders within the DevOps Enterprise community, and you’re both presenting at DOES London this year. You’ve actually both presented at previous DOES events as well. So thank you for coming here. You know what? When you guys first started kind of preaching in the wilderness about DevOps and so forth, it was a bit of the wilderness, but it’s becoming commonplace in businesses and organizations throughout the world now. Our goal on this chat, guys, is to learn about the patterns and practices that leaders have identified for business and technology alignment, and really what we’d hope is just to share your experience and thoughts with our audience so that maybe they can learn something and they could integrate or assimilate that into their own transformational journeys and escapades.
And just again a reminder, this is about DevOps Enterprise Summit London, June 25th to 26th, and you can get more information on the event at events.itrevolution.com. You’ll find on there, by the way, the entire conference agenda, and beyond Carmen and Jayne, it is a gangbuster lineup of speakers. If you’re interested in DevOps and any kind of related type of technologies and frameworks, etc., it’s really a can’t-miss one for those of us, you know, who follow this space, or even for those of us just getting involved in it.
That being said, though, I’ve spoken enough. Let’s get started. I’ve given a little bit of your background, but maybe I haven’t said everything that needs to be said. So, Carmen, since I see your lovely face on the screen ahead of me here, why don’t you go first? Give us your background, your company role, etc., professional accomplishments.
DeArdo: Okay. Thanks, Alan. So I actually spent most of my career in telecom working for Bell Labs. Thought I would retire from Bell Labs like everyone else at the time, and then the telecom bust happened, and we all had to figure out what we were gonna do with the rest of our careers. But it served me well, because I think a lot of those concepts, even though we didn’t call them DevOps, but, you know, certainly, creating high-availability, high-reliability capacity systems, you know, those concepts are still, I think, pertinent obviously today. I moved into Nationwide to really help with trying to get Agile set up about 12 years ago, and then, you know, as I think you see the case with a lot of companies, they start somewhere in their value stream. They may not even think of it at that point like an end-to-end value stream, but they’re starting somewhere. They start with Agile.
You know, we were very successful getting all our work done there, but then realized, okay, that’s only part of the story. The cards getting into the backlog through iterations is great, but we aren’t getting flow of work from the business into the teams, and we certainly aren’t releasing into production frequently. So about, I’d say, five years ago, you know, somewhat in affiliation, some of the work I was doing with, as you know, Rosalind Radcliffe, Hayden Lindsey, you know, started to talk about what’s this DevOps thing. Was lucky enough to end up at the first Gene (Kim) conference speaking with Hayden. Wasn’t sure what I was getting myself into, but it’s been a wonderful experience. You know, got to meet you, Jayne, and lots of great folks from Gene’s community.
In Nationwide, we’re just continuing to work, how do we make that end-to-end flow and lead time, you know, what do we do to make it better? What DevOps practices can we bring? But as you noted at the beginning, how do you get the business more online? How do you get work to flow? And how do you address culture, which we know is probably more important than technology?
Shimel: Excellent, dead on. Jayne, how about you? You have more hair than both Carmen and I. You’re the lovely face we should see on the screen here. Give us a little background and accomplishments.
Groll: So I call myself an accidental technologist. So I started my career, got out of school, ended up in the legal field for about 15 years working on the business side. So I wasn’t a lawyer, but I was one of the early paralegals for a big Wall Street law firm that adopted UNIX a long, long time ago. I don’t even want to say when, but screens were black and green back then. And so everybody had to learn UNIX. And so I was very fortunate to be given an opportunity to accidentally become a technologist, and I know even with my technical skills, I’m a little self-taught. Was able to move up into some senior management roles across several different verticals, leaving the legal space.
And then in 2004, kind of fell on ITIL and really started to see a paradigm shift in IT that technology is important, but your practices, your principles, your processes are important as well. And people, process and technology became a mantra. And so co-founded ITSM Academy with Lisa Schwartz and really saw the growth of maturity in IT. You know, I always say we love our frameworks. IT, we love our frameworks more than any other business unit, and really started to see that percolate. Met Gene and some others through that experience, but really, landing where we are today. In 2012, I was able to attend an early DevOps day, frankly, at Gene’s invitation and really saw something percolating there that was pretty much common sense, but not common practice.
So we started to see, you know, should Dev and Ops collaborate better? Should there be a faster flow? Should there be less silos? Yes. Should we use automation more? Yes. We automate the rest of the world, we don’t automate ourselves as much. And really started to see something grow there, and, Alan, as you know, in 2015, we launched the DevOps Institute primarily because the practices around DevOps unlike other frameworks were really emerging in the wild. You know, you said it before. They were emerging in the wild and making some sense out of that, you know, as it crossed over into the enterprise space was important and requires a lot of research.
So, you know, we don’t have a single body of knowledge in DevOps. Thankfully, we have a collective body of knowledge in DevOps. So for me, I think part of my, you know, pride is my journey has not been a linear path. Really blessed to be, you know, where I am today, and, you know, DevOps Institute right now is, what, 32 countries that are talking about in doing DevOps. I mean, that’s really kind of surprising and remarkable all at the same time.
Shimel: Yep. And just to excuse, I don’t know if you guys can hear. We have a train, the 11-08 Cannonball Express, going via the office here.
DeArdo: Just like my cousin Vinnie here, Alan? Is that like …?
Shimel: That’s “two yutes.” The way I talk, we’re not far off. Anyway, though, guys, let us move along here. You know, one of the things that I’ve learned in my own exploration of DevOps and digital transformation, etc., is that a lot of businesses, large enterprises, they may think they do, but on the whole, they don’t really understand technology. Yeah, some of the guys in IT understand some of it or what have you, but do you think most businesses understand technology? Carmen?
DeArdo: I think it’s … Obviously, people are exposed to technology. In fact, I talk about this all the time, that sometimes we’re still in the book writing business or book production that we still feel like we got to produce manuals of paper material … The disconnect comes as, How we can effectively utilize the technology that we have to meet the business needs? And I think that’s maybe where the disconnect goes. It’s not that, you know, people certainly are … they have Alexas. They have stuff in their home. They may be even, you know, great at programming their home devices, but how are we actually taking advantage of that to serve our customers? And I still think thinking about things kind of in this … you know, Jayne talked about silos, but I actually think the last frontier really of DevOps is in the left part of the value stream, not the right part.
I think they code the cloud. There’s patterns, maybe not everybody’s done it. I know it’s not easy to do. That’s pretty well-defined from a pattern. The front part is not, and I think understanding that, you know, you have to basically be an IT business. We hear this all the time. If you’re not an … consider yourself an IT business, someone who is good at IT is gonna disrupt you. So it’s not that I don’t think they understand technology. They’re certainly capable of it. It’s just, do we really understand how we can use it the best way in order to meet business needs? And, you know, things like the system of engagement. Well, the system of engagement is gonna change. We’ve already seen it change. It changed from web to mobile. It’s going to voice. It’s gonna go to different engagement models.
That’s fine, but you still have to have the back-end technology, and the microservices, and the APIs, and the ability to deliver more quickly, and I think that’s the part of it, the gap we still haven’t bridged. And how can we actually get …? You know, one of the things that Nicole and I are talking about at the conference is the project-to-product model. And I think large companies like ourselves are kind of flailing at what … you know, that makes sense. It makes sense to align around a value stream, but how do you really define what those value streams represent so that you can actually get that flow and then use technology to help get that quick deployment and, you know, feedback? So I think that’s where we see a lot of the gaps, you know, from that perspective.
Shimel: Sure. Jayne, before I have you answer on that, you know, I got an email of pitch. I get a lot of pitches as you can imagine, but I got one the other day that, to me, really nailed the issue. The issue was they pitched me about how great their solutions and their services are, and they said it makes IT costs less. Instead of … so they’re still thinking of the IT department as a cost center instead of a profit generator. And to me, when you say that, that means you really don’t understand technology, you don’t understand the role of IT in the modern enterprise, and you’re just not doing it right. Jayne, your thoughts.
Groll: So I think you’re right. I think, you know, the modern enterprise has a few challenges ahead of it. Carmen, I absolutely agree with you. I think every business knows they need technology and they need to accelerate their use of technology. I think they don’t understand how to apply that, and more importantly, I think the big paradigm shift, and, Carmen, you said it, is that most companies don’t realize that they are now technology companies. It isn’t even just IT does for you, is the core company as a technology company. And those that kind of recognize that, I think, are those that move ahead. Those that are still kind of hanging on to a legacy … Now, you know, I’ll add kind of something into that recipe that’s a little scary.
With the way technology is moving and how fast it’s going, I mean, the acceleration is remarkable, and, you know, Carmen, you said it. It was cloud. It was mobile. Now it’s voice. That it feels like, you know, this kind of moving target that if I’m a business leader, not a technology leader, although Lord knows that, I think, has a plan here, you know, where do you put the dart? You know, do you invest in mobile? Do you invest in voice? Do you invest …? So it’s such a moving target, and it’s going so fast that I think it can be very daunting to figure out, okay, where do we make our play, and, you know, where do we use our technology spend? And I would say something funny, Alan, because you’re right.
You know, in my years in senior IT management, I almost always reported to the CFO, because I was a call center. And so it was nobody understood quite what I was spending money on, but they figured if I reported to the finance guy, that somewhere along the way the cost would be controlled as opposed to let’s optimize the capability. Let’s look at this in investment. So I really think organizations are trying to figure out, first of all, are we a technology company? And I would say unequivocally the answer is yes regardless of what vertical you’re in. And then where do I invest? What technology do I start looking at? And if what I do today is gonna be obsolete tomorrow, how do I make that investment for my company further?
Shimel: Excellent. So, guys, you both have a little bit of a background, more than a little bit, in training and so forth. Do we train people outside of the IT organizations on what technology can do for you? Do we put up sort of Uncle Sam’s “We want you. What can I do for you?” posters? How do we get the business to understand the technology aspects, the technology side of things? Go ahead.
Groll: I mean, you know, the “we want you …” unless you can promote something that says what’s in it for me, me as an organization, me as an individual, me as a leader, I think that’s difficult. You know, doing road shows on here’s what technology can do for you isn’t something that you can tell. I think it’s something that you have to prove. And I think IT sometimes runs into an uphill battle trying to prove that, because it is costly and it does change a lot of the way people perform on a daily basis. I know what I did today, and tomorrow you want me to do something differently, and I may not be as successful as I was yesterday.
So there’s a little bit of a proof of concept usually, you know, done through piloting, whatever, but I think the, “How do we tell them?” I don’t think we tell them. I think we have to show them.
Shimel: Fair enough. Carmen?
DeArdo: Yeah. I mean, I think we’ve gotten a lot of appreciation. I mean, I’ve told … you know, and Cindy Payne and Jim Grafmeyer told the story at the last conference about Hurricane Harvey and how the business was able to respond within a day to what was a wind event and came a rain event with all our flooded cars and how we got the website optimized to handle those, to take the load off of our customer service center. They’re starting to get that, “Gee, having this capability to deliver things more frequently …” We now have some of us who deliver daily whereas before everything was going into a monthly release. So that’s a great accomplishment.
On the other hand, we’re running into the things that, you know, Topos talked about with compliance, with legal, with … and just, you know, how do we … Most of our time now on lead time is going from the idea to the backlog of the team, not from going from the … you know, the team getting the work to deployment. So I think going into, you know, that view of how do we start to think more about, you know, the other things that are getting in our way of lead time, because it’s not just the IT part of it. It’s now the business part of it, and we have a couple areas now who actually have true product owners sitting with their lines and are almost at the point now where they can deliver, you know, stories and storyboard them and move them all the way through production, you know, much more quickly.
So I think that’s an example, and I think that’s what you need. I always talk about you need stories, you need examples of how this can actually be done at your company, because reading about it, hearing about it is great, but then when you see the team next to you doing it, and even if it’s not perfect and even if you know it can be improved, that’s where really you start to change the culture of not just IT but of the business. You want something like that. And then, you know, I think you got something going that you can really build on top of. Jayne.
Groll: Yeah. I mean, I think that conferences like DevOps Enterprise London, Las Vegas, other events, local events, I think, also let individuals and organizations know they’re not alone in this journey. You know, part of the challenge in DevOps right now, I think, is we’re going from what is DevOps to how do we do this. And it’s not finite. It’s not, you know, you open a recipe book and it says, “Start here. Add these ingredients. You know, stir, bake for 350 degrees, and you have DevOps.” It requires a lot of higher-level thinking, requires some experimentation. And so I think that, you know, access to what have other people or organizations done … Carmen, I think you’re absolutely right, what have other teams done, really kind of making it a community of enablement is very, very important in this space, because everybody’s trying to figure out where do they start. And unfortunately or fortunately, the answer is it depends. It depends where you are, it depends what you’re trying to achieve. So I think that’s part of it as well.
Shimel: Yep. So, guys, let me try to tie a bow on this section before we move on. The reason I asked about the technology and technology education issue is I think it’s imperative for organizations to understand that in order for us to get what I call business and tech alignment, and what I mean by business and tech alignment is that we’re all pulling in the same directions for the same reasons with the same goals, and we’re following hopefully a road that we have agreed upon, and we all know the road we’re traveling, because, again, you get back to DevOps, guys. You know, when you guys are out there talking about it and we were covering it at devopsy.kinsta.cloud, what do we always hear? What exactly is DevOps?
There’s no real definition. What does it mean? You know, how do we define DevOps and so forth? And I think one of the things we’ve learned over the course of the years is that, you know, in DevOps, the focus is, you know, heavily cultural, but it has to be squarely on nurturing, buying across the organization for this “DevOps initiatives,” you know, that we’re starting. But at the same time, we need to be orchestrating our strategic alignment initiatives between the disparate functions and organizations within the business. And that to me is business and tech alignment. If you guys don’t agree with that, speak up, but if you do, let’s move on to our next part, but can we wrap up, Carmen, Jayne? Are you fair to say that what we’re really talking about here is business and tech alignment?
Groll: So I’m gonna jump in just for a second, because … So you know I come from the ITIL space. And so in the ITIL space, they were coining the term BITA, business IT alignment. And so for years and years and years, there was a lot of conversation about BITA and its semantics. But alignment means that we’re kind of standing side by side in lanes next to each other. The reality is it isn’t alignment. It’s really unification. It’s really we don’t need to align with the business, we need to become the business. And, again, I know it’s semantics, but that word alignment gets tossed around a lot, and it implies something like, “Well, I’ll drive my car next to yours, and we’ll travel at the same pace, and we’ll get to the same journey,” as opposed to, “Let’s be in the same car.” And so you understand what I’m saying?
Shimel: Yeah.
Groll: And I said the term BITA is sort of falling away a little bit, but it was thrown around a lot during the years when ITIL in particular, you know, was kind of front and center.
Shimel: Yap. Carmen, any thoughts on that before we move on?
DeArdo: No, that was great points. And, you know, I refer back to Mark Schwartz’ last book, “The Seat at the Table,” and where he really talks about IT really should move beyond trying to get a seat at the table and move towards, you know, as Jayne said, you’re actually moving together, and you have to merge really these concepts of what the business wants, you know, has to be very much aligned, more than aligned. It’s part of what IT need to be doing. So that merging has to take a fact, and I think as much as we’ve seen the culture issues in Dev and Ops, that’s gonna be an interesting culture issue. But we’re seeing the companies who are successful are already doing it. They are working together. And, you know, if you walked up to some of the teams I just talked about, you wouldn’t be able to say, “Oh, well, such-and-such is a business person, and, you know, Jayne’s a business person, and John’s an IT person.” No, they’re a team working together to achieve something for the good of the company, and that’s the way it has to be.
Shimel: Yep. Guys, let me broach another subject then, because I think we’ve covered this one. You know, I read an article yesterday about AI, and automation, machine learning, and we’ve all seen these before, and, you know, how it’s changing. But automation really is changing the job market, especially for people younger than the three of us. I mean, we’ve both seen our … all three of us have seen our 21st birthday recently and …
Groll: Just recently.
Shimel: Recently, but really the folks coming up behind us, and we’re talking about our children and so forth, automation and the job market that they’ll grow into is paramount. And one of the reasons is that we have a tremendous skill gap. You know, my background is obviously in infosec, and now we call it cybersecurity. I hate the term. But there’s a tremendous gap in the security space. There’s also a tremendous gap in the DevOps space, obviously, and that’s one of the reasons we see such a high demand, even for people who may not be certified or classically trained in DevOps, I mean, take some sort of DevOps class. If they’ve learned to work Puppet or Chef or Jenkins, you know, they’re in high demand here.
And so with this skills gap, it doesn’t hinder our DevOps transformation. Is it a drag on the entire DevOps industry or community? Jayne, I’m gonna ask you to take first crack at that. I mean, you must see this with DOI stuff.
Groll: I do, and, you know, it’s kind of like good news, bad news. So the great news is, where else do you get to work in an industry or an environment where you are now encouraged to learn something other than what you’re essentially good at? I mean, you’re now encouraged to grow new skills to evolve. Organizations are funding skills modernization programs. So, you know, we groomed … and Carmen referenced that. You know, we groomed an IT based on silos. And in every silo, you were a developer, or you were a QA person, or you were a security person, and you lived in your silo with other people who had the same skills as you did. And now, cross-functional skills and, you know, what they call T-shaped people where you need to still have a specialty but you’re absolutely required to have very large breadth of different skills means that organizations are supporting and funding that.
So the continuous learner is more the norm today than it was before where you will be a developer … experience, and I think it’s a great day to be in technology truthfully, because you are encouraged to think, and learn, and practice, and train, and do, you know, all sorts of other things. And I think companies are starting to see that. I hear the term “skilling” a lot. We not only talk about training, we talk about skilling. We need to skill our force. We need to skill our teams. We need to reskill or upskill. You know, those are really terms that are starting to enter our common vocabulary. And the day of the generic, “I’m a master, I’m an expert, I’m a practitioner,” and I’ve got a few of those credentials as well, those are so ambiguous that now the skills are very, very tangible, and organizations are hiring, I think, hiring and funding individuals to develop not only technical skills but practice and principal skills, too. So we’re all gonna be upskilled, maybe outskilled.
Shimel: Perhaps both. Carmen, how about you on this one?
DeArdo: Yeah. I mean, automation is obviously nothing new. I mean, I’m really dating myself, but I can remember when people didn’t trust the output of compilers. Like, are we sure the compilers are producing the right machine language or assembly language? I don’t know. I can bring the assembly language better than this compiler. I mean, I think automation and learning is just … obviously, you know, if you spent, you know, four decades like I have, and, you know, none of us are spring chickens, but you’ve got to learn a lot and keep learning. Now, I think the great thing, and I agree with you and Jayne, the great thing about Nationwide is they have invested in learning and upskilling their people. We had this thing called Teaching Thursdays where twice a month we have two hours which is set aside for peer-to-peer learning, and it’s really not … and it’s peers teaching people, and people love to be the teacher.
I mean, at the last forum, Jason Cox was talking about … We had a subgroup focused on operations, and Jayne was there. And talk about … you know, he had some folks on his team, that they have to become engineers. They have to become coders. And one of the guys who initially maybe wasn’t so crazy about it, once they became kind of the expert in their area and they were teaching other people, well, you know, they were really engaged then, because, you know, they were involved and they were the one now from a peer-to-peer learning perspective.
So companies, I think, like Nationwide, Disney, other companies that are leaders in this space need obviously to invest in that. And then, you know, it also means that the associate themselves, you know, needs to take advantage of that. I mean, we can offer those capabilities. We know the jobs are gonna change. We can make those skills available, and then folks need to take advantage of them, but yes, I mean, people have to become more broadly skilled and be able to become more of what I would call problem-solving engineering mindset as we move forward.
Shimel: Sure. So, guys, though, you know, so we have skills over here. And on this side, there’s another thing that creates a tension with the skills, and that’s what I call the information gap. So we have a skills gap, and you guys have both addressed that really well, but we also have an information gap. And I alluded to it when I talked about training. If an employer or an organization thinks that someone who can write a recipe in Chef or has heard of Jenkins is a DevOps engineer, if there’s such a thing as a DevOps engineer, or is someone who, you know, is gonna really help build their DevOps team, to me, that’s not a skills gap, that’s an information gap. How do we understand … How do we make organizations … How do we fill that gap on information so that organizations recognize, A, that there may, in fact, be a skills gap, B, how to fill that skills gap and bring the organization up to it?
I mean, this tension, this chicken-and-egg, if you don’t know it, you don’t know. How are you supposed to know? And so I’ll put it to you. What do you think is more important? The information gap, the skills gap? Are they equally important? Do we tackle them concurrently, individually? Carmen, how do you guys do it at Nationwide?
DeArdo: I mean, I think one of the things that IT hasn’t been good at is treating IT as … we’ve been a very bad customer to ourselves. So if you look at our pipeline, we don’t treat it as a product. If you actually want to get faster at delivering a capability from idea through deployment, you need to consider that as a product, not a bunch of different tools. It’s not Jenkins, and New Relic, and UrbanCode or, you know, the AWS. It’s not that. It’s a pipeline that’s gonna enable you, and it doesn’t start at code, it starts at idea to get you all the way through that deployment. So then what … do you have a team? Are you doing thinking across the pipeline? Are you doing architecture? We don’t do things like value stream architecture or architecting the pipeline as a product. We want to buy a bunch of technologies. We can hire people good in those technologies, but as you said, that’s not really gonna get us where we need to go.
So I think the first thing is, do you really treat your product … One of the first things, do you treat your pipeline as a product? Do you have a team that can actually support that product all the way? Do you have a product owner who can drive continuous improvement across that with funding and prioritization? And do you have one of your best architects, if not the best, to actually create the architecture and do value stream architecture, which is something, you know, that Mik Kersten and I have been talking a lot about. I think that’s one side of it that we don’t get, is teams could … if you ask a team, they can kind of figure out, tell you like a Deming quality circle, how they can go faster. And you can experiment, but then if you’re gonna operationalize that, you don’t want 200 teams doing things in 200 different ways. You can then take that and say, “How do I address that as part of my delivery capability?”
And then I think what you need your leadership to do is apply systems thinking, and that’s a whole another subject we could get into, but I don’t think executives and leaders know how to really address the, “How do I optimize this as a whole?” They want to get into the weeds. They want to get into the tool selections. There’s people that can figure that out. You need to really focus on the strategy and how you can optimize all this great information you’re getting to make sure you’re removing barriers and allowing teams, you know, doing the learning, making sure they can be upskilled, investing in their ability, and allowing them, you know, to be able to innovate and improve your delivery capability. And I think that’s what I just said quickly. It’s easier said than done. And I think that’s where I see a lot of the struggles, and I think where we’re trying to address this is how do we start to put some of those pieces in place so it’s not just a bunch of, you know, divergent disparate technologies we’re trying to bring in and hope that that’s gonna make us get better. Because those things and having skills just around those things is not gonna actually get us to where we need to go.
Shimel: Fair enough. Jayne, I’m gonna give you a chance to comment on the DevOps skills versus information gap.
Groll: So I think the two are really related, and I think Carmen brings up some good points. You know, I think it all comes down to silos. So let’s look at our silos. Well, within our silos, we speak the same language. We use the same acronyms. We use the same tools. We live in a common community where everybody kind of understands what’s going on and what’s happening. And then when we leave our silo and we try to talk to a different silo, we don’t speak the same language. We don’t use the same tools. We don’t have the same processes. So I think the skills gap doesn’t fully overcome the issues with the information gap, but, certainly, there’s help there that if we’re looking to share information, we have to share it in a way that everybody kind of has some type of uncommon understanding.
The other thing with information is, you know, information is really interesting to me, because everyone thinks they communicate a lot. People generally think that they communicate well. You know, teams generally think they communicate … like I told you that. You told it to me maybe in language I don’t understand or it wasn’t clear. It was some report that, you know, I don’t even know where it is. So I think, you know, kind of the flow of information and from a vocabulary perspective, from an understanding perspective, from a “Did you understand what I shared?” is something we all need to overcome. And I think, you know, again, they’re so interrelated to each other that if we start to create a broader set of skills, hopefully, that helps to improve the communication. I think the other side of it is we talk a lot about collaboration, and there’s a really fundamental difference between communication and collaboration.
And so information flows through communication, but communication is pretty much one way. I tell you, you tell me, and somewhere along the way. Collaboration is I start to ask your opinion, and that’s a really big, big difference. And so when we’re starting to share information, there’s a respect that comes across the skills gap. There’s a lot of things that go across that that, again, there’s separate gaps, but hopefully, the long term, and as Carmen said, not easy to fix, is by overcoming some of the skills gaps as well.
Shimel: Fair enough. I think we’ve covered that one well. Let’s move on to another area if we can. We have 20 minutes or so. You know, one of the things that really does my heart good is this concept of DevOps everywhere as far as the eye can see, like the meme with Buzz and Woody. We have seen DevOps move from just Dev and Ops to QA, DevSecOps exploding on the scene where, you know, a couple days, the 28th, a day or two after DOES London, John Willis and team are rolling out our second DevSecOps Days, which I’m involved in, and devsecopsdays.com for those interested. But even beyond IT, we’re seeing what I call DevBizOps, where DevOps’ Agile sort of practices are starting to take hold in HR, in sales, in finance, in, you know, accounting, etc.
And let’s be fair. This is not unique. The fact of the matter is a lot of the lean terminology, a lot of the lean stuff that was built into DevOps didn’t come from IT, it came from manufacturing. And so, you know, it’s like pay it forward. Now we’re seeing these kinds of DevOps principles move into other areas of the business. First of all, is that a good thing? I think it is. I can’t imagine it’s not, but I’ll defer to the both of you. And then, secondly, you know, hey, at the end of the day, remember, it’s all about the culture, stupid. And so what human factors, cultural factors should we be thinking of when we talk about a broader DevBizOps opportunity? And, Jayne, you’re on my screen, so I’m gonna tell you to go first on this one if you can.
Groll: You know, it’s business transformation. You know, it’s not really DevOps transformation. Digital transformation is not limited to IT. It’s really business transformation. And so it goes back to, you know, we talked about a little while ago, where, you know, every organization has to recognize that technology is their business, and so some of the practices from the business start to assimilate into IT and beyond. I saw this in service management where there’s now movement towards enterprise service management, where you’re gonna make changes, you do it the same way.
I think when we start to look … I mean, I can tell you from the content perspective, you know, we use tools in content development, even though it’s not software development, that are very, very similar to that. So I think it’s fantastic. I was talking to a gentleman from an organization on the Netherlands recently, and they actually took the Spotify squad model and applied it to their entire business, and not a small company, by the way. And so they applied it to their entire business where their business is now broken into squads. And, you know, some think that that’s only for a tech company, and by the way, this is not a tech company. It’s a large financial organization.
So I think that’s great. I do think there’s some … I think there’s good news, bad news. I think there’s a little bit of risk that, you know, with DevOps and some of DevOps practice is still emerging that it becomes, “This week, we do it this way, and this week, we do it another way.” And, you know, “Oh, that didn’t work because …” You know, fill in the blanks, but I do think that kind of having a one business and getting away from this we love our frameworks and IT, and every year, we have a new framework that supposedly supersedes the other framework, you know, that’s a maturity issue. And I think if the business embraces it … you’re right, Alan. Lean Six Sigma. That was a business initiative that a lot of organizations underwent that weren’t necessarily manufacturing organizations. So, you know, as we get closer to that, I think the unification becomes stronger.
Shimel: Great. Carmen, how about you?
DeArdo: Yeah. So I think of things like … It is a great thing. So I think of things like lean concepts. We have leaders across the company that we have gone through lean education and lean concepts. So when you talk about value streams, when you talk about lead time, when you talk about wait states, people understand those concepts, whether they be on business or IT. I mean, this whole idea that Dominica, I’m sure, would have talked about, about making work visible, Kanbans. I mean, we actually had an explosion of people who wanted to use some of our tools that initially were brought in for work out of management because they wanted … you know, it’s like, “Gee, who knew, you know, this Kanban stuff would work for us and WIP.” WIP limits. And so people certainly want to apply those kind of concepts.
So I do agree that, you know, the basic concepts, you know, really can spread everywhere, and the whole concepts of even the things, like we talked about it, the three ways. The three ways don’t just apply to IT. The three ways apply to anything that you’re trying to do and get better at. I think when it comes to information sometimes, though, you know, it’s kind of like the robot story and the goal. We have lots of KPIs, but are we actually focused on the goal? So the goal is not around keeping this person utilized or that team utilized. The goal is about, can I get faster from one end of my value stream to the other? And do we have data that shows flow? And that’s why I’m excited with some of the things that I’ve been … you know, that Mik’s talking about. You know, he has a book coming out that is gonna show actual flow of work, because up until now, we have not been able to actually see work flow all the way through that delivery pipeline. And so we guess a lot of times. We think, “Oh, well, if we just add more developers. Oh, we’ll add more testers.”
Well, how do we know? We don’t really know, because we’re making maybe educated guesses, but we’re really not all focused on understanding where the work is and those concepts that can shine a light on it. So I think it all does come back to a lot of those concepts that, growing up in Bell Labs, I was lucky enough to experience with Deming, even going back to Shewhart, around doing those experiments, getting better, seeing the entire end-to-end value stream, but these concepts apply. I mean, “The Phoenix Project” is really not a book about IT even though I teach part of it. It’s a book about how do you get better at doing whatever business you’re in and trying to, you know, stay in business and improve what you’re doing for your customer. So I think those concepts will continue to go, and I think, again, as we’ve talked about today, there’s a thread here of everybody needs to be on board with these concepts: legal, compliance, the business, everybody, because they all play a role in allowing you to do a better job, delivering more quickly to your customers.
Shimel: Fair enough. Guys, let me … You know, Carmen, you hit on some great things there. The Kanban board or even here at devopsy.kinsta.cloud, frankly, we run our entire customer engagement, not practice, but now into farming, on Trello cards, which is sort of an electronic Kanban. And it’s a great project manager. I’ll give you another thing. You know, there’s the cultural aspect of this of taking that sort of DevOps culture and expanding it throughout the organization, but there’s also the bits and bytes and tools aspect of it. Kanban’s a great example. I’ll throw another one out at you. Get up. Why does it have to be source code for programs? Why can’t it be source code for contracts or any kind of digital document or, you know, things that we work on?
So I think we’re just starting to scratch the surface on how we can take that DevOps can do or Kanban and, you know, move it out across the entire organization. And we’ll all … I think we’ll have better organizations as a result, but let me now turn it back around. How can we take some of the business culture positives, some of the things that have worked in other parts of our business, and reflect it back into our DevOps and IT processes? How can we enhance our DevOps by adopting broader business principles and practices that seem to work? Carmen, I’ll let you take first crack at that.
DeArdo: So I think, actually, a lot of our test and learn activities started with the business who had actually hypotheses around, “Well, if we offered a policy in a different way or if we made a tweak to something, would we be able to sell more of those things?” So we had people who … and there’s a lot of statistical rigor that you have to bring to that. So we actually had people on the business side who had these ideas about, “I have a hypothesis. You know, is there a way you can allow me to test that hypothesis to see if it, in fact, will yield some positive result in terms of actual policies being sold?” So it was a very scientific-type experiment that they actually wanted to run, and at the time, we really didn’t have a way to support that from an IT perspective. And it kind of forced us to do some things to support, you know, how could we actually get this out and offer it to only a subset of people, which we now might call canary launch or some other terms that are DevOp-ish terms, but really nobody was reading a DevOps book at this point. They were just trying to figure out, “How can we support the business’s need here to try to adapt more quickly and have a high plan around?”
And that started, I think, some of the things that actually were successful that then led into once we started to get into DevOps, like, “Okay, what we actually did there was DevOps.” We didn’t call it DevOps, but those are principles that really we need to support not just in this one’s case, but for all kinds of business hypotheses that we want to get out and turn around real quickly. And doing that really does bring everybody together, because it’s exciting. It’s exciting if you can sit at a business and you can think up, “I have ideas for this product or that capability. You know, how can we more quickly try to see if that would be a good idea?” rather than writing a 12-month business case and trying to do, you know, a protracted study.
So the whole idea of experiments and gain things out quickly, I mean, everybody will resonate and get behind that if you talk about it in that way. If you start talking about Puppet and Chef and things like that, that’s not gonna cut it. But if you talk about it in terms of business and what it can mean for the business, then that resonates and gets a lot of people excited.
Shimel: Excellent. Jayne, how about you?
Groll: I mean, I think Carmen is right on point. And, Carmen, you said something I think that was … you’ve said a lot of very insightful things, but I think in particular that the experiment came down to, “How can we sell more policies? How can we make our business more successful?” And I think if you look at kind of the past in IT, sometimes, we didn’t know how we were contributing to the bottom line. So we were introducing a lot of technology, and we were doing all this cool stuff. But how did that convert into an increase in revenue, an increase in market share, increase in competitive advantage, things like that? And so I think that this unification with the business becomes more significant when IT sees themselves as an enabler of the goal. The goal of every business is to make money. And so sees themselves, and it goes back to information and communication as well, that they understand that what they’re doing is actually helping to sell more policies or increase market share or stand above the herd or anything along those lines.
Now, again, if you’re the CIO, you probably know that. If you’re in senior management, you probably know that. If you’re a developer and you’re one of a few hundred developers, you may not know that. And so I think that it is that kind of bottom-up top-down approach where understanding that what you do every day is contributing in a very, very substantial and tangible way. And then I think the other part of it, and, Carmen, I think you said it really well, is encouraging those experiments where the business and IT work together. And maybe it is that 1 in 100 coder that’s working as part of that team to say, “You know what? I have an idea.” Everything starts with a great idea. It could be from the business. Hopefully, from the business, that says, “I have an idea. Let’s see if we can, you know, bring that to life and what it will do to our bottom line.” And then there’s really a great collaboration between IT and the business.
Shimel: Agreed. Agreed. So, guys, we’re coming up to the top of the hour here, and I guess we need to wrap up. Otherwise, we’ll just be on air all day, and I know Jayne has a show in Vegas and so forth, and Carmen has stuff to do. But first of all, Carmen DeArdo, Jayne Groll, thanks for being our guests here on this hangout as we, you know, continue to build up to DevOps Enterprise London, DevOps Enterprise Summit London. Just a reminder for anyone watching, it is June 25th and 26th in London. There are still some tickets left, I think. I don’t know how many. I wouldn’t wait. You can get updates about the event as well as get tickets at events.itrevolution.com. It’s obviously on the web.
By the way, this year, as in past DevOps summits, devopsy.kinsta.cloud is a media sponsor. We’re partners. We’ve partnered with Gene from the beginning. We will be doing videos again this year at DevOps Enterprise Summit. I think it’s gonna be a little different this year. We’re doing some interesting roundtables. You’ll see them on our YouTube channel, DevOps TV. So stay tuned for that. All right. Guys and lady, or guy and lady, I had a great time today. I’ve learned a whole bunch. I hope our folks listening and watching this have learned as well. You know, you guys have done, not just today, but, Carmen and Jayne, you’ve been instrumental in helping to bring the gospel of DevOps to the world, if you may, or at least maybe not the gospel, but at least some really good learning and understanding.
So thanks again, guys, for being with us. We’re gonna call it a wrap. Carmen, any last word? Three words.
DeArdo: Three words. Project to product.
Shimel: Okay. Jayne? Last words from you.
Groll: Pittsburgh Steelers. I don’t know.
Shimel: We finally got her. Carmen, we converted her.
DeArdo: I should have said, “Let’s go Tens.” That’s three words.
Shimel: Okay. Hey, everyone. I will see you both in London June 25th and 26th. Hope to see many of you listening or watching this in London as well. If you’re there, stop by, say hello. I always like to meet people who have watched us online. But until then, this is Alan Shimel for devopsy.kinsta.cloud and IT Revolution. Thanks for watching, everyone, and hope to see you soon. Bye-bye.
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.
In this DevOps Chat we spoke with Prem Chandraskearan, VP of Software Engineering at Barclaycard. Prem led the DevOps transformation there. He sums up his learning thusly:
The best way for an organization to approach DevOps is from a collaborative angle. When development and operations experts actively work together in a cohesive effort, solutions are well designed, efficient and smart from both a development and maintenance perspective. When operations is viewed as a software problem, Dev and Ops can work in tandem to implement a tool that is holistically a part of the process from start to finish.
DevOps is always a work in progress, but the initiative can only improve with quality resources that implement a variety of backgrounds and perspectives on both Dev and Ops working together. Barclaycard has had some interesting challenges with DevOps due to being in the credit card/banking industry, so for example, the “you build it, you run it” mantra doesn’t work as well for us as it would for other enterprises implementing DevOps. It is definitely a learning curve, and our goals and best practices are still coming to fruition, but we are continuing to find ways to automate.
The best way to get teams to work together is to simply ensure that they are not in silos, meaning that if there are distinct dev and ops teams, they must spend time in each other’s sectors to understand the pains, how the functions work, what makes it tick, etc. When the development and maintenance perspective are strategized in tandem, it automatically makes for a better, more streamlined workflow.
The best way to ensure a DevOps initiative’s long-term success is to ensure that the foundation of the program is collaborative and understanding of how each function works. With this, automation testing for failure is imperative to discover problems that are typically only otherwise found in production. If all the bases are covered and the process is streamlined and collaborative, the overall quality of your DevOps function will be much higher.
As usual, the streaming audio of our conversation is immediately below, followed by the transcript of our conversation
Audio
Transcript
Alan Shimel: Hi, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Got a great chat scheduled for today. We’ve got a real, live DevOps practitioner. I’d like you to welcome to the show Mr. Prem Chandrasekaran—and I mangled that terribly—Prem, why don’t you give us proper pronunciation?
Prem Chandrasekaran: The name goes “Prem Chandrasekaran.”
Shimel: Fair enough. I don’t think I did that bad then. So, Prem, you are a software group leader at Barclaycard US, correct?
Chandrasekaran: That’s correct.
Shimel: Okay. And, well, before we get into it, let’s make sure that, in case people aren’t familiar with Barclaycard, who they are and what they do, if you wouldn’t mind just giving us maybe a quick little background on that.
Chandrasekaran: Yeah. So Barclaycard in the US is a credit card provider. Our primary business is co-branded credit cards, so, for example, when you’ve got an Apple credit card, if you look carefully, it actually says “Barclaycard” on it, in the background somewhere, but we’ve got a whole bunch of partners like that and we provide credit card services for our partners and customers through the co-brand. We also have a consumer lending business, which is a lot recent, but the credit card business is what is our primary revenue _____ _____, if you wanna look at it that way.
Shimel: Very good. And, Prem, in your role as software leader, what exactly does that mean? ‘Cause it means different things in different orgs.
Chandrasekaran: Yeah, yeah. So my actual title is that of a vice president, but, you know, what I was hired to do was to incept this new line of business. We were coming up with a new line of business called “consumer lending.” And our infrastructure, both hardware, software practices, all of those were on a pretty old legacy system, and we had two choices. One was that we would build on top of the legacy system or create a new platform, as we wanna call it, have all of the modern techniques that we use, including CI/CD, a lot of XP factors, and so on.
And I was brought in as a consultant first when I took the role on full time, two years ago, to lead the launch of that new consumer lending business. And I’ve been doing that. And now we’re trying to apply the same processes, software, hardware, all of those solutions, onto the credit card business, as well as we try to migrate.
Shimel: Excellent. And how long has this project been ongoing?
Chandrasekaran: Consumer lending started somewhere in 2015 and we launched at the end of 2016. It’s been live for the last 18 months or so. And what I’ve been doing after that is, again, I’m still in charge of making sure that consumer lending runs in production, but we’re also building what we call a “global platform” – basically, a set of design patterns and application templates and CI/CD pipelines to allow us to create new services, migrate existing ones, and develop what we call the platform –
Shimel: Oh, sorry. Go ahead.
Chandrasekaran: Yeah, so what I’ve been doing is we’ve been defining the learnings from what we did for consumer lending and making it available to development teams here, so that they can focus more on the business-logic portion of things, solving real problems, as opposed to grappling with a whole bunch of the surrounding stuff, nonfunctional stuff like log-in monitoring, CI/CD pipelines, tracing, and authentication authorization, and so on and so forth.
Shimel: Correct. So, Prem, I didn’t hear you mention security or cyber security, though, and that’s obviously something that’s important anytime we talk about financial services. Where did that play in, in the program here?
Chandrasekaran: I mean, we like to think that it’s something that starts with the code that you write, you know, so we make sure that all of our developers and teams think about security right from the ground up. And we have tests, both static and dynamic and penetration test frameworks, which check the state of the code that you’re developing from a security perspective, right through the CI/CD pipelines. And you’ve got a whole bunch of automation and a bunch of manual penetration tests that the teams do, to make sure that we are producing things that are secure not only for ourselves but also for our customers.
Shimel: Got it. So, Prem, let me ask you a question then. What I think is interesting is this was a project that, as you said, started in 2015, and here we are, 2018, talking about some successes you’ve had. And now rolling some of the lessons and learnings and success from that throughout other parts of the organization. And that actually – no two DevOps transformations, no two experiences, are exactly the same, but that’s right in sort of the sweet spot of how we see DevOps expanding within an organization. You get a project and many people are surprised that, in spite of the speed and automation that we think about in DevOps, it actually takes time. It takes time to launch a project. It takes time to bring a project to market like this.
But, once that’s done and you have good results, part of that DevOps way, if you will, is to take the feedback loops, take the learning, take the lessons learned, and apply them in other places within the organization. Prem, what about executives sponsorship of this, if you will? I mean, you’re a group leader, but, above you, what kind of buy-in or sponsorship did you have from your exec team
Chandrasekaran: Oh, absolutely. I mean, without exec sponsorship, I don’t think we would have progressed to where we are. I mean, we’re by no means done, but, you know, we are still in this journey and we’ve got a very solid leadership team which basically said that we need to operate not as a traditional bank, but as an IT organization, rivaling the best in the world, right? And that’s where we want to be. And it starts from there. And it percolates pretty much every single facet of our organization, starting form hiring to the way that we think. Basically, you know, DevOps is really a means of shortening the cycle of getting a product out of the door reliably and repeatedly, right?
Shimel: Yep
Chandrasekaran: So it does take a huge amount of effort in terms of the automation and the processes that we need to put in place, but, yeah, I mean, we’ve got very strong support from our leaders to help us transform the organization that way.
Shimel: Okay. So, Prem, let me put you on the spot here a little bit. We have listeners out there saying, “Wow, this guy’s done a project where they did this,” right? If you could – and we didn’t discuss it, so I apologize for putting you on the spot – can you give our listeners sorta three things they should avoid? What were the three biggest lessons you learned in the course of this project?
Chandrasekaran: Yeah, so, okay, I’m gonna try to look for three things, right? Okay, so the first thing that comes to mind is that, at least at a place like where we are, in a bank, right, buy-in is very important. So you might have buy-in from the top, but you need to have buy-in from pretty much every facet of the organization, that automation isn’t a threat to their jobs and existence, right?
Shimel: Mm-hmm.
Chandrasekaran: Where, you know, it’s normal that now our time and operations person – “Oh, my job can be automated and now I’m out of a job.” Right? That’s one thing that it’s largely a psychology thing, where you have to address that and give people the confidence that that’s not the motive here. The motive here is to churn out software fast and enable both DevOps, business, QA, information security – I mean, you name a whole bunch of these groups – it’s about collaborating and working closely together to achieve the end, which is putting out software solutions for our customers and our stakeholders repeatedly and reliably, like I said before. That’s one. It’s more of a mental shift that needs to happen. And, unless you do that, you’re going to meet with a lot of resistance.
The second thing is in terms of who you hire, right? Like I said, it’s a mental thing. It’s a philosophy where you need to have likeminded people who want to do the automation, as opposed to doing something that’s manual and error-prone, right? So hiring the right kind of people definitely is second.
And, third, it also needs your business folks to be patient while these transformations happen, where you might not see the benefits of it on day two, right? It takes a while for the benefits to start appearing because it does take a lot of practice. And we’re not there yet in terms of saying that we’ve achieved perfection – I guess nobody can say that – but it does take a few patient stakeholders as well. I mean, those are my three things.
Shimel: Excellent. So, you know, Prem, when we started, I said the 15 minutes go quick – we’re wrapping up here – but, again, for our listeners who maybe are contemplating or in the throes of their own DevOps journeys, I mean, this is certainly a success story to date. What else – I mean, what’s next here, though? Beyond what you’ve already mentioned to us?
Chandrasekaran: Yeah, you know, so, right now – I mean, our next step is to scale this out, right? I mean, we’ve got one product line that is using all of these, and a bunch of the rest of the organization, at least here in the US, has drawn a lot of inspiration from the successes that we’ve gained here. You know, we still operate in a private-cloud environment. We’re targeting going to the public cloud, which basically means that we now allow ourselves to scale a lot more quicker and a lot more faster. So, yeah, I mean, that’s probably the next step, where we’re targeting the public cloud and provide value to our business and customers a lot more quicker that way.
Shimel: Excellent. Excellent. Well, Prem, thanks so much for giving us a little bit of insight into how Barclaycard US has leveraged DevOps here and has started out on their own DevOps journey. We’d love to hear more about it in the future; maybe we can check in.
Chandrasekaran: Yeah. Thank you very much, Alan, for having us.
Shimel: Okay. Prem—and I’m not even gonna mess it up or attempt ’cause I will mess it up—Prem, thanks so much for joining us here on DevOps Chat. This is Alan Shimel for DevOps Chat and we hope to see you soon on another DevOps Chat. Have a great day, everyone.
This DevOps Chat features “the CEO’s view” as seen by XebiaLabs CEO, Derek Langone. Derek is one of my personal favorite CEOs in the DevOps space because he is very articulate, to the point and sharp. I think all of these characteristics come through in this DevOps Chat. As CEO of XebiaLabs, Derek is leading one of the leading companies helping transformations in enterprise DevOps. In this chat, Derek talks about with us about cloud and cloud migration.
As usual, the streaming media of our conversation is below. The transcript of our conversation follows below that.
Audio
Transcript
[su_pullquote align=”right”][su_custom_gallery source=”media: 122032″ link=”post” target=”blank” width=”200″ height=”200″ title=”never”]Derek Langone
Derek Langone has been the Chief Executive Officer of XebiaLabs, Inc. since April 21, 2015. Mr. Langone served an Executive Vice President of Global Sales at Telerik, Inc. since February 2014. Prior to Telerik, he served as the Chief Executive Officer of 5nine Software where, in less than a year, he significantly increased revenue, lead generation and conversion rates. He served as the Chief Executive Officer, President and Chief Operating Officer of SmartBear Software, Inc. (also known as AutomatedQA Corporation). He served as the President and Chief Operating Officer of SmartBear, Inc. He began his career on Wall Street focused on technology investing. For over 15 years, he has focused on building and scaling Technical Sales Organizations. Prior to SmartBear, he served as Vice President of Sales at Quest Software and IMCEDA Software. He held senior Sales Positions at Vality Technology, (now IBM), Embarcadero and SAP America. He is an Industry Veteran, has more than 15 years of expertise in cultivating enterprise IT and application development adoption. He has been a Director at XebiaLabs, Inc. since April 21, 2015. Mr. Langone holds a Bachelor’s Degree in Business Management from Boston University.[/su_pullquote]Alan Shimel: Hey, everyone, this is Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps chat. Happy to be joined today on DevOps chat by Derek Langone, CEO of Xebia Labs. Hey Derek, how are you
Derek Langone: Alan, I’m excellent, thanks very much for having me today.
Shimel: Thank you. Just a heads-up to our audience, I had been working on this for a long time. Derek’s agreed to be sort of a regular guest here on DevOps Chat and we’re looking forward to hearing from him, oh, maybe once a month or so on topics that are of interest to hopefully our whole audience so you know they’ll be around DevOps and related to technologies.
So, this is the first one we’re doing and we were going to talk today a little bit about cloud and whether you already are a cloud customer or new to the cloud, how can DevOps and related technologies help you.
But before we do, Derek, in case there’s anyone out there who maybe is not familiar with Xebia Labs, you want to give them a real quick kind of pitch on Xebia Labs and what you guys are doing?
Langone: Sure, here’s the 30-second commercial. So, Xebia Labs is entirely focused on enterprise DevOps. We provide a software platform for large enterprises that encompasses three primary components, released orchestration so basically create your pipelines in our technology that are templated, repeatable, standardized, use our automated deployment engine which is a model-based agentless engine.
And then lastly, we have a machine-learning and AI-oriented reporting engine that collects all the data associated with your journey from development to production. It allows you to report on that for things like compliance purposes, regulatory purposes, security, and just a good old-fashioned scorecard – am I going faster? Is my quality up? Are my customers happier?
Shimel: Couldn’t have asked for more than that in 30 seconds, Derek, thanks. So, here’s the deal, we are approaching I think this year a threshold in cloud adoption where it’s something like 50 percent of enterprises will have significant infrastructure in the cloud, not just a toe in the water or an R&D project, but significant infrastructure in the cloud.
And that’s big, right?That means half of all enterprises have a large investment in cloud. But it also means half, don’t, right? And that’s always the flip side of the coin. I want to talk today to both of these audiences but let’s first start with the half that already has, right?
They’ve invested a lot time, a lot of money, probably a lot software or tools and personnel, but maybe they’re not getting everything they need out of their cloud deployment? How can DevOps help?
Langone: Well, DevOps by principle is sort of an accelerate opportunity, right? And if you look at a cloud investment, it’s a similar value proposition that you don’t have the requirement to manage this infrastructure, you’ve got less administrative overhead, you’ve just got on-demand, scalable infrastructure. So, that’s all oriented around speed.
The challenges we see with our customers that are generally large enterprises, the biggest banks, insurance companies, airlines, in the world represent our customer base. They’re moving aggressively to the cloud because it’s just generally less expensive and certainly much less administrative overhead.
But the consequences, the applications they’re trying to get there are very complex and don’t necessarily lend themselves to moving to the cloud very neatly. And what I mean by that is if you use an example like a large bank might have a money transfer application, core to every business that’s a big financial institution.
That application lives in many places; the back-end horsepower may be a mainframe, there’s referential databases that do some validation every time there’s a query. You’ve got distributed architecture, maybe a containerized front end that gives you your mobile banking access and things like that.
Moving all of that to the cloud is not simple, it really requires an incredible amount of orchestration, some very sophisticated deployment functionality. And we see most of our customers when we get engaged, them trying to do that with either the simple tools that come with the cloud platform providers, you know, the out-of-the-box Amazon or Azure tool portfolio.
Or in most cases, just using the good old- fashioned, using extremely talented valuable developers to write tons of scripts to try to move these components around and shift them to the cloud. Neither of those initiatives are generally successful.
Shimel: And I think you just hit it, Derek. Those are the two ends of the dumbbell if you will, right? One is to use the vanilla tools that the cloud providers give you and not to bang anyone but AWS is notorious for this, right?
They give you 60 percent of the functionality at a really low, low price of some of the best __ tools but it comes bundled. Or you go the other way, right, just totally customize the heck out of things, which is not scalable usually, nor repeatable.
Langone: No, it’s not, that’s the challenge. And just to hit those two ends of the dumb-bell as you said, the tools that come with the cloud providers, I mean, look, they’re sort of minimalistic by nature because it’s not the core business that they’re trying to provide. They’re infrastructure providers, they’re really not deployment technologists, right?
So they’re gonna give you a little bit to get some basic applications there but anything complex is really gonna fall down. And like you said, the other side of it is, and the more traditional approach, is just using your engineering assets to write a ton of scripts to provision infrastructure, to migrate applications, to request instances.
You know, it’s just an incredible amount of plumbing code that gets written that is super low-value and basically comes at the expense of much higher value activities that those engineers could be participating in, things like building new features and fixing bugs and just basically delivering more customer value.
Shimel: And with that approach, Derek, to me it’s always been, well, what happens next month when I have to do this again? I’m gonna rewrite all the scripts, waste all that time? It just doesn’t make sense. But you hit on this with your opening, the reality is that most of these organizations who may already have significant infrastructure in the cloud are not totally in the public cloud certainly.
They still do have mainframes, they have stuff in the closet, they have stuff in the data center. They’re living in a hybrid world, right, Derek? And so for whatever reason, and I’ve heard this from numerous, they hate the idea of using one tool for their public cloud stuff, one tool for their on-print stuff, one tool for their private cloud. They want one throat to choke, right? They want one tool.
Langone: Well, I think they want one platform that can kind of account for the migration and IT landscape that they are going through, right?
Shimel: Yes.
Derek Langone:And that’s sort of what we’ve tried to build at Xebia Labs. We work with the legacy infrastructure and give you velocity, repeatability, standardization for your mainframe deployments in the exact same way that we will accelerate your journey to containers and leveraging Kubernetes and Docker as well as, you know, getting onto what is generally hybrid cloud infrastructure.
We definitely see large organizations leveraging things like Amazon but in most cases, they’ve got some combination of a data-center cloud that they’ve got under their own control, as well as the sort of less mission-critical applications or the things that don’t represent the family jewels if you will in true public cloud infrastructure.
And when I talked to CIOs in these organizations about their aggressive shift to the cloud, they look at me and say, look, we’re moving to the cloud with a lot of new development and some of the less mission-critical applications but the five apps that we run the bank on are gonna be running on mainframes five years from now.
That’s not changing. We can’t break them up into micro-services and they don’t lend themselves to refactoring. We’re gonna continue to just add, you know, additional workload front ends but for the most part, they’re gonna stay intact. And that just represents I think the reality in enterprises.
Shimel: And that is dead on the reality. And I just want to make sure we’re talking about tools like Xebia actually give these organizations the ability to use one platform across these multiple infrastructures.
Langone: Yeah, I mean, look, I don’t want to just plug our platform because there’s others out there, there’s others out there, but at the end of the day, yes, what we’ve tried to do is basically build the technology that can accommodate the mission-critical requirements of a large enterprise. So, not only have we baked in the ability to deploy any technology from any starting point to any destination including public cloud, private cloud, hybrid, containers, you name it, right?
We’ve also baked in all of the things that enterprises need to account for, like the compliance steps, the security steps, the who did what and when to the software reporting, so that all of these standards are met if you’re migrating to infrastructure that’s off of your own premises.
None of those business requirements go away. In fact, in most cases, they get a little bit more stringent as the security team start to understand that if you’re gonna move applications outside of the firewall of the organization, then we need to put even more validation steps and security procedures in place.
And again, if you’re doing this manually with engineers, they need to script for all of that activity and maintain it every time there’s a slight change in the application.
It just becomes 50 percent of an engineer’s day managing these scripts that were built to move applications around when they could be using that 50 percent of their day to do things that are much, much more interesting for them and much more valuable to the organization.
Shimel: Sure, I mean, and again, we’re not tooting Xebia’s horn here but you know what, Derek, from a manager-executive point of view maybe listening to this, knowing that there are tools like that that will allow them to go across these different infrastructures, single platform, is important. I mean, that was always one of the big inhibitors.
Langone: No, you’re absolutely right, and look, what we’re tried to build into our platform is this templated approach. We have a model-based architecture, it’s agentless so you create templates and every single application that you have to move from development to production follows one of maybe three or four templates.
And we’re talking 3 to 4 templates account for 500 different applications, whereas the alternative is you’re basically hand-scripting 500 different paths to production. So it’s much easier to maintain, it’s centralized, it’s controlled, there’s reporting, there’s visibility, there’s sort of all the things that you need to be able to score your process for migrating applications, whether it be to the cloud, the containers, or just frankly, to an existing data center.
So, that’s really an important consideration. The other piece to consider, and again, a place where we’ve put a lot focus in our platform is leveraging what you’re doing already. So, we are a part of the process but you’ve got provisioning tools, like Puppet and Chef, you’ve got service ticketing, like Service Now or Gira, Jenkins on the CI side.
A lot of technologies are required to move applications from one destination to the next, so we integrate with all that infrastructure that’s already running right out of the box, and we basically allow you to pick best-of-breed components so that you’re not locked into one specific vendor. And that’s been a lot of the feedback that we get from our particularly big financial services customers.
They like the fact that if they want to switch cloud providers on the fly and move from Amazon to Rat Space or from Rat Space to Azure, they can do that with changing one configuration file in our product rather than having to rescript everything from scratch to reach a new destination.
So, it really comes down to you avoid vendor lock-in, but when you want to make a pivot, that pivot in our technology and our platform takes five minutes versus months of scripting.
Shimel: Months, exactly. So, Derek, let’s make our own pivot, let’s talk about the other 50 percent of companies that aren’t moving major infrastructure to the cloud, or big parts of their infrastructure to the cloud. Let’s first of all say should they? Should they feel they’re getting left behind? Is it fatal to their business? What’s your feeling?
Langone: You know, I think every IT organization makes choices that line up to the business objectives of their firm. I wouldn’t say that the shift to cloud is mandatory. There’s certainly a strong value proposition associated with it. It’s very, very expensive to keep technology infrastructure fresh. That’s always been the issue.
You could build the data center but then, you know, 18 months later, all the technology in there is sort of out of rev, right? So you’re forced to buy it over and over and over again versus the cloud providers. You’re certainly paying the rental fee and that rental fee can be steep but you’ve always got state-of-the-art infrastructure to work against, and that’s just a very compelling argument.
The other pieces, the administrative element goes away so there’s less people required to maintain it because it’s getting maintained for you. But the majority of our customers are moving to the cloud but for specific reasons and with specific applications, right? They’re not just wholesale-lifting their entire application portfolio to the cloud because it’s just not practical.
So in the cases of customers that are still on premise, and that’s still the majority of large enterprises, I am not at all a cloud-denier. People are moving there and moving there aggressively, but when you look at large enterprises, I think your number was 50 percent are using and 50 percent are not.
My on the ground sort of feeling is it’s less than 50 percent that are aggressively using the cloud for many different reasons, not the least of which are just security concern that still sort of haunt these large organizations. But the fact is anywhere your applications reside, right now DevOps is a good investment.
Being able to increase the velocity at which you can build technology and deliver value through software to your end users is sort of a fundamental requirement nowadays in order to stay competitive in your own given space.
So, we help with velocity, like I said earlier, on mainframes distributed technology, legacy systems, building a repeatable standardized release and deployment process with all the reporting that you’d expect to be able to identify where you’ve got areas of friction that can be remedied.
So, we sort of approach with the same – our approach is the exact same whether it’s a legacy application or a nimble application that’s being written in containers to run in cloud infrastructure.
The templates are the same, the mechanics of how you release and deploy those applications is the exact same.
So, the beauty of our platform becomes anybody can use it, it’s understood, it’s centrally managed and it scales infinitely versus writing code which just is difficult and impossible to maintain over time.
Shimel: Sure. So, Derek, you brought an interesting point up though and it was one that I wanted to hit on. And that is, look, for those who are just moving to cloud, right, there’s a choice to be made. Do I take my inherited legacy, not so much infrastructure as much as my legacy stack and just port this existing stuff to the cloud?
Or do I really just bite the bullet in Greenfield, right? Like, my stuff hasn’t been built on containers, maybe it wasn’t even built on hypervisors and virtualizations – who knows? But you know what, if I’m gonna move to the cloud, the heck with it, I might as well containerize and take advantage of micro-services and all of this.
But my goodness, that’s such a major, you know, throwing out babies with bathwater potential. What’s your advice to companies faced with do I just port my existing architecture, or do I go for broke in more ways than one and adopt the new stuff?
Langone: Yeah, I’ll tell you, in my experience, and I wouldn’t want to give advice ’cause every company sort of has to line up against their business objectives. But what I will tell you, what we see most often is people threading the needle, right? Basically taking these monolithic applications and starting to build components of those applications in containers on sort of more nimble infrastructure.
You know, a good example, as I mentioned earlier, a money transfer app, right? That’s a legacy application that’s been running in a big bank for 25 years. The horsepower on the back end that does all the computations is still a couple of IBM mainframes strung together. But you’ve got referential databases that are living in distributed architecture maybe onsite, maybe offsite in the cloud somewhere.
You’ve got containerized and mobile-centric front ends so you could do your mobile banking, web banking, things like that. So, that application lives in a lot of different places and you can, with some small investment in more nimble development platforms and infrastructure on the front end, really energize and give life to these legacy applications.
So, there isn’t a need to move the entire thing to the cloud. You can move components of it to the cloud, but again, when you do that, you get the benefit of the faster architecture and the ability to deliver value through your software more frequently for your end users.
But the consequences, getting those components to the cloud becomes really complex and that’s where our technology really lends a hand, where we understand those complexities, we’ve accounted for them already.
We do this sort of every day for the biggest banks in the world so you can take advantage of not having to reinvent the wheel and still get the benefit of the velocity that you’re looking for and the flexibility you’re looking for in these applications that need to live on.
Shimel: You know what, Derek, that was one of the best examples of hybrid cloud that I’ve heard. I think for too many people they think of hybrid cloud, they say, well, this application lives in the cloud, this application lives on my mainframe, this application lives in a data-center, my payroll system is here, my HR system is there, but that’s not really hybrid cloud.
Hybrid cloud is we have one application that different elements and components of it live in this hybrid world, right?
Langone: Yes, I think there’s a misunderstanding that you’re either in the cloud or you’re not, right? The fact is, I think, that in most cases, most of our clients, you’ve sort of got one leg in both places.
Shimel: Yeah, at the same time.
Langone: You’ve got I’m somewhat in the cloud, and they make decisions relative to where can I get the biggest bang for my buck? Some of this application needs to be in the cloud for a bunch of reasons so let’s do it, and then we’re just not gonna forklift up our mainframe apps and dump them on AWS. It’s a cost-ineffective strategy; we’d have to refactor them like crazy.
So, yeah, and I don’t think that trend is gonna change, right? There’s certainly a bunch of Greenfield development that’s going on, containerized apps micro-services, just cloud-centric development. And that’s great but that represents generally less than ten percent of the application portfolio in a large organization.
And that’s the fact is that 90 percent of the apps have been around for five years or longer, and those apps are critical to the business.
And they, over time, will migrate to the cloud and be refactored and rewritten.
But it’s just too big of an endeavor for any large company to take a 1000-application portfolio and say, hey, this year we’re going to rewrite all these for the cloud. I mean, I don’t know anybody that’s doing that.
Shimel: I would hope not. Hey, Derek, I think I told you before we started, time goes really quick here. We’re at maybe 25 minutes now, we were supposed to be 15, so we could probably talk about this all day, but we’ll continue the conversation on our next visit with you.
But, hey, this was great, Derek Langone, CEO, Xebia Labs. Thanks for being our guest on DevOps Chat today and we hope to have you back real soon here.
Langone: Thanks, Alan, talk to you soon.
Shimel: All right, this is Alan Shimel for devopsy.kinsta.cloud, we’ll see you soon on another DevOps Chat.
In this DevOps Chat we speak with Jim Gochee, Chief Product Officer, New Relic. In his role at New Relic, Jim has seen years and years of evolution in digital transformations. Jim and I spoke about a number of topics including about how to succeed with DevOps, the rise of SRE and APM. Great discussion all around.
As usual, the streaming audio of our conversation is below, the transcript follows that. Enjoy.
Audio
Transcript
[su_pullquote align=”right”][su_custom_gallery source=”media: 122025″ link=”post” target=”blank” width=”200″ height=”200″ title=”never”]Jim Gochee
Jim is New Relic’s Chief Product Officer, overseeing the teams that design, build, and deliver New Relic’s products. He has a passion for building world-class products and loves technology – especially when it’s well architected, scalable, and fast. He takes great pleasure in helping New Relic’s customers analyze their technology and build great digital experiences. Prior to New Relic, Jim was the Chief Architect for the Wily Technology division of CA, where he was the technical lead for Introscope, an industry-leading web application performance monitoring solution. Prior to that, he was Chief Technology Officer for an internet-based trading system for the wholesale food industry. Jim also spent four years at Apple, Inc. and three years at Connectix Corporation working on VirtualPC. He holds an A.B. in Computer Science from Dartmouth College.[/su_pullquote]Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud and you’re listening to another DevOps chat. Today’s DevOps chat features Jim Goci of New Relic. Jim, welcome to DevOps chat
Jim Gochee: Hey, Alan, how are you? It’s good to be here.
Shimel: Thank you, it’s good to have you here. So, Jim, let’s get some stuff out of the way here, a little housekeeping. What exactly is your role at new relic?
Gochee: Yeah, Alan, so I oversee all of product development and that includes engineering, product management, design as well as operations. So pretty much the whole shooting match.
Shimel: Fantastic. And Jim, I was talking to you off-mic before we started today, we haven’t done a good job frankly of covering New Relic at devopsy.kinsta.cloud but when we first launched, which is going on five years ago, New Relic was already a well-established player in the DevOps market and is certainly even more established now.
But why don’t you give our audience maybe just a quick little history to bring us up to where New Relic is today.
Gochee: Yeah, absolutely. We’ve been around actually for ten years, Alan. So we just had our tenth-year anniversary party just a couple of weeks ago if you can believe that. So, 2008, and when we started, we were focused on Ribyon Rails, monitoring the backend services, grew the product portfolio over time to include other languages.
But mostly sold to small companies, startups, companies that got bigger like Air B&B. But really, it was a couple years ago we started to pivot more into the enterprise and that was a very exciting time for us.
We were already getting pulled into bigger and bigger companies at a project level and then we found ourselves being kind of drawn in organically to more and more groups to the point where these big companies were wanting to have more of a formal relationship with us, from a sales perspective.
So we built out an enterprise sales team and have been really focused there. So maybe, in one way, while you haven’t seen a lot of us in the last couple of years as we’ve been pretty heads down, focusing on the needs of the enterprise market. But what I’ll also say is we’ve been releasing a lot of product as well in the last a couple of years and the biggest thing that we did is we rounded out our offering to include an infrastructure monitoring component.
And that really complicates, not complicates, but it complements our offering at the application layer as well as the end user layer. So at this point, we have a pretty comprehensive portfolio of offerings that cover that full stack.
Shimel: Very cool, very cool indeed. So Jim, I would imagine in your role around product and everything you’re doing at New Relic, you get to talk to more than a few customers, yeah?
Gochee: Well, I do and I just feel so blessed, Alan, because this is an incredible time to be in technology. So I’ve seen a few really interesting times in tech. I think the first was when the Internet really started to get mainstream, back in the mid-’90s, but what’s really interesting now is this thing that you hear a lot about which is digital transformation.
And we all feel it, which is we want a relationship with the companies that we do business with, we want a relationship via our mobile phones or the web browser. And so a lot of companies are trying to figure out how do they have that new customer relationship, right? And how do they come up with new ways of engaging with their customer?
And then, of course, again, companies like Air B&B completely rethinking business models, companies like Uber, and so it’s just a really fascinating time to be in the tooling space that supports and assists a lot of these digital transformations that are going on. So, yeah, we definitely see a lot of interesting things.
Shimel: Excellent. So, Jim, one of the themes that we have run into here recently at devopsy.kinsta.cloud is this idea that somehow people thought digital transformation and DevOps transformation was gonna be easy. And they’re a little bit taken aback.
You know, you speak to them, the first kind of foray into it it’s like, you know, this is hard. And I feel like saying no one promised you a rose garden, right? If it was that easy everyone would be doing it already. Are you seeing any of that?
Gochee: Well, you know, Alan, in fact, we do see a lot of that but I would say is this, I guess I see the full continuum. I see the early adopters and the enterprise to DevOps. I mean, DevOps, you guys have been around for five years and we’ve been doing it for 10 and it’s early to do when you start a company that way.
In other words, when you start a company and you have a DevOps organization already, it’s easy to grow and keep doing that. But when you’re a traditional enterprise and your operations team is very siloed from your development teams, to bring those two together is a pretty big task, right? And you hear a lot about the cultural challenge involved, and that’s very real.
The thing I’d like to ask, the question I ask when I go into one of our customers and I’m not familiar yet with really where they’re at in the journey, I ask them one simple question. Who takes pager call? And if it’s still the operations team that’s taking pager call, then normally they’re still complaining that the developers don’t care, the developers are very isolated, and you see those silos still in place.
And it’s really not until a development team, then with the help of operations, people like SREs embedded on that team, it’s really not until that happens where I would really see the crossing of the chasm into more of a true DevOps model.
Shimel: Absolutely. You know, you mentioned SREs, Jim, and that’s another area where we’re just seeing it, man, it’s blowing up, right, in terms of companies hiring SREs, incorporating SREs on to their ops team. Many people have gone as far to say SRE puts the ops in DevOps. What are your feelings around the SREs and that?
Gochee: Well, what I like about the SRE role is Google wrote a book about what they believe it is. And so while that probably just applies to Google and nothing’s ever as perfect as it seems, they clearly define these are the things that this role does.
And this is why these things are important, and it’s a real philosophy and it’s a real mindset, and they wrote it down and these are all things that other people had been doing in various ways. But I think the SRE role, it got really clarified what exactly it is.
And so I am starting to see this more and more as well, and it’s not like SRE is a new concept; again, Google’s been doing it for a very, very a long time but I just feel like it’s kind of catching on.
I can tell you ourselves we’ve been doing DevOps for a long time but just in the last year, we’ve really formalized around SREs as well and we got a vice president of site reliability engineering, we converted people’s titles over, we got really crisp about exactly what are you doing.
We’re trying to figure out right now whether central versus embedded or a hybrid of the two approaches, so you know, how to organize SREs and how do they really attach into development teams? There’s still plenty of work to do even that we’re looking at, but I think this is helping the industry really figure out a model that they can work with.
Because that’s the biggest thing I see, Alan, is people want to transform to be more agile into DevOps and to use the Cloud, but they don’t really know how to do it, right? They don’t really have a good playbook for it yet.
Shimel: I agree with you 100 percent. It’s interesting you guys are eating your own dog food with that.
So, Jim, in many ways, New Relic, sort of, if you will, pioneered what we call APM, you know, and we recently did—it got too big but it was a DevOps tools primer, just trying to at least draw it so that the taxonomy of categories—and certainly APM, but APM itself has become so intertangled in this whole software development life cycle. Is that still where New Relics thinks they play?
Gochee: Yeah, so it’s a great question. We like to say that we’ve democratized APM; in that, we created a service that anybody could subscribe to, download our agent, install it into an application code, relaunch your application and now you’ve got your data showing up on our screens.
The technology around APM, though, has been around a lot longer but we were the first to bring it to everybody in a very transparent selling model, right, and again try it before you buy it. And we have by far, in a way, the most users in this APM category. These categories are funny things though, yeah, applications here but there’s also end user, there’s synthetics, now there’s infrastructure tier.
It’s all kind of collapsing and probably the markets sort of get renamed after a while. One of the things that we like to say that we think we have is a digital intelligence platform, digital intelligence just means data about everything that’s part of your digital system, all the code running, all the infrastructure that’s running.
And so at the end of the day, if you want to be agile and deploy a lot code and make a lot production change, you need to have data that tells you that things are still working correctly about all the different pieces of your infrastructure, right?
And without that data, you’re flying blind and so, flying blind, it’s okay if you deploy code once every six months, you can fly blind for a little bit while you sort out any issues. But if you’re deploying code every day, you’ve got to have real-time data about what’s happening in order for that to be successful.
Shimel: Sure do, sure do. And Jim, when we talk about the move to the enterprise, I think that’s one of—not that startups or non-enterprise customers don’t use data or that they do fly blind. They don’t. That’s not the case at all. But when you go to the enterprise and you start thinking about enterprise-class functionality, right, is when you start realizing what—really, things have got to be locked down, right?
There’s got to be sort of—I mean, sometimes it can be overprocessed and overcomplicated but you can’t just fly by the seat of your pants as much. And I think products like New Relic, they can’t help but bring some of that regimentation to a company.
Gochee: Absolutely, no, I mean your point’s really well-taken. When you’re a smaller company, you can take more risk, you don’t have to do things the right way, you know. That’s common. When you’re bigger company, you have a lot more experienced people who are used to having better tooling, better processes, better governance, right?
Because there’s a lot at stake. I mean, these are some of the largest companies in the world who are betting their future on their digital projects, and those projects have to function and they have to work. So, I don’t know, can I tell you one story, Alan?
Shimel: Sure.
Gochee: It’s a few years old now but do you remember when healthcare.gov first launched?
Shimel: Yes, I do.
Gochee: It first launched and the thing didn’t really work. It was hung and broken and the president was like apologizing to the nation, right? This is an example of we looked at each other and we’re like this is the highest-profile example of a web project gone awry.
Shimel:[Laughs]
Gochee: Yeah, right, I mean the president has to apologize for poor web performance and –
Shimel: At least we had a president who apologized then, but go ahead.
Gochee: That’s another story altogether.
Shimel: That’s a whole other story.
Gochee: The president brought in a team from Silicon Valley to help fix that site. I forget Mikey’s last name from Google. Anyways, they brought New Relic in and then we gave them the data to help sort that out, and then from now on, we have been the tool of record for how that system has been performing. And they’re just 1 of 15,000 customers that we have.
Shimel: Interesting. But that’s a classic example of it, too. That was done probably, frankly, without the necessary requirements in laying it all out there. Jim, let me ask you a question. From your catbird seat, what do you see at the future of the market here?
Gochee: Yeah, so just in terms of digital transformation and digital customer experience, that’s absolutely gonna be powering the whole economy and tech sector in particular for the next five to ten years. Cloud, the move to Cloud, the opportunities you can get by some of the Cloud services.
In particular, Amazon is really blazing the trail in just the sheer number of services they offer the market, changing how people can build and deploy software, it’s incredible. So we see a continued explosion in software and digital experiences, and then that drives companies like us, we offer tooling in this area that really helps companies move more quickly, have a better customer experience. And so I mean, I think the whole category of tech and DevOps and Agile and tooling, observability is a trend, SREs, all of this is gonna continue to have a lot of strength and a lot growing over the next five or ten years. I just absolutely believe that.
Shimel: Excellent, Jim, as I mentioned to you, when we first got started here, 15 minutes goes really quick. I think we’re probably closer to 20 at this point but it’s okay. Maybe we can have you back on here at New Relic and a DevOps chat because we would like to stay on board with everything that’s going on there. But in the meantime, thanks for being a guest on this episode of DevOps chat, Jim.
Gochee: Alan, it’s been enjoyable, thank you so much for having me. I’m happy to come back on as well
Shimel: Absolutely, we’ll make you a regular. Hey, that was Jim Gochee, Jim runs products and a bunch of other things over at New Relic and this was another episode of DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud. I hope to see you soon on another chat soon, everyone. Take care.
