Palo Alto Networks, Inc. (PANW) Earnings Call Transcript & Summary

Hello. Welcome. I'm William Fellows. I am the Co-Founder of 451 Research, and I head our new cloud native research channel. Welcome to our cloud native panel, HCTS, Cloud, Containers and Kubernetes - Taking the Sting Out of Transformation? You'll notice I'm continuing the bee theme, for those of you who were in the -- Owen and Melanie's previous session. Now I know everyone will be familiar with the term, what happens in Vegas stays in Vegas. But due to circumstances out of our control, I'm actually fortunately being able to bring the HCTS content to a much wider audience than I would be ordinarily. So I'm going to be your moderator today. And these are your panelists: So Erik Vogel, VP of Customer Experience at HPE; Mark Hinkle, Co-Founder and CEO of TriggerMesh; and John Morello, Vice President of Prisma Cloud at Palo Alto Networks. So I've also got a couple of the cloud native analysts on hand: Jean Atelsek, who is a research analyst; and Jay Lyman, who is a senior research analyst. And these are 2 of the folks who are collaborating in the channel, which I now have more than 25 analysts participating in. So my takeaway from the previous session was that cloud complexity is being driven by an enterprise market demanding more options and capabilities. The complexities increased during COVID, however, that those using cloud native frameworks have had the most flexibility during this time. So before I ask the panelists to introduce themselves, I'm going to spend a few minutes just presenting our view of the market and sharing adoption data from our global alliance of enterprise IT decision-makers. So I think as you might have gleaned, I'm also a beekeeper or an apiarist. So I hope you don't mind if I continue with this. There are depictions of humans collecting honey from wild bees dating back 10,000 years and more. Subsequently, colonies of wild bees were kept in lots of things, including woven straw baskets or what you can see here, a skep. The problem is that all of these entail the destruction of the entire colony when the honey was harvested, which is clearly inefficient. So scientific understanding in the 19th century led to the creation of the Langstroth hive, which has a series of wooden frames in a rectangular hive box, maintaining a space of between 5 and 9 millimeters between successive frames, so the bees will build parallel honeycombs in the box without bonding them to each other or to the hive walls. This enables the beekeeper to slide out any frame for inspection without harming the bees or the comb, protecting the eggs and the larvae. Combs containing honey can be removed and the honey extracted without destroying the comb. The empty honeycombs are returned to the bees intact for refilling. So it was the invention of the movable comb hive fostered the sort of growth of the commercial honey production on a large scale or what we now know as apiculture. So Langstroth made beekeeping for honey production better, faster and cheaper by effectively industrializing a natural process. It's self-sustaining and its infrastructure components are reusable. There are various versions, including the National hive and this, my top bar hive, that you can see here. Now cloud native works because it is also an apiculture, an API culture which renders infrastructure largely invisible to the developer, leading to better, faster and potentially cheaper service -- digital service creation. Software releases using DevOps processes enable services to be assembled, connected, consumed and reused just like in a hive. And together, I think they help take the sting out of transformation. So where are we? Well, cloud is a teenager now, but cloud native is still a relative toddler. And it's early days in the market which is undergoing this -- well, can only be described really as a kind of a massive sort of Cambrian explosion. The container is the atomic unit. They are assembled into microservices. And Kubernetes is becoming the dial tone. But given the breadth of cloud services available in the market, the key to success, I think, is going to be finding the right combinations of all these things that you can see here and operationalizing them to deliver the benefits, which are as advertised by their suppliers. And this is why at 451, we segment the market in a couple of ways now. So we see cloud very much as being the venue where this takes place. This is the infrastructure view, whereas cloud native is the platform. It's the application view which provides all of these new elements from containers to Kubernetes, serverless, microservices and so on; and the reason that we now operate 2 channels, so our cloud and managed services transformation and the cloud native channel, which I mentioned earlier, which is a collaboration across the entire research group. So how do we think about cloud native? We don't really see the different technologies competing or eliminating one another. Everyone's kind of driving in the same direction. The main distinction is the level of abstraction provided to the end user. So we sort of described this cloud native set of technologies that fall on the spectrum of abstraction. On the one side is do-it-yourself containers approach, where organizations leverage sort of custom code and services and make their own choices on languages, frameworks and APIs; and on the other end, as functionality becomes more abstracted and visible, are serverless functions and events for which there are, well, standardized and opinionated choices that are abstracted away. So in between these 2 ends of the spectrum are still other levels of abstraction, such as supported Kubernetes distributions and Container as a Service offerings and so on. So the data that I'm going to show in the next few slides is taken from our 2020 Voice of the Enterprise DevOps survey amongst our global audience of IT decision-makers. So what do we know? From the survey, we know that 61% of organizations say half or more of their DevOp perhaps are developed with cloud native technologies. Coming to the technology itself, 43% say microservices are sort of the key building block there. And about -- on the adoption front, some 55% say that some or all are adopting widely of containers, 42% some -- or full adoption of Kubernetes, 40% when it comes to serverless and 36% when it comes to service mesh. And a whopping 89% say that containers is still mainly often or always still running inside VMs. So when we double-click on adoption at the team level, we can see here the -- that in -- that there are in -- there is somewhat full-scale adoption across all teams, which is in the green, but more adoption across some of the teams. And we expect full adoption to grow in the quarters ahead. To expect to find refuge, I think, these days in sort of legacy and siloed responsibilities is sort of pretty retro. And it's the organizational clean slate of companies like Uber, Lyft or TransferWise that enables them to eat lunch with traditional competitors. Their existing data and assets and relationships are only going to take them so far into the future. And it's one of the virtues of Kubernetes in DevOps. They're change agents that break down institutional barriers and let organizations adapt and morph to take advantage of the possibilities. So yes, existing investments must be respected. And some workloads are surely better, more efficient, more cost-effective, left on-premise for now. But really, that's a starting point and not the end point. We were also fortunate at 451 to be able to survey our base on a regular basis throughout the pandemic and to take a reading on what that has meant in terms of the effect on cloud native software initiatives. And we can see here that while some have accelerated, some have been delayed, actually the vast -- for the vast majority, they're continuing as they had been. So what about the primary drivers and benefits of cloud native? Asking that same survey base, we can see that IT operations efficiency, security and costs come out top in terms of what the benefits the IT decision-makers tell us. But I wonder then what about -- what does it imply for the organizational disposition or posture towards cloud native. And I'm going to ask my colleague, Jay Lyman, who looks after the DevOps research here, to spend a minute just overviewing how we see that playing out here. Jay?

