Welcome to the KuppingerCole Analyst Chat. I'm your host, my name is Matthias Reinwarth. I'm a senior analyst and lead advisor with KuppingerCole Analysts. My guest today for this special episode is one of the founders and the principal analyst of KuppingerCole analysts, Martin Kuppinger.
Hi. Yes. Pleasure to talk to you.
Great to have you and the is something special about this episode because it's episode 100. So we've finally made it, we are in three digits now and counting. So this is really kind of anniversary and good to have you for this special episode. As Mike, as today, we want to talk to, we want to talk about a phenomenon that we see right now, gaining a lot of popularity and also a lot of interest in the, and our customers and the vendors. And in our daily work, we want to talk about a phenomenon. That's called everything as code infrastructure, as code software-defined, networking, et cetera. So the coding aspect, as the foundation for dynamic infrastructures, to start with that, what is your basic notion of this? Everything as code aspect, is this something that can apply to everything that we have as critical infrastructure as our daily business infrastructure as well.
And I'm to be, to be honest, I'm reluctant. The challenge is code and coding always as error prone. So coding is challenging. Usually the security experts, the infrastructure experts are not coding specialists while the coders usually on other security or the infrastructure specialists. So there there's, there's some gaps between what you need them to do and what you, where your domain knowledge with your domain expertise, commonly isn't. And that is something we need to be. I think very cautious, very careful about where every single on every single code code is also as we know relatively complex to maintain. And have you also see that the large repertories tend to be under attack? So it is also clearly something where, okay, take us kind of come in everywhere, but this is also an area where attackers can come in and identifying that something has changed in code. Okay. Can be done technically, but analyzing codes that has been written for correct this, et cetera. And that's super easy. So I think we need to be a little bit careful and I'm honestly not. I don't have the opinion that everything has code is really the future. It doesn't need to be distinguished carefully between every single code and things like SD wan SD wham can be trust, configured without code, without coding. So the point where I'm really skeptical is the coding aspect, right?
The problem or the challenge of creating error free code is a topic that we have been discussing as analysts as consultants for many years, if you think back for saying 15, 20 years, there was this password caused called case tools or computer aided software engineering. And that also came with the idea that code is not actually written, but generated at this at large scale. Is this something where we should end up here again? Because the, the genius out of the bottle, we will have dynamic infrastructures. We will have this code, this configuration as the basis of this infrastructure. The question is, how do we get to that configuration slash code? How do we scale it up? How do we make sure that this is something that is as secure as it would be? If it was still, yeah. Bare metal machines, what is your opinion on that? How do we get to this proper configuration? What, what are means to, to, to achieve this?
Yeah, so I think the, and you brought it up, I think with this comparison to case, which is really quite awhile ago. So it's a first, I think it has been, it has been some times that the 1960s, a professor, I believe it was for the Netherlands. I thought I was named in my mind or on hand anymore. But he came up with was a, sort of a proof that software starting this a certain length can't be free of errors anymore. So there's a certain point where software has errors. And I think we see it day by day, just look at the number of patches, the number of updates, et cetera, where things are fixed because something went wrong. So I think there's th th that's inherent challenge in, in creating code manually.
On the other hand, when we look at what's happening across it, then one of the hype seems, these days is no code low code. So it is saying, how can we abstract the complexity of coding, something into a configuration scheme, which has done the really more a click together approach for doing things. And so no code low code could be one pass to go, which then at the end results in what today is done by code. The other approach I see is to say, we go way more for automation. So if you know what this piece of software you're creating needs to be executed successfully, if you can describe the, the resources required to compute the storage was versus all the other configuration aspects, whatever how many instances can run in parallel and cost aspects, et cetera, then at the end, that configuration can be what at the end controls the environment. And I strongly believe that this is at the end anyway, a better approach. So I'm a big believer in configuration over coding,
Right? And if I think back to the EIC, the European identity in cloud conference in Munich earlier this year in September, you, your keynote was covering one of these concepts in details of really talking about policies as the basis for the automation and then the creation of code and in the, in the concept of what you called basis. So business driven, agile and security, I secure it as a service to make sure that you get to such an approach as you've mentioned. So not coding everything piece by piece, and rather than really making sure that you have a proper set of definitions of proper set of rules, also reflecting your corporate requirements and your corporate policies, and then that leading to a set of configurations that then can be orchestrated across your platforms wherever they are. I think that is really reflected here as well.
Yeah. And do you know, it's not that I'm against coding in my past. I even have written books on Borland C plus plus followed five and things like that. So I have written books. I have a background, not a super deep background, but I have some experience and some background in coding. So, but, but, but I, I think the challenge at the end of the day is read that there are two aspects to honors decoding, sort of the inherent coding challenges and self mentioned. So create code, keep coats. So managed the updates, the changes in code and all that stuff, which clearly can't be handled by that, which is not an easy thing to do. And at the end of the risk, but there is something wrong in the code that it does is the one part Deanna, upon his half management also earliest it very different skills.
So coding is a different skill than infrastructure knowledge, some security knowledge clearly. And it's also describing the spaces concept. We need to decide things. We need to bring people closer together to work together. And, but isn't necessarily that then really at the end feed, we try to describe things, basically why our code, I dare to say, it's, it's not the right direction. We still, even while we need to bring people together closer and to work together and to, to, to operate, it's not coding, which, which should make this happen. So, but it's really more, how do we enable that we can deliver solutions on time in an efficient manner and deployed them, run them, operate them in an efficient manner. And this is I think, where we should put our, our, our emphasis on it. And yes, there are areas where you could argue this works quite well.
So if you're a provider of a SAS solution of an, a solution where you say, okay, this is a single tenant, so you wish, but I want to automate deployment for, for dozens of hundreds of, of, of tenants. Then you can easily build a team, very say, Hey, there are other specialists from the software side and from the infrastructure and the security side, because their day by day by day work in that team. But then it's, it's somewhat a different thing than when you're creating a lot of applications in your own. It w we will not have these teams in the same manner as when you're a provider. So for a provider that can be a different thing for the ones who are not the providers. I see if we're a little bit skeptical,
Right? And we've seen that in presentations and earlier KC life events, where there were approaches described that had a kind of a self-service approach towards the provision of infrastructure for internal teams, providing software for end user customers for the organization. They were always capable of adding their parameters there, but, but very limited in what the size of the machine and the, and the area where they should be deployed and how many instances could run in parallel. But that's it. And that would really immediately lead to a configuration, which is code with added parameters, which make sure that the actual infrastructure is rolled out where it needs to be. And then they deploy their code in this infrastructure. So this, this self service approach, what goes hand in hand with this policy plus automation approach, because in these policies, in this, in this front end, that allows for this self services, that would be the, the basic rules already embedded in there, plus the added parameters for the individual solution plus the deployed code. And that would lead to a, a policy-based automated deployment of these infrastructures, which could be, could be easily changed afterwards as well. Is this something that you could agree?
Yes. Yes. I think it was an abstraction. It's easier at that level because when you look at a Google cloud platform versus on AWS versus Azure, the code looks very different for each of these platforms. Yes. You have to platforms that sit on top again. So yeah, there are things which it strikes us standardized, but if you standardized it, what, why, why necessarily doing it? Why a code? I think this is, this is the point where we really need, need to think about, and at the end, one of the targets should be that these things run everywhere. And I think there's a good reason why concepts like Keem sort of cloud infrastructure, entitlement measurement, or Urim hour or KuppingerCole Analyst concept of digital resource access and entitlement management are gaining so much traction because what happened at the end of the day is that organizations already has lost control about their dynamic DeAnn environment, where they run into dynamic workloads, be the public infrastructure as a service environment and, and pass and SASA environment as AWS, Google cloud platform or Microsoft, or be something they write in their private clouds, they already are losing control.
And that, I think also sheds a light on that. At least the way we did sings as a code or the last couple of months, a month, two or three years or so, half Derrick temp, major issues when it comes to security, when it comes to control when it comes to governance. And so I think also from that perspective, there's a logic in saying, let's think about how can we do things better and avoid some of the inherent charges.
So if I understand you correctly, then it is not an option to move towards policy-based automation, but it's a necessity because many organizations already are in a situation where they at least could improve their control. I, I w I would not always dare to say they have lost control already, but nevertheless, it's not an option they need to, to change the way they are doing things maybe as a final thought for this episode, what would be a good first step to move towards such a policy-based automated deployment of complex dynamic infrastructure? What would be your suggestion if somebody listens to this and that? Yeah, they're right. I want to, I want to embark on that journey.
Yeah. So, so I think the, the point of look at us today, especially for these environments and this looking at theory at Keem at the solutions emerging in this space, which helped to handle access of services to resources, and to get a trivalent, that, to automate that, to get a better control about that, because this is one of these areas where it's really essential, that we get better to a wide that our cloud security gets totally out of control. That also includes the, the cloud security posture management approach. So, so really understanding what do you have as assets in the cloud, because at the end, you only can automate, you can create policies when you know, what you have, what you have in essence, et cetera. So this, and these are all emerging technologies where something is there where we can see still a lot of evolution, but that is where I would start looking at.
Right. Thank you. I think that topic and this group of topics, because this was really an, an area of at different abstraction layers, where we have to look at that, that set of topics will stay with us for the next say, eight years. And I think we can, everybody can get better in, in, in dealing with these challenges because the challenges will grow a multicloud, multi hybrid, and as business gets more digital, any issue that re that happens in it is a business issue. So thank you very much, Martin, for joining me today, I would highly, I would highly recommend real listening to your opening keynote for the EIC. I will link it in this video and I will also put it into the show notes. So please follow up with that because this is a great, very concise, compact introduction into this set of topics. Thank you again, Martin, and looking forward to talking to you soon. Thank you.
