What’s Next is a biweekly conversation between SDxCentral CEO Matt Palmer and a senior-level executive from the technology industry. In each video, Matt has an informal but in-depth video chat with a fellow thought leader to uncover what the future holds for the enterprise IT and telecom markets — the hook is each guest is a long-term acquaintance of Matt’s, so expect a lively conversation.

This time out, Palmer spoke with Chris Wright, CTO and SVP of Global Engineering at Red Hat. In that role, Wright leads a team that guides Red Hat’s technology vision, co-creates technologies and collaboratively implements change to ensure the success of Red Hat’s ecosystem of associates, customers, communities and partners. During his 25+ years as a software engineer, Wright has worked in the telecommunications industry and beyond on high-availability and distributed systems. He also been a Linux developer for more than 15 years, with most of this time spent working deep in the Linux kernel.

[Editor’s note: The following is a summary of what Palmer and Wright discussed in their conversation, edited for length. To hear the full conversation, be sure to watch the video.]

Matt Palmer: Cloud native is a hugely important topic these days. Where are you seeing people getting traction at moving to cloud native? What kind of roadblocks are they running into? And what are the ways to start to get around and circumvent those roadblocks?

Chris Wright: The places where I think people have been really successful ... is going back even from the earlier days of cloud net new applications. So something is literally cloud native. It's built in the cloud with cloud-native principles. Those are the areas. So whether you think that is net new applications or new interfaces to existing applications that might introduce new capabilities to a business. Maybe it's a new way to engage with your customer base. Those are areas that are that are showing real success.

And I think there are some conceptual pieces there. How how do we cloud native, which is about automation, managing your resources as ephemeral and only using them when you need them? Because cost becomes a real issue. For any consumer of cloud (and you know you're if you're used to), I just own the server, and I just run things whenever I need them. It's not necessarily cost-effective in the cloud. So that. And there are also tools that help support that so I'd say one part of it is just conceptual being cloud native. Having written code to start off working that way.

Palmer: Once you've decided what you're gonna move to cloud native, the next question is really about the security implications, which is at the heart of open source. So what do you see are the implications of cloud native from a security standpoint, and also the adoption of all of these open-source tools and libraries, all of the great components that you can go grab today?

Wright: It's a huge topic, so I'll try to break it down into some key discussion zones. One would be the cloud-native design principles. And there I'd say, and I think we all know this, the history of security and enterprise applications perimeter security —hard on the outside, soft in the middle — and you just have to throw that mindset out the window. If you think about building an application out of a set of services, each of which has a public endpoint ... well, those public endpoints obviously are public. So they're accessible to anybody. If you take a monolithic application, which means any of the calls between portions of the application are internal, and you break it apart and turn it into a set of services, you expose a lot of internal interfaces. You have to think about what it means to expose those interfaces and build security parameters around the boundaries of anything that expresses the public interface. And that's just a very different view on security. It brings it all the way down, not just to the application, but almost to the exposed APIs.

We also have to think about trust. What are the trust boundaries? Not only from the outside to the inside, but how can you ensure trust from one portion of an application to another? And you know you can assert an identity. You can authenticate that identity and validate that identity with certificates, and then encrypt your communication, which is maybe one of the important roles of something like a service mesh that can help create that secure connection. So in a sense, anybody could have access to the API. But if you can't effectively authenticate against it ... then you're not gonna be able to communicate that type of bring security all the way through, from from the perimeter into the barriers, just right around the edge of the application is a pretty huge shift. There are a lot of open-source projects to help in that space.

Then there's the other topic of open source itself. And we've had some high-profile security vulnerabilities, and open source projects that have drawn them to the forefront of this conversation like, well, maybe open source isn't isn't secure after all. I think that's completely missing the plot, the storyline. What's really happening is open source is so valuable. And it's ubiquitous. And any software has vulnerabilities, so there will be exposure from time to time. Defense in depth is critical. That's an architectural view. How do you maintain security? And then understanding two critical things: Where is your code coming from, and where have you placed it? So that is really about some kind of supply chain security, and having the provenance of code through to production and being able to trace it all the way through.

Watch the full video for the rest of the conversation between these old friends and colleagues, who also happen to be tech visionaries.