Yes, yes. Thanks, William. In keeping with sort of the bee theme, when we look at bee colonies, we see different roles, right? You have the queens in charge of reproducing, the drones helping out with that, and worker bees making the honey. And when we look at DevOps, which is where we do see a lot of the cloud native technology deployed in site DevOps teams and site reliability engineers, we also see different roles. And DevOps, the term itself implies we're primarily talking about developers and IT operations, but as you can see from our data, we do see other stakeholders in the process. And we've been covering what we call the stakeholder spread for some time in the DevOps trend. And the other stakeholders beyond those developers and IT ops teams, we see more management leadership involved in DevOps deployments and DevOps releases, and this is indicative of much more top-down adoption of DevOps. It's no longer a grassroots movement limited to developers. And we see the same thing with the central IT admins, traditional IT admins involved in sort of ushering in DevOps into the larger organization and making sure that rather than being focused on speed or efficiency, making sure that DevOps deployments are blessed and sanctioned by the organization and compliant and secure. Security teams, another important group of stakeholders as we see the fairly rapidly ongoing evolution of the DevSecOps trend and shifting left, integrating more security components into DevOps releases earlier in the process. That's certainly happening, and security teams are part of that. We also see lines of business and product managers, data science, data analytics teams, database administrators, who a few years ago were sort of notoriously left out of DevOps processes. Now they're part of the conversation and then work to speed up releases, drive efficiency and create a general sort of agility and readiness for whatever changes in the market might be coming. Looking ahead, we see these finance officers and compliance officers, among other stakeholders. And I would also sort of -- on the radar for additional stakeholders are sales and marketing teams that might be involved with the development of an application in coordination with a campaign and also human resources. As we know, there's a dearth of DevOps skills and expertise out there, and so the hiring and retaining of DevOps professionals becomes a big factor here as well. So the bottom line, if DevOps is working correctly, you will see the stakeholder spread as you apply DevOps to more applications and releases across the organization. As it moves more broadly, it's going to pull in more folks. And with that, I'll turn it back over to William.

