Analyst Chat #60: The 2021 Trends in DevOps and Security

Welcome to KuppingerCole analyst chat. I'm your host. My name is Mathias Reinwarth. I'm an analyst and advisor at KuppingerCole analyst's and my guests today is Paul Fisher. He's an analyst with KuppingerCole working out of London. Uh, hi, Paul.
Hi Mathias. How are you? I'm Fine. Great to have you again. And I hope you're doing well as well. I am. Thank you very much. Great. Um, today we want to talk about trends. We want to talk about, um, an area where, uh, things are changing rapidly and we are at the beginning of 2021. So we want to talk about, um, the dev ops area. So some, some developments, some trends that we are seeing in the market. And of course we want to have a look at it with a slight twist towards security and identity and access management. But first of all, what is one of the most important trends that you are seeing in the area of DevOps right now?
Well, one, uh, a phrase that keeps coming up in my reading and my desk research, uh, particularly in the last sort of six months or so that doesn't mean that it's only happened in the last six months, but, um, it's just when I've become aware of it. And that's probably because I've been working on, uh, Pam, uh, for dev ops. Um, and that's a thing called infrastructure as a code, which in a way, sounds a bit like what, I don't know if you remember it was software defined networking, which people spoke a lot about a few years ago, but what, what seems to be is instead of infrastructure being, uh, a lot of 10 and alert and networking and all strung together, um, we're now having infrastructure, which is defined purely as code, uh, which should in theory, make it much easier to roll out by TJ to upgrade and, um, cheaper to run.
And of course the, the key tool that is, I imagined it would run in the cloud. So dev ops people are, uh, it seems now being encouraged to, to create stuff for infrastructure as a code, um, in terms of what my questions are obviously, um, what does that do or what does that mean for the security of all this and what steps are being taken to ensure that infrastructure as a code, uh, sorry, as code is as secure as it can be. And if you have any code lying around in the, in the cloud, uh, as we all know that is, uh, vulnerable to attack and vulnerable to theft. So I think we're going to be hearing a lot more about infrastructure as a code, uh, this year as we move into hopefully the post COVID period, which is something we're all looking forward to it.
So that's, that's one thing that I, I think, um, we should be hearing a lot more about it, in fact, not just dev ops, but it will affect, um, identity and it will affect, um, privileged access management, um, and computing, or should we say organizations in general? Um, I think the attractions of infrastructure as a code is, is reduced costs, um, because you don't have to have so many people involved in creating infrastructure. Um, it's also something that is scalable much more scalable because you're talking about code that something that can be, uh, scaled a lot more quickly than physical hardware, et cetera.
Right. And I think if we, if you just look at the, at the two components of the term dev ops, and we look at infrastructure as code, so there are different tasks and different responsibilities when it comes to the developer, so they can create infrastructure on the go while they are working so they can create different instances and maybe a testing environment, um, on the goal just by writing and executing code. On the other hand, as you've mentioned, them operations also can highly benefit from that. And it always gives the chance to, to, to provide infrastructure at the scale at the scalability as required. But also you can, um, make sure that you, that you freeze, uh, well known and known as secure, um, the definition of that up that infrastructure and fall back on that and reuse it and scale it up. So this is really if done, right? Uh, and you've mentioned Pam for DevOps. I think that it's really important and it's important for the developers because they need to secure their technical accounts, that service accounts that are embedded in their infrastructure as code and the same is true, of course, for the, for the operations people who need to make sure that their access towards this infrastructure as code in the cloud or wherever, um, is properly secured. And I think that's identity that's. Um,
I think, I think also, um, that the attraction of infrastructure as a code is, uh, like you say, the speed and the fact that you can roll back, uh, to a previous version very easily, for example, um, but like anything in DevOps. And I think that's why the Pam vendors are, are, um, taking it very seriously is that you have to still ensure that while dev ops are allowed to do all these great and crazy things and create infrastructure like this, and then create other applications, um, that they are managed and that the, the code and the secrets that they need to do all this stuff are protected. And that's where Pam and identity and access management come in. So, um, and I think infrastructure is code is of interest, particularly to perhaps, uh, manufacturing companies, automotive companies that, um, are under pressure to develop new products, like never before, you know, there'll be before you could launch a car and it would mostly be judged on its mechanical features, its mechanical performance. Now it's increasingly going to be judged on its software performance and how that software can squeeze better performance out of batteries and how it connects with, um, other cars and how it connects with edge devices. So being able to create infrastructure for that sort of thing in this way is hugely important, but it has to be like I say, it has to be secure.
Exactly. And then your last sentence, it has to be secure. Um, we, we, we did some episodes around this area already. We talked with, with Alec, say about the citizen developer who is working most properly also in the cloud. And of course also adding this sec to DevOps, is this something that you see when you're doing your research in the market? So this dev SecOps adding security to the DevOps tool chains, is this important?
I think that dev sec ops or sec dev ops is a bit of a misleading term. And I think it was in probably invented by the, the, the market to, to sell, uh, security products. I don't think there is really anything called or DevSecOps that works or, or sec dev ops, whichever way. I can't even remember what I said now, dev ops dev ops. Um, I think that security purely is, must be built into dev ops operations and the people responsible for doing that are not going to be the people that work in dev ops. They're going to be the managers around them. They're going to be the CSO, the people that need to take that holistic view of security for the entire organization. So I really, I obviously think that security is going to become, um, an integral part of, uh, software development. Um, but it will be done through the decisions of CSOs and through to decisions of other it people who then make the choice of what technology to buy or what platforms to buy, to enable secure DevOps.
Um, and again, it comes back to things like privilege, access management. Um, I an increasingly see people starting to talk about, uh, secrets management more than, uh, this is another thing that I predict will happen not overnight. Um, I've noticed there's already, uh, within the sort of Pam community, if that's what you want to call it. Um, w w we're shifting from what I mean, we've gone from privilege account management to privilege access management because, uh, it seems old fashioned now to talk about privileged accounts, um, to secrets management. And I think that's, that's, uh, an important change because it's not so much people have privileged accounts or they have privilege access, they have access, or they need access to things that are secret or that if they fell into the wrong hands could, could do harm to the organization. So I think we're seeing a shift now between, um, you know, the old idea of privileged accounts, where for admins to do privileged things to users, right across the spectrum, um, including people that are now used to working from home on the endpoints, et cetera.
So we're going to see the shift towards, um, managing secrets or managing privilege so much more than having a privilege account. I don't, you may, one day be doing, you may work in DevOps and one day you need access to particular tools or you need access to some code, or you need to access to containers, whatever it is. Um, the next day, you may not, therefore you don't, you don't always be a privilege user. Um, you just become someone who, um, is a privilege, you know, a consumer of secrets. Um, and when you need those secrets, you have, you need to go through zero trust. You need to be authenticated and all of that has to happen really quick. Um, that's the other thing that, um, is, is a trend, is the speed of computing, the speed of development, and the speed of the way things happen, uh, is increasingly, I mean, we, uh, we all went on our Christmas break or holiday break from KuppingerCole. Um, we came back to find that, um, uh, teams have been completely changed, um, overnight, uh, when over Christmas, uh, there's been yet another update to office 365. So we're seeing even in the stuff that we consume, um, and that's happening in within organizations as well, where applications and code is being, you know, it never ends. There's never, there's never a finished, um, object,
Right? If you think of, of where, where is dev ops in place that it's in place, where you have this speed, where people have to, um, provide solutions, new services, new apps, new infrastructure at a high pace, and that needs to be then of course done properly when it comes to the, the, uh, the tool chain for creating the code for writing the code for testing the code for doing code analysis, for deploying the code on different platforms and all of this, also, as you've mentioned, requires secrets to make sure that you have access to the platform you're deploying to be it, uh, be it microservices that are run in containers, be it serverless, be it a traditional infrastructure as a service with, with keys to access the service, to create the infrastructure, all this needs to be done at the right, at the right pace at the right agility. But on the other hand, make sure that this is really properly secured and, and well executed. If things go wrong, this is bad. If things go wrong at scale, this is really dangerous at scale. And this is really an issue there. And of course, all the information that is stored within the infrastructure as service infrastructure, as code, sorry, needs to be properly protected as
Well. Yeah. And th and the way that we're moving into containerization and things being broken down instead of monolithic applications. Now a little bits of code are separated into containers, which meets all those demands for agility and for flexibility, but it does present a, uh, a problem perhaps of how to, you know, you've got applications now broken up into all these millions of, uh, separate containers, how to protect all those, um, is, is a challenge, I think. Um, and there's something else that is kind of crazy sounding, but it's called chaos engineering, um, where developers deliberately experiment on software that's in production, um, to, to see if, if, uh, you know, to sort of stress test the systems, uh, make sure that they, they may withstand, uh, unexpected conditions. Um, that sounds like the worst thing possible you could do, uh, to a production system to, to introduce some kind of chaos, just to see if it works, but apparently that's becoming a practice of some sort. Um, it sounds like, you know, failing, failing fast or break things, you have to break things to, to, to get to where you want to be or to make things better. It, it sounds like one of those nice theories, but I'm sure that in reality it would drive most it managers and CSOs and everybody else up the chain completely crazy. The idea that developed dev ops are deliberately introducing errors and, uh, things that might break just to see if it can withstand that. So, um,
Yeah, being in a security advisor, being in the identity and access management field for so many years, that really sounds scary for me, although I get the point and I've come across this term, chaos engineering, um, quite, quite frequently recently. Um, but this is really something where you also, at least in my opinion of being no developer and being known, not an operations guy. Um, but, but this is something where you should apply a risk based approach, what to test in which manner I think it can make perfect sense to, to do that to, to really, to, as you said, stress tests to get really to the, to the, to the core of the system, to understand where optimization can take place, where you can increase security as well. Um, but as it's, as you said, it's really a challenging approach. And, uh, I would like to see that in real life for the first time,
I, I remember, um, the financial sector in UK at least a few years ago. Um, for many years, the financial sector would never test on production systems for the very good reason that they're dealing with the, the economies or that we all depend on. Um, and the banking system. Um, however they did, eventually people said you, at some point, you need to test on production systems because you don't know everything, just testing in theory, doesn't give you a real idea of what might happen, but the difference was they didn't just go ahead and then like do a bit of chaos engineering. Uh, as we were talking about just now, um, it was all done through risk management and it was all done through an agreed template of persona of process and procedure that all banks, uh, signed up to, um, an owner of those banks that followed this procedure were allowed to test their own production systems. So you're absolutely right. Um, we can't have people just going off throwing spanners literally into the works, um, um, without it being, you know, properly monitored and controlled, but I think chaos engineering has such a, it's such an attractive title. I think people are going to be talking about it, you know, it sounds fantastic, doesn't it? It's chaos engineering.
Um, I, I think this is a concept that I've come across actually very earlier than that. Um, I've talked to developers who provide large, um, uh, sales platforms in, uh, in the cloud for, for, for goods, for retail goods. And, and they said, okay, we, we implement new functionality into that platform. We, we tested of course. Um, but then we don't roll it out to all the instances that we're running, but we're just rolling it out to say 10 to 15%. And depending on where the load balance authors, you add, you end up with a new, or the old functionality so that they can test it in real life. And when it's working, they then deploy it to more so that it is gradually rolled out. So that is the concept that I've heard of before. It's not really breaking the system, but it's changing the functionality over time. And you won't know where you end up in the version one dot or the version one.one.
Yeah. I mean, I'm reading this, this little blog here and it's chaos engineering has mentioned again, uh, and someone here says it's, it's, it's, it's critical, uh, in today's hybrid infer world as he calls it. But this sounds very much like, um, a dev person talking, um, and his rationality is it, unless you test things, um, as the customer would experience, then, then you haven't tested properly, but I don't know. Right. But I look forward to reading a lot more about that.
Absolutely. Um, before we close down one final, uh, trend that you see in the dev ops environment, when it comes to security to identity, to privilege to access
The trend, I think I mentioned just briefly was in that Pam privileged access management is really taking DevOps is I think is their next sort of step forward. Um, we've just, if I can just, um, promote one of our reports, um, very shortly, hopefully by February, the leadership compass, Pam for develops will be available for download on, on our website, um, which I produced. And even in the time that that was produced, uh, companies like CyberArk, for example, have even set up an entire division within the business to co concentrate purely on Pam, for DevOps, with, uh, with a dedicated general manager to, to lead that business. Um, and, and there are, is sort of a battle going on now between the big four Pam providers, uh, to, to gain leadership in, in this space. Um, but they are, they are being challenged by companies like SSH and Hashi Corp, which use very lean, um, volt lists or certificate based, uh, systems that can be easily plugged into DevOps.
So, um, it probably DevOps is, is, is featuring in other areas as well. But I just noticed even in the last year that I've been looking closely at this, that, uh, the focus has changed quite considerably. And I think, as I said, people are starting to talk about secrets management, not so much privilege access management. And, uh, I think the two are, I think dev ops is really pushing the innovation curve within privilege management as a science, I suppose, as it is, or discipline is the best way. Uh, the other, the other thing of course is cloud. I know that sounds crazy to say cloud is, is a trend. Um, it seemed obvious to say that after many years, but I think that the pandemic has pushed cloud even further into the, uh, the sort of mind space of, of managers and buyers and everything is becoming developing cloud native applications seems to be, you know, uh, the, the way forward, a kind of a, a no-brainer decision, um, that we are moving even further into a cloud-based world.
Exactly. And I think one thing that we did not get mentioned is the complete topic of serverless in the cloud, which is not a really new trend, but it's a trend that, that is gaining more and more traction. Of course, it is interesting for dev ops as well, because it's, it's really, uh, with less, um, administration effort and with, with less insecurity when it comes to how to pay for that, it's just people use it, that's it? I think that that will be an aspect that we would be that we should look at as well. When you mentioned the pamphlet dev ops document, I really highly recommend that as well. We've talked about that in an earlier episode already.
Yeah, we've mentioned it before, but it's, it's imminent. Now. One other report that is actually available on our website is one I did on workplace delivery or workplace delivery systems, which is probably worth a whole podcast in itself, but there's another area where we're moving. The pandemic has changed the way we work and whether people go back to their work place or not. And I think people have realized how much time they spend looking for things, how much time they spend switching from applications to other applications. And although it's in sort of very immature field and dominated at the moment by the virtual VMware and Citrix, I think that delivering single pane, digital work places to users, whether they be at home, whether they be in an office spaces is a growth area. And again, that will affect privilege access management and identity and access management and everything that we talk about.
Right. Okay. And I, I take this as a promise. We will have a talk about that as well, because yeah,
Yeah. It's something I could waffle on about. Um, so yeah.
Great. Looking forward to that. Thank you very much for sharing your insight when it comes to trends and developments in the area of, of, of DevOps and DevSecOps we in regarding also, uh, our core competitors
Put instances. Yes. I even, I can't say it.
Um, yeah. Anyway, the thing that we had KuppingerCole do best, um, if you are interested as the audience in, in finding more information about, we just been talking about, um, we recommend the leadership compass, um, patent for dev ops and also the leadership compass around the traditional in air quotes, Pam. And, um, if you have interest in more information, just use our search engine at the KuppingerCole website to the upper right. Corner type in DevOps type in, um, Pam, or just type in Paul Fisher to, um, get to more information of the research that you are providing.
Yeah. Type type in my name. And then Pete I'll get lots, you know, make me look very important. Right. Um, when they, when they look at the, uh, search logs on the, on the web. Exactly.
Okay. Thank you very much, Paul, for being my partner in crime today, and looking forward to talking to you soon about this workplace today,
It's been a pleasure, have a great day or evening or whatever it is. Um, I don't know. Okay. Thank you very much. Bye-bye bye