Great. Thanks, Jay. So those are the benefits in organization. But what about the hurdles then? And that same survey base tell us that security, cost and complexity really are the key challenges. And the colors there represent -- well, we've done it by the level of DevOps adoption here: with green, full adoption; black, some adoption; blue really the total we're paying attention to there. Interesting that some of the benefits are same as some of the challenges here, I think. One of the key things -- and this applies right across the sort of cloud landscape. When we ask where is your organization currently facing acute skill shortages, cloud platform and cloud native come out on top here on the black, 2019, and the green, 2020. And we can see that the skill shortage around cloud native has accelerated significantly in 2020. That is -- we also look at the -- across our organization, we look at how M&A is being experienced in these sectors. And I know that the -- our panelists have a great deal of experience with this. And what I -- so what I did was just to put together a set of data which shows, in the green, the number of cloud native transactions across the sectors that we cover; and in the blue, the aggregated, the total volume in the dollar amount of the value of those transactions. And we can see that it's picking up. It's somewhat skewed, obviously, by the IBM acquisition of Red Hat in 2018, but certainly that is something also that we track very closely in our service. So what do we know? Well, when we come to the technology piece, I think all of us have found and are seeing that organizations, enterprises are really looking for multi-cluster Kubernetes support and they're getting it. The serverless is becoming, well, a sort of important or sort of target for general-purpose applications. Server mesh is gaining traction as cloud native deployments begin to scale. And as digital channels replace brick and mortar, then observability really is becoming a really key piece of the pie. So that's technology. On the economic side, what we know is that the various FinOps models, as they're called, variable cost, low CapEx, on demand, are all supported in cloud native as well as the sort of no-ops, anywhere, anytime operational flexibility. And just on the economic piece on the M&A, really it's the security sector which has consolidated first and most quickly in cloud native, as I know again our panelists can attest to that. When it comes to the organizational aspect, well, DevOps is clearly mainstream. And what we do see now is that DevOps as a service sort of internally delivering DevOps best practices and so on really is becoming a thing in terms of the introduction of new services and the ability to exploit new technologies and be collaborative and so on. And I like to think about it like the waggle dance that bees do when the returning foragers signal the location of new food and water resources to the rest of the hive. And ESG metrics, so environmental, social and governance, are becoming a factor in financial reporting and investment evaluation. So it would be interesting to see what are the potentials for cloud native to support those, for example, the cost of serverless versus server-full. And it's been the subject of some of the recent conference sessions. Overall, it's still really sort of making infrastructure more invisible. So to summarize, human intervention has been helpful in addressing threats to bee colonies, such as controlling the Varroa mite, but also harmful with the continued use of neonicotinoid pesticides, which are toxic to pollinators. And there's a similar tension in cloud native, I think, letting technology take the wheel, so to speak, with automation versus the desire to tinker with and potentially break things. And there is currently a deep schism in apiculture about the use of this, which is the recently invented Flow Hive in which honey is automatically extracted by turning a lever, which doesn't disturb the bees. However, it uses plastic comb rather than the natural wax comb and is relatively expensive compared to other hives. But the key criticism is that there's no longer any interaction between bees and beings. It's another layer of abstraction and level of automation. So finally, what are the gaps? What are the sort of some of the key issues that we can talk about on the panel? I said that some of the challenges seem to be the same as some of the benefits and the skill shortage is becoming critical, the access to talent becoming more of a constraint than the access to capital, which really is a thing now. And there's a -- it'd be interesting to try and understand what the relative disposition of customers is between using cloud native for modernization or for new app development and its suitability for more general-purpose applications. I'd clearly also like to know how our panelists think about what adoption might look like in 5 years' time. So without further ado, I'm going to turn to our panelists, and I'm going to ask them to each introduce themselves and just summarize, if they can, the kind of cloud posture of their company in terms of their posture in terms of cloud native and going back to the theme of this panel, whether indeed they think that these things collectively are helping to take the sort of sting out of transformations. So I'll ask Jean and Jay to just introduce themselves first, if I may, just so that folks know what their responsibilities are. Jean, would you like to?

Sure. I'm Jean Atelsek, and I work with William on cloud native and in particular service mesh and serverless. And I'm also part of the Digital Economics Unit at 451, which the relation of that to cloud native is pretty obvious. So Jay?

Thanks, Jean. Yes, I'm Jay Lyman. I'm a senior research analyst on our applied infrastructure and DevOps team. And I head up our Voice of the Enterprise DevOps surveys, which we do twice a year and we included some data.

Thanks, Jay. So my panelists -- or your panelists, I should say, rather, Erik, would you like to introduce yourself and your role and have a go sort of giving our audience a view of the sort of cloud posture that's going on, cloud native posture over at HPE then?

Sure. So Erik Vogel, and I lead customer experience for HPE GreenLake. And GreenLake is HPE's brand for Everything-as-a-Service. So about a year ago, we made a pretty bold proclamation as a company that we will be pivoting and offering everything within our portfolio as a service, again under the GreenLake brand. And what we are doing is really bringing the cloud on-prem. So as we think about the cloud experience today, specifically with respect to hyperscalers, is now we are bringing that similar experience with GreenLake to customers in their data center, in their edge or maybe a colo facility. And when we talk about that experience, it's about the economic model that -- well, you mentioned being able to provide things truly as a service, fully managed. So when we look at container platforms, for example, we can manage all the way up through the container platform, just providing customers access to the container clusters that they need to run those applications. So as we think about our view and where we are headed, bringing that cloud on-prem is we're really focusing on addressing that set of workloads that we recognize are not moving right now to public cloud for a variety of reasons: whether that's data gravity issues, regulatory issues, compliance issues or even complexity issues with the applications themselves, where they were never meant to be cloud native. So we're really addressing that 60% or 70% of those workloads that will stay within the client environment and again bringing that cloud experience, whether that's the economic model, the automation, the orchestration, the management capabilities and providing that to clients. So as we think about cloud native, it's not just about public cloud. From our perspective, it's also allowing that development and that cloud native experience but sitting within the customer premise.

Great. Thanks, Erik, and I know you've got a lot of momentum there. Mark?

Hi. I'm Mark Hinkle. I am the CEO and Co-Founder of TriggerMesh, and we make a cloud native integration platform based on Kubernetes and Knative. And what we do is we automate workflows between cloud services or between the cloud and on-premises so that you can automate everything. But with all the buzz -- and I had to say that after all the bee analogies, around cloud native, we focus mainly on cloud services and integrating them with whatever infrastructure you want to integrate with.

Great. Thanks, Mark. John?

Hey, I'm John Morello. I'm the VP of Product for a product that we call Prisma Cloud, which is Palo Alto Networks' platform for securing cloud native infrastructure and the application frameworks that run on top of it. I was the CTO at Twistlock. So we pioneered the space around container security and serverless security and just sort of the notion of DevSecOps in general. And through a variety of other acquisitions, Palo Alto has been trying to build this platform. It really is a cloud-native security platform. So our goal with this is -- I often talk to customers about there being 3 layers to cloud security, the bottom layer being the cloud provider's problem, right? That's Amazon or Azure, whomever, making sure that they're running your data centers and services in the way that they prescribed to you based on the regulatory regimes that they're compliant with. And there's 2 layers on top of that, that you're responsible for as a customer. One of those is how you configure those services. And part of what we do within Prisma Cloud is to make sure that not only do you have the right configurations, the right compliance settings and so forth, but that we harvest all the data that we can gather from things like CloudTrail and flow log and so forth and providing analytics over that to be able to find problems that are occurring with that configuration plane, that service management plane. On top of that though, there's also this notion of the compute plane, which is the applications that you run in containers and serverless platforms, on-demand containers like AWS Fargate, all kinds of other permutations of cloud native today. And we're trying to help protect you across that entire dimension as well. So regardless of where you're running your application, whatever it be, a container or be it in Kubernetes cluster or some other sort of form of serverless, we provide a consistent set of capability that spans the life cycle of that application, so everything from vulnerability management, active run time, defense, all that in a way that's really designed to be cloud native itself. And what I mean by that is everything is in open formats and open APIs and really designed to be programmatically accessible and integrated into CI/CD flows that the development teams are already using. So Prisma Cloud is that overall cloud native security platform, and it's really designed to help you regardless of where you're running those clouds, public cloud providers, your own on-premises environments, wherever it may be, again, leveraging those open standards of technologies to protect you across both the service plane and the compute plane.

Great. Thanks, John. So I guess given that we've got -- we've arrived where we are, we've got clouds, containers, microservices, Kubernetes, serverless, service mesh, I'm interested in just understanding from you guys when you're speaking to customers, what is their sort of goal with these things? And is it actually assisting the transformations? Or is there -- are they really going through a whole lot of kind of learning at the moment? And the reason I ask is because the data that I showed earlier was interestingly -- showed that the -- some of the benefits of using cloud native are also some of the biggest challenges. So I wonder whether there's still a sort of tension underway until there's some sort of -- some breakthrough, if you like, in terms of the -- seeing the real benefits from it. What do you think? Does anyone want to pick that up?

I mean there's all kinds of customers at different levels of maturity and different levels of sophistication of their use of cloud. So certainly, there are lots of customers that are very much in that learning stage that you allude to earlier. But at the same time, there's also lots of organizations, and this is really not an industry-specific thing. I think of cloud native as being just really universal in terms of the customer base and market segments that it's applicable to. But there's plenty of customers across all those various industries and verticals that are actually already quite sophisticated in the way they build their software. If you believe in the whole notion and whole concept of software eating the world and every organization having to develop a competency in developing software because that's the way that they are going to differentiate themselves from their competitors if they're going to obtain and maintain competitive advantage, well, think about all the stuff that we're talking about in cloud native as basically being the tools that enable that degree of software-driven transformation. So it's -- whether it be about containers or Kubernetes or serverless, it's really about -- there's a lot of different options. There's different kinds of workloads and patterns for -- that customers have from long-lived databases to enabling mobile applications and so forth. There's different fits for each of them, but what we've seen a lot of is a growing degree of maturity amongst customers and being able to choose the right cloud native technologies out of that toolkit for a given workload. They're using a mixture of many different cloud native technologies at the same time, and they're really using all of that to further that notion of digital transformation to allow them to create and maintain software much more rapidly than they've been able to in the past.

Got it. And is this also happening in sort of on-premise then, Erik? Because I guess the assumption is that most of this happens in hosted cloud environments. What -- to what extent can this be achieved on-premise as well?

Yes. We see kind of a similar -- I think that was John talking -- similar to what John's saying. We sort of look at it and we're seeing customers kind of fall into one of what I would consider 3 tiers. We have those customers that are really looking for what I would call infrastructure transformation, where they're really looking at how can we consume infrastructure differently. How do we buy infrastructure differently? We really want that physical infrastructure truly as a service. We don't want the big CapEx expense. We want it OpEx. We want it consumption-based. We want to pay for what we use. We want to manage from a capacity standpoint or even the infrastructure fully managed. And we have that set of customers. I'll call that kind of Tier 1. The second tier of customers are ones that have already progressed, and they've already accepted or sort of standardized on that new infrastructure model, but they're really looking at a platform transformation. So they are looking at container platform. They're looking at even VMs, how they do that differently. So they're looking at how do they consume platforms, understanding that the infrastructure comes with that. And they just want to buy and consume a VM. They want to buy and consume a container cluster, and they're doing their cloud native work essentially on top of those platforms. So we have that platform transformation-type customer. And then at the top tier is really those customers that are really embarking on that workload transformation where they're saying, look, we don't want to run Epic. We don't want to run Splunk as we've done it traditionally. We just want to consume that as a service. And we're looking for somebody to provide the infrastructure with the platform, with the management so we can just have access to those tools, whether that's an MLOps set of tools or an AI set of tools or again something like an Epic or Splunk, where they can just access it and use it as needed. So that's kind of that -- what I'd consider that top tier. So within the on-prem environment, as we're doing that work, again, we're seeing those customers in those 3 tiers, whether that's -- those focused on infrastructure, those focused on platform or those focused on workload transformations. And it's not uncommon, especially at big enterprises, where they may be in all 3 tiers at once. So for certain workloads, they're looking at that workload transformation at a platform layer. They're looking to transform it. And even at the infrastructure layer, for certain things they're doing, they're looking for that transformation. So I would say generally, again when we look at the on-prem, so not specifically talking about the public cloud but for the on-prem environment, our customers sort of fall into one of those 3 tiers. And it's really to support that digital transformation that pretty much every one of our enterprise customers is undergoing right now. And I'll say as part of the whole COVID challenge we're in, it's definitely accelerated that digital agenda for a lot of our customers. They are definitely moving faster and faster. And they're definitely starting to move up in the tiers where we had customers who were just worried about buying infrastructure differently. Now they're really looking at what are those cloud-native platforms we should be consuming and how do we think differently about deploying and leveraging those versus the traditional models.

And Mark, I guess you're more bleeding edge provider. I wonder is there a different lens for how you see what customers are doing here.

Well, I think I like the -- Erik's tiers because we do have 2 sorts of customers. So we have customers that are deploying containers, Kubernetes on-premises. And a lot of these folks are in different parts of their journey from automating just the CI/CD on on-premises to more sophisticated folks who are running a FaaS service like Knative on top of Kubernetes to offer services and automating it. And then there's folks -- there's the bleeding edge folks who have put in event management systems. They have Kafka. They're really investing in event-driven architecture. And then there's the ones that want to get there because those kind of architectures really are what's the foundation for the digital transformation. And then sort of the other set of customers or users are those that want to weave together cloud services. And this is the hybrid cloud in the sense that it's not comparable workloads but actual services that are differentiated. So they may be using Amazon Lambda, but they're also using Twilio and Salesforce. And they're monitoring with Datadog, and they're creating this mesh of cloud services together. And the thing that's interesting about them is some of them are very, very advanced and decided they don't want to run infrastructure. And some of them are not nearly as technical but, because the barrier to entry is fairly low, are adopting in a sense.

Got it. And so I wonder then, what are the kind of linchpins of what they're doing here? Because enterprises really have to sort of embrace, I suppose, fundamental structural change to sort of turn their ships around and compete with more nimble competitors. And they need, well, different approaches and new roles. Are they -- is it DevOps and Kubernetes which are the sort of key change agents for these transformation projects? Are these really the anchors and all these other stuff is kind of collateral? I wonder if this is where it's really grounded.

So I would say the linchpin is events and then so the systems to speak to one another. So not just collecting events with Kafka but transforming them so that they're consumable by web services and in a standard like CNCFs, Kafka, things like that.

And so Erik and John, I wondered are DevOps and Kubernetes really the things which are driving these -- are they the change agents? Or would you say all of these things together make it work?

Yes, I think...

John, go ahead.

I was just going to say I think that DevOps is really more of a philosophy and organizational change than it is a particular technology. And I'm not saying that to trivialize it, in fact actually quite the opposite, in fact emphasize that I think it has a much more potentially large impact to the way that organizations operate than Kubernetes, which is a tool. I mean it's a great tool. It's a very popular tool. But at the end of the day, it's just a mechanism for running software. The real transformational thing that organizations that are successful with this digital transformation have to embrace is the notion of removing the friction points and barriers between development and actually running their applications in production. DevOps is somewhat of a vague term, and there's a lot of things that can kind of fit into it. But the general notion of saying that you're going to automate everything, that you're going to treat everything including your infrastructure as code, that you're going to have well-defined, software-driven processes for deploying your application and maintaining your application and again removing those barriers that used to involve human beings and responding to outages and security incidents and so forth, that real transformation is the thing that's most durable and most long-lasting, impactful for organizations. Whether the tool that you use are Kubernetes or you're using serverless [indiscernible] or even you're using just standard VMs, you're going to see the biggest net benefit to your organization if you can adopt and embrace those people and process changes not simply trying to drop a new tool into an existing kind of legacy model for people and process.

Right. And that's what I sort of came to in my last slide about the flow hive, which is really that's the challenge. It's the sort of organizational rotation that's required in order to do that and the extent to which organizations feel comfortable with doing that. I'm also the -- over here, the sort of team captain for serverless within the cloud native channel. I do want to just sort of dig in just a little just to ask -- because serverless adoption's sort of growing pretty rapidly, and it's the basis of many sort of transformation projects. And I wonder if you thought how much compute do we think will eventually go serverless? What's beyond the basic sort of functions? And do we foresee a time when entire cloud native applications can be deployed on serverless? Because I know you all have interest and assets in that area. And I'll throw that open to -- throw that to anyone who wants to run with that.

Well, this is Jay. I guess I would say that we certainly see serverless expanding beyond compute, right? When I talk to end users that are leveraging serverless, they're leveraging serverless database, serverless data streaming, all types. And so it's sort of, I think, beyond -- certainly well beyond compute, and we are getting closer to sort of the full serverless stack.

Right, right. I mean...

In terms of the customers that we work with -- and we include a lot of serverless capabilities in the platform. But I don't think it's like an either/or sort of question. I think of the different options for cloud native compute is basically being a continuum of choices. You've got virtual machines. You've got containers, Container as a Service, serverless. And you can think of that as a continuum where on one side of it, like with VMs, you have the greatest amount of compatibility and control and configurability. Whereas on the opposite end of that with serverless, you have the least amount of that but you also have the greatest amount of just sort of agility and efficiency in the sense that you don't have to worry about the infrastructure. But other than organizations who're saying that we're going to go from the left side of VMs and we're going to go to containers, and we're going to go to Kubernetes, and we're going to go to serverless, and eventually, we want to have everything on serverless, it's really about choosing the right tools for the job. There's a lot of things that serverless is great for, but there's also a lot of things that traditional virtual machine is really well suited for. You've got a database that runs or is the back end for some line of business application. The database is only supported by the vendor and the VM, and it's been working great that way for 10 years. Is there really a need to go and try to move that to just a different technology platform? Or could you better apply that time and resources to actual innovation of the application layer? So I don't think of it as like a serverless is the future and how long does it take before we all get there as much as it is just there is a different set of capabilities between VMs, containers and serverless. Organizations choose the right mix on a per workload basis and it's an "all of the above" approach, not a journey from one to the other end of the spectrum.

Yes. Interesting because it's often sort of portrayed as a -- it's either serverless or Kubernetes/containers rather than both. And I guess our experience, like Jay said, is that folks tend to be doing both of these things. And I wonder, what about the progress of serverless on-premise, Erik? Because there are a lot of things in the market at the moment which kind of are directed at that. I just wonder what the experience or appetite amongst your customers are is for doing serverless.

Yes. I think that -- as I look at serverless or even containers for that matter, I think especially within our customer base, which, as we look, is mostly broad, big enterprise, it's I would say fairly slow, I think, hype cycle. The hype is there, but most enterprises we work with are a little bit slower to start to adopt those technologies than what we would expect especially because -- I think Mark was saying, right, we're dealing with a lot of legacy-type applications at the enterprise that, hey, maybe they're already running well in a VM. Maybe they're even running on bare metal. Do we really need to go through that expense to port or to migrate or to refactor applications to leverage serverless, to leverage even public cloud? So I would say that we're seeing kind of, again, a lot of talk. And this is what we saw with containers I'd say 4 years ago, maybe 3 years ago, where a lot of talk, a lot of excitement but we really didn't see the enterprise really jumping in with both feet. They were testing, they were validating and verifying that it would work. They were checking the -- understanding the models, security models, compliance models, and then of course working with the big software vendors who, again, don't always support on every platform. So from my customers -- our customer view -- and again, we deal a lot obviously on-prem -- so it's the bigger enterprises with the big data centers. I would say, again, a lot of talk about it, a lot of kind of putting your toe in the water, wanting to understand more, wanting to see how it's going to work longer term. But we really haven't seen a huge uptake yet in terms of paying customers adopting those technologies.

Got it. Got it. One of the other things, I guess, we sort of witnessed in the whole cloud native universe is that there's this great amount of energy around open source and all the enthusiasm and ingenuity in it. But I wonder can it last given all the sort of competing commercial interest? And at what point are all the sort of competing stacks and components and so on working at cross purposes? Or do you think that, that doesn't matter and that it's kind of a rising tide that will continue to float all the boats out there?

Well, I think one of the big things that's changed is just the proliferation of these open but not open source licenses like Kafka, [ DB ] and Confluent and Elastic have adopted, which keeps the majority of the benefits available that come from open source, the ability to change and refactor, et cetera, but just not offer as a competing service with the original benefactor. I think that's a necessary but good change for the most part. And that probably keeps the same people active in those communities besides the vendors from the end user standpoint.

Got it. So I mean -- so that's an interesting one and sort of leads on to something that I was going to ask around standards and the whole sort of trade body -- trademark body and so on. Do customers care about standards as such? I know the sort of CNCF has sort of arguably got the conch, if you like, in this market. But do customers really care about this stuff?

Well, this is Jay. I'll chime in. I think having covered open source software for a long, long time, it's sort of become an expectation of customers that the components that they're using, at some level, are open-source software and sort of supported by this broader community. At the same time, when an enterprise is using open-source software, they're going to want commercial support for that. Because once applications make it to production, once you're scaling up, you need the SLAs. You need the support from a commercial vendor. So it sort of drives this commercial open source software. And I think it's important that we have neutral bodies to help sort of oversee these projects that aren't necessarily the same entity or company that's providing that commercial support. But I think it has become an expectation that the components be open-source software and that you're able to leverage this broader community that's really not possible unless it is open source.

Yes. And I think given the history of software lock-in and being -- especially when you're talking about platform and application transformation, people see open source as a way of avoiding that. So...

Yes, I think what we see within our customer base is we sort of have the range. We have certain customers that would never run an unsupported piece of software in the enterprise. If it's not -- if it doesn't have support with it, it's not something they'd do. And then we have the other side, which are those kind of leading-edge companies that are looking for open source as a way to drive new innovation very quickly. So they see that as kind of an external innovation engine that's helping to drive new capabilities within the platform, and they're very open to adopting unsupported open source technologies. So I would say -- I think it's a real range depending on the culture of the organization, how their IT functions operate. Again, some will not touch it. Some love it and would -- are willing to experiment and try because it gets them to market faster, gets them to the solutions they're looking for faster at lower price points. So I think that it really depends a lot on the company and their willingness to adopt those technologies. But most importantly, I think it's a cultural and governance decision within those IT organizations in terms of the level they're willing to adopt unsupported/supported types of open source technologies.

So I wonder, as the -- as sort of deployments scale then, are there other things which now enterprises must do or need to do in order to ensure that they are coordinated and can be successful? I mean there's an awful lot of momentum at the moment around service meshes, but they've typically been pretty fiddly to get working with. And there are lots of different approaches in the market. How -- what's your counsel to customers with regard to using those things? I know Jean might have some ideas here as well.

Well, what I'm seeing is that the service meshes are -- have been very hard to adopt, and they are a very fiddly configuration. And a lot of the work ideally is automated and put into the data plane as much adjustment as can happen in there. But -- so companies are intimidated about investing in it. On the other hand, we're seeing more and more service meshes being launched, which -- with the idea of ease of use, ease of adoption, which is great, but the question is how can you scale after that? So I think there's a real tension between adopting service mesh and actually scaling, upgrading and life cycling it the way it needs to be done.

And Erik and John and Mark, is that something that you're seeing? I wonder given all these new technologies, is service mesh being seen, used and so on by customers like that?

I don't see a lot of usage of service mesh today. The -- I think the main reason is what was just alluded to there. It's extremely complex to deploy it. And I would also argue that for the great majority of enterprises, it's questionable whether or not the capability that service mesh provides are really worth the cost and just the overhead of doing it. I mean service mesh is great if you're Lyft, for example, where a lot of the invoice are reported, of course. They need to build this like planetary-scale application. You've got an entire team of software engineers that looks at that as like the absolute core of your business. Your needs in that situation are a lot different than a mid-market bank that's really just trying to keep your application up and going. It's not going to see enormous differences and spikes in demand. So one of the things I often tell customers is until you get to the part where you feel like you've exhausted the capabilities of kind of the standard tool set being defined as what you would get with whatever Kubernetes distribution you prefer, whatever your cloud provider Kubernetes service is, really doesn't make a lot of sense in most cases to try to add service mesh on top of that. And very few organizations really have needs that are so sophisticated that they're not well met by what the underlying platform already directly provides. And I guess the other aspect that I would say is in my opinion, I think it's going to be more likely that the things that are valuable out of that service mesh layer, if you think about it being sort of on top of the Kubernetes layer, whatever is actually found there to be valuable to organizations will eventually kind of percolate down into the underlying platform itself, where it will be easier to deploy, more integrated, simpler to support and manage. So it's not as though no one will use a service mesh, but I just think that the large majority of your typical enterprises will not see enough benefit to justify its complexity. And those features that are desirable for them will eventually just make their way down into the underlying platforms.

Makes sense. I guess we're always in danger of sort of just looking at the sort of the -- right at the leading edge of the market rather than what's going on in general, I suppose. One of the -- so maybe turning just to -- taking a different kind of lens. One of the things that we are often asked as analysts is whether there is a killer app for cloud native. And I always say, well, it's a bit like asking what the killer app for 5G is when it's really sort of about the bandwidth. But it's interesting to me that now and recently, many or most of the sort of mobile and communications service providers and operators are overhauling the way that they deliver service by crafting cloud native services in order to do all of those things, be agile, do it more quickly and respond more quickly and so on. And it strikes me that actually 5G could become an interesting -- or 5G edge could become an interesting killer app for cloud native. But I wonder in your thinking or in your mind, is there -- how -- do you think that there will be a killer app for cloud native?

I'll take this one, William. I don't see any one killer app. I think the benefits you already alluded to, whether that's faster times to market, faster time to value, being able to deploy faster, get to customers faster, I think that in general becomes that killer app or that killer capability and why I think we'll see increases and more driving in that direction. Look, if you look at business today, the cycles, business cycles are shortening. What used to be a slow-cycle business is now standard cycle, or what's standard is now fast cycle, and what was fast cycle is hyper-fast cycle. So IT organizations are always under pressure to deliver faster for the business. And I think because of that and because of those compressed business cycles for IT to respond is really driving a lot of -- at least, enterprise customers, to really look hard at cloud native as a way to accelerate and meet those business demands and really aligning to that business strategy. So I don't see there being one or a handful of killer apps, at least not from my view, but what I see is killer capabilities or killer functionality that all of the apps can benefit from. And it allows our customers to really then accelerate and do things faster to better align to what the business needs are.

Yes. I was going to say sort of another way to look at this is I sort of see cloud native as the killer app for the cloud, right, as enterprises are sort of contemplating how do you package and deploy applications in the cloud, application containers, like Docker sort of rose up in the market. And now we're sort of seeing that Kubernetes is the killer app for hybrid and multi-cloud, right? In addition to being a container orchestration, Kubernetes is a distributed application platform. And that matches with what organizations are trying to do as they support applications across on-prem, private cloud and multiple public clouds. So it's a little bit different way of looking at it, but I feel like the timing in the market, when we talk about killer apps, it's sort of all about the right timing. And that seems to be where general cloud adoption drove containers, and now adoption of hybrid and multi-cloud is driving adoption of Kubernetes.

Sure. I'd like to ask the panelists just something we touched on is it -- with the sort of the rise of DevSecOps and the -- and I referred to the sort of momentum or the sort of market consolidation in security when it comes to cloud native. I wonder to what extent do you think security this time around can be sort of baked in rather than, a, another capability that has to be integrated or led? Because it seems to me that in the cloud, well, these things are not very well joined up at the moment. Do you think that can happen in cloud native?

The opportunity is definitely there. And when we build Twistlock and what we have now with Prisma Cloud, we really try to give people the software that capitalizes on that opportunity. I often tell people that cloud native has a few fundamental characteristics that really make it possible to do security differently. Cloud native apps are much more declarative. We talked about the notion of them being something that developers have to build that framework and describe what the application does. They're more minimalistic and they're designed to be more predictable at run time. Those 3 characteristics, if you build your security software to be able to learn based on that declarative nature of what the application should do, you're able to leverage the minimalistic aspect of that to be able to do so in a high-performant manner, and then you're able to compare the actual state at run time of the application to what the model would predict for that, it becomes possible to have security much more autonomously generated based on every build of the application. And if you combine that with integrated security, the DevOps life cycle, where you can say every one of those steps along the path from git repo, to build time, to registry, to deployment, et cetera, you can have security embedded in that flow because, again, the entire flow is automated. You really have again the opportunity to do security better. I say opportunity because just like with anything else, simply adopting cloud native doesn't magically make you more secure. But those fundamental characteristics enable you to have a different approach to security, one that's fundamentally much more automatic and much more efficient than what traditional security solutions allowed you to do.

Okay. Good. Thanks. We're coming up against the top of the hour here, and I want to be respectful for our audience. Has anyone got any last comments or thoughts that they would leave the audience with, with regard to cloud native and how it takes the sting out of transformations?

I guess -- this is Jay. I'll just briefly -- we really see a mix of things. As organizations deploy cloud native, no one is all-in on any one thing. They're using some of the on-premises tools that they like. They're using cloud services. They're using SaaS. They're using open source. And I think bringing that all together is a big part of the challenge but also part of the opportunity to leverage what works best.

Sure. Okay. Good.

I'll just add from an experience perspective, we always talk about, look, the experience we're creating is really a reflection on our culture and process. And that's really what we're focused on. So again, whether it's a suite of tools, it's a suite of capabilities that we're bringing, and it's the right mix of those tools and capabilities, whether that's on-prem, off, cloud native or even traditional. But every firm's got to really address the cultural issues and the process issue through that and then start to deploy the right technologies.

Got it. Okay. Good. Well, listen, thanks very much indeed for joining us here in our first virtual HCTS and the first panel session of it. Thanks to the audience as well. And I want to remind everyone if they want to catch up with the next session, A Quantum Leap or an Entangled Dream, presented -- a panel presented by colleague, James Sanders, they need to check out of this session and check into James' session, which starts in about 5 minutes. So once again, thanks to all of my panelists. I enjoyed the discussion and the opportunity just to chat with all of you. So thanks again and enjoy the rest of HCTS. Thanks very much.

Thanks all.

Thank you.

Thank you.

Bye.