Mark Lavi and Michael Haigh

We have to thank you for coming because we didn't even submit an abstract, and you came here just based on the title alone. That is just brave. Brave, brave, brave. Just for my edification, we already kind of got a good sample of who's in the audience, but if you don't mind, put up your hand if you are development. Cool. Ops. Almost half and half. And what we saw, business and analysts, raise your hand. Cool. All right.

One more thing. That's actually good, right? We're pretty much half DevOps and a handful of management and project and PMO, all that good stuff. How many of you are Nutanix customers? Please raise your hand. One. There's more than that. They just don't know. It's okay. Okay. All right. Who would like to make sure that we don't go heavy or even mention product names today? Please raise your hand. That is the plan. I will apologize if I slip into one or two, but that is the plan, okay?

We will do who is Nutanix, though, right? We'll do that. At the beginning, we'll get that out of the way. Michael, shall we start? Yeah, let's get started. All right.

Speaker Introductions

Would you like to introduce yourself- I'd love to ... to the audience? Yeah, certainly. So my name is Michael Haigh. I'm a technical marketing engineer at Nutanix. So on my day-to-day, I get to speak with customers and potential customers like you about our automation and some of our cloud-native products. Prior to my current role, so I got my career started at Cisco. I was a Java developer for a couple of years. I wasn't crazy about that, so I moved over to systems administration in our proof of concept labs and worked there for about six years.

And then came over to Nutanix and worked in support for about three and a half years or so. So anytime any of our customers would have an issue, they'd call in and I'd answer the phone and get them straightened away. And then moved over to my current role about a year and a half ago. What is the net promoter score of our service department at Nutanix? So over the last five years, we're averaging right around 90.

If you're not familiar with net promoter score, it can go from anywhere from negative 100 to positive 100. So 90 is pretty fantastic. Look it up. It's unparalleled. Our customers are happy. Okay. Because they're not trapped behind cloud-first waterfalls and all this other stuff. We'll get to explain all that stuff in a moment. Okay. I'm Mark Lavi. I'm the principal DevOps advocate, which is a fancy way to say is I work for you folks. I work with customers large and small. I started my career at the first national internet service provider. That's why I have these grays.

I worked at a browser company called Netscape, and I was a webmaster there. I taught myself Perl 4 even before that. I've been at startups and start downs over 20 years in Silicon Valley. In fact, I was a DevOps manager of a small cloud VPN company. We had three configuration management systems and 14 public clouds and such. And we were only a 40 people organization. Lots of fragmentation. I actually was part of a startup that Nutanix acquired about three years ago called Calm.

And one of the last product pitches, I promise. But that's how I came to be in front of you now. And for the last three years, I have been working with our smallest and largest customers around the world, helping them understand this DevOps thing, this agile thing, this how do I run the business better thing. And we'll get started with that.

Agenda and Nutanix Context

So let's talk about the agenda. We'll explain who Nutanix is just for getting that out of the way. But the truth is, everything that we're going to talk about is really the customer experience that we have, that Michael and I share in helping fight these battles. Sometimes they're just culture, sometimes they're just our products and bugs. Sometimes it's how do we make other products work really well for you on the platform so that we get DevOps outcomes.

So you already know who we are. The next step is, shall we talk about what is Nutanix? And quite frankly, the goal for us is to help you understand the lessons learned that we have encountered from our customers, right? Our customers make us better, we make them better, and this is the way we pass it on. But does that sound okay? A lot of people signed up, like sponsor workshop, I want hands-on keyboards. Is this an okay agenda?

Make sense? All right, good. If not, it's small enough. I want you to ask questions. Do you want them to ask? Yes, please. Raise your hand. Shout out. And we even have microphones in the front if you want to be amplified. But we want to make this as interactive as possible because-- I'll explain Nutanix in a moment, but because we have this kind of menu of options, right? We're going to talk about whether or not-- In fact, we're going to ask the audience, do you want us to define what DevOps is?

Because there is no universal definition. And if that's helpful, we can do that. Sometimes that's where I start with my customers. Sometimes we talk about what's the maturity model. Where are you on your journey to agile, to DevOps? Because it never ends. Never ends. And quite frankly, Nutanix, we'll explain in a moment, is kind of an infrastructure company for the most part. So we talk to our customers about how they go cloud first, how they break out of Waterfall all the time.

But the truth is, they ask for things that they actually don't want. We'll explain why lift and shift is a trap. Is anybody already nodding or is like, "No, that's what we want. We want cloud first. We need to lift and shift to the cloud." I can't tell you how many customers ask for that. And I'll explain to you why that's-- Well, we'll help you do that. Of course, the customer's always right, but we'll help them get past that because quite frankly, sometimes they lift and shift back.

That's the reality. So, this is going to be the menu for things. And the truth is, we'll ask you, should we just skip what is DevOps? Should we skip lift and shift? Or should we talk about this cloud mindset, things that Dr. Nicole Forsgren called out in the State of DevOps report and why that's important. We can explain these things. So, is this sounding good? Yes. Good. All right. Well, then let's just go back to- All right. What is Nutanix?

Why are we here? How do we actually help make these things happen for our customers? Why are we even important? Why would we come to a show like this? And the answer is, Nutanix is a DevOps company, but our CEO doesn't say that enough, and I'm working on that. Okay. So, if you're not familiar with Nutanix, you want to do the 30-second elevator pitch? Sure, I can do the- We're going to do dueling elevator pitches. Yeah.

You go first. All right. So I always, whenever I get asked that question, I always have to gauge how technical the person asking me is. Not very technical, I'd say. We essentially enable our customers to have public cloud-like features in their own private data center. So, ability to expand your data center, your cluster, add, compute virtualization, storage, any of that piece by piece. So, that's the real quick summary. We have a lot of products that sit on top of that and are enabled by that kind of core platform.

Exactly. Here's how I explain Nutanix to my kids, and they go, "Ew." So on three, go, " Ew," after this. Nutanix is what happens when Apple and Google have a baby. Ew. Right. Yeah. My kids go, "Ew," all the time. My wife goes, "Ew," as well. But long story short is our co-founders came from the Google File System team. Nutanix is literally commercialized Google data center technology. We're a software company. We offer these things as subscriptions.

And what you can see, ultimately- Move this chair for you. Sure. It's getting in your way. Am I talking with my hands? What you can see, we'll just focus this down, is the core product is literally clustering software. We software-define data centers and help our customers re-platform out of what we consider legacy three-tier, typically your Dell boxes, your Cisco routers, your NetApp storage. These are three different vendors. Well, we've shrink that all down into a Lego brick experience.

Now, first thing we do is we drive this software-defined data plane, software-defined scale out. It's cloud native. It's built with ZooKeeper and Cassandra. Deduplication is a MapReduce job on this. You getting the idea? We normalize all of the hardware vendors. And by the way, that includes public clouds. So, if you want to run a Nutanix cluster on GCP and on Dell, on-prem and off, that's instantly out-of-the-box hybrid because the control plane spans these things. So, Nutanix is a hybrid cloud solution.

We drive that storage to underpin hypervisor, so our customers bring their workloads as they're comfortable onto the platform. We drive micro-segmentation on top of AHV. AHV is our industrial-strength wrapper around Linux KVM. Our position is that the hypervisor is commodity. It's just included with the platform. Customers can and also do run ESXi or Hyper-V as well. Of course. So whatever you're comfortable with. Right. Customers bring their full stacks on top of us. Sometimes we're just storage for them. But as you can see, we go up the stack.

We can drive all these kind of additional interfaces onto Acropolis storage so you get more return on investment. Database as a service, Kubernetes as a service, backup as a service. But this automation that we have with the control plane doesn't just go to hypervisors, it goes to public clouds. Nutanix became a public cloud provider a year ago, and we have a bunch of SaaS services. I'm not telling you the product names except for Prism and Acropolis, because we have too many. So, we won't do anything more.

That's Nutanix today. Long story short, we're a platform of value. We help you have multiple vendor strategy built into this with a cloud native experience. And we will try to tilt you towards the left-hand side to get an all native experience on Nutanix, because we can drive automation for all of this. And that's how we get to, and this is where we'll end up at the end of the day, how we do ephemeral CI/CD pipelines for 17,000 developers at one of our customers.

This is how we create DevOps outcomes, because the infrastructure is a solved problem. All right, enough of the pitch. Let's begin.

DevOps Maturity, Pets, and Cattle

Who wants to hear anything about DevOps? Who wants to hear the definition of DevOps and all this other stuff? Unfortunately, that's a vast minority of this room. Should we say majority rules? Because the truth is, the first half of this agenda is pretty much slideware, and I can go through it separately with you. I would be happy to do it. But again, we're going to make this interactive. Ask questions. We're going to skip what and why is DevOps.

I will show you the maturity model really quickly to see if that percolates any questions. Fair enough? All right. You should be able to use the clicker. I know, but I want to skip. I don't want them to see- Oh, okay ... all those slides. That would be- Yeah. No, I got it ... that would be teasing them. All right. If I were to summarize the last three years of what's going on with all of our customers, they have only two business problems. I can break it down to just these two.

They need to go faster, and they need to go everywhere, meaning they want to be hybrid. But the truth is, they're just trying to get a private cloud done, because I told you, most of our customers are the operators. We're an infrastructure company primarily, but now you know what we actually do do. And so, everything is like-Can you help me get to Amazon? Can you help me come back from Amazon? Can you help me get to Amazon and Azure?

And so this is the scale. We don't want to have pets. We want to have cattle. Are we all familiar with this term, pets versus cattle? Raise your hand if you're not. That's enough. Let's define. That is half. All right. I will go back one or two slides. Long story short is that I ultimately, with our customers, say DevOps is the key to agility. That's all there is to it. I'll skip my definition, but pets versus cattle, this is the second lens, and this is what unlocks the scale factor of these things. So let's talk about pets versus cattle, super quick right here. All right.

Long story short is pets are your single points of failure. And your single points of failure can be people, can be your infrastructure, can be your architecture, can be your operations. It's multidimensional. Any single point of failure is something we need to remove in order to achieve scalability. It's that simple. And for my colleagues in India, we usually say livestock. I apologize for being slightly culturally insensitive, but it is the meme and you'll see this everywhere now.

I want you to look at the world and look for the pets, the only one person who can do the handoff. Who read "The Phoenix Project?" Brent is right there. He's a pet. He's a single point of failure for getting the database fixed at 4:00 in the morning. He's the only one who could save the world. Now let's go back and do the definition more succinctly. And how are we doing? Are we doing good on time?

We're doing well, yeah. Okay. So the goal is to move to fleet management, service level agreements. No single point of failure. If something fails, we don't go and remediate it because we have an emotional attachment to it. We named it. We take it to the veterinarian. It's a pet, and it's important to us. No, we have a fleet of them. We remove that node, we bring another node up, and we keep our service level agreements up. So you can see that we don't care about scaling up and adding more resources into an individual VM or Docker container. We care about scaling out.

That's the difference between a pet, giving it more resources, feeding it more, and scaling out, which is a fleet. Yes, sir. I've never thought about it, but as the person being a pet, a single point of failure, what's the recommendations to get around that? Oh, I'm glad you asked. So did everybody hear the question? Nope. What's the recommendations for pet culture and pet ops and everything? Specifically around employees, though, right? Yeah. Oh, yeah. Employees as the one at risk.

So the answer is you need to adopt the DevOps mindset. Your value is in helping enable your organization to do your job so you can get to your next job. Actually, so you can get to your backlog, because who has a backlog that's going smaller? Please raise your hand. All right. Yeah. Could we all applaud this gentleman? I want to work for him. All right? Seriously, what's the secret to your successor? You must tell us now.

Easy. Slow, PMs or PO. Is anybody else having a shrinking backlog? Does everybody else? You're an anomaly. Thank you, but that's wonderful to hear. The point is I tell people, "Don't hire DevOps people. That's a mistake." And they're like, "Why?" Why? Because the DevOps people inherit all of the cultural and technical debt of the organization. When I was in this 40-person startup as the DevOps manager, the customer support people are like, "DevOps does that for me.

That team does it for me. I don't have to care about how we ship updates to the customer." Yes, you do. The developer's like, "No, DevOps is going to take care of the release and even keeping the build systems up. I don't care about the build systems." Yes, you do. So we actually had to rename the DevOps team so that everybody started to understand DevOps is a mindset that we share. We all become DevOps, and if you know my DevOps definition, I'll tell you what that is. But long story short is we all share in the responsibility of delivering value to our customer. All right. You've heard my DevOps definition, right?

It's a business mission. And so the answer is, yes. You tell your manager, "I'm a pet. We need to scale this out. I don't want to be a single point of failure. I want to be able to go on vacation. I want to be able to have a sick day. I want to be able to sleep on the weekend, and I want to not have change controls anymore. Can I get a platform that doesn't make me stay on the weekend?"

Own it. Own your pet worthiness and become livestock. All right. Did that help answer the question, sir? Yes. We're actually trying to implement a DevOps mindset where we're at. Good. Cool. Any other questions? All right. Now we got pets versus cattle. Make sense? Good. So look at the world and you'll see pets versus cattle. So let's take this now to the maturity stage. So when I explain DevOps and when I explain pets versus cattle, and I did this for a large government contractor on the East Coast, before I even finished this much explanation, they're like, "Oh my God, we're a pet shop.

We're at stage 0.5." They identified where they are on this journey. They found out that they were in the lower left-hand quadrant, which means that they're typically in a pet data center, maybe with a pet hypervisor, maybe with one pet cloud, and they don't have the ability to go multiple places. Dr. Forsgren said how many of the organizations out there in the State of DevOps Report who are DevOps savvy actually have a working disaster recovery plan that was tested in the last year?

40%. I'd be curious how many people in this room have tested their disaster recovery plan in the last year? Good. About half. I think we can say 40%. Yeah, right about 40%. Yeah. I think we can say 40%. Is that good enough? If you haven't tested your disaster recovery plan, you don't have a disaster recovery plan. If you haven't tested your disaster recovery plan, you don't have a disaster recovery plan. Absolutely true. So we need to be able to cattle our workloads.

We need to be able to go anywhere at any time now. So this is how we start to show the journey of this world of ephemeral anything, anywhere. That's the upper right-hand quadrant. And people start to see the journey, but they also start to look at their vendors and their platforms, and their tools and their culture, and they see that the reason why they're trapped in the lower left-hand quadrant. Does this help? Now, this is too simple.

The truth is, we have silos. That's all there is to it. So let's move the infrastructure forward. I work with the infrastructure team, work with the operations team, I work with the development team, and we talk about the pets in their architecture. Right? Then we talk to the operations team, and we talk about the pets in their operations, because only one person can do that. There's only one person who can save the business. Wrong. So we help them mature and look at this.

And the truth is, most of our customers, they start off in the upper left-hand corner, and they start working to get to the lower right-hand corner. And as they progress through these things, the silos start to come down, because truthfully, when your operations and culture start to align, now operations becomes delegatable, and we can start talking about serverless, can't we? Make sense? We can talk a lot more in depth on this, but you start to see the journey.

This is what we do for our customers. We just start the conversation. They tell us all the problems, then we try to find a solution to accelerate something out of it. So that's it. All right. Let's go back to the menu. Was that good? That's DevOps maturity. Yeah. There's the menu. So, onto lift and shift.

Cloud First, Cloud Smart, and Lift-and-Shift

Let's talk about cloud first and lift and shift. Is this something of interest? Please raise your hand if it is. Right. It's part of the title. That's why you're here. Thank you. But I wanted to confirm that because everybody's like, "No, no, no, Mark, I got it under control." So, do you want to take this on a little bit? Do you want to talk a little bit about how people approach cloud first and cloud smart? Well, let's do a little conversation about that.

Yeah. All right. Let's pull up the chairs. They squished out. All right. Hi, Michael. How are you doing? Pretty good, other than I think I knocked our monitor out. Oh, there it goes. It's good. A little static electricity there. Yeah. Yeah, so cloud first. So often I cover our automation product. And so I'm talking with customers quite regularly, and we have a cloud first mandate from higher up. And so, the product that I talk about, that I cover, allows us to deploy and do automation both on-prem and in the public cloud. So often, I'm talking to customers that have these cloud first mandates. So we talk about challenges they have, and things of that nature. So I guess my first question is, what's your biggest concern? So if you walk into a room, and what's your biggest concern when a customer says that we have a cloud first mandate?

I ask why. Because is it to make the business run leaner or faster? Because the truth is, cloud first might be the mantra, but that may not be the business reason or even justified for why to do it. I'll give you an example of how we try to improve the conversation. We'd start to talk about business and how you manage your resources. We try to explain capital expenditures versus operational expenditures. In other words, why will you rent or why will you buy where you place?

And the truth is, we'll get to cloud smart in just a moment, what is the right model for operating your workloads? It might be perfect to be 100% in the public cloud for certain workloads. It might be 100% only justifiable to be on-prem. And the answer for almost all of our customers is, "Well, we're going to start here, we're going to go there, but we think we'll probably end up in a hybrid fashion." And nobody denies this. Everybody understands that hybrid, a blended model of OpEx and CapEx, on-prem and off-prem, is the wisest way to give you the way to manage your business most efficiently. The benefit of the public cloud is utility computing. Be able to turn it on and turn it off.

But when you run it 24 by 7, you have lifted and shifted your 24 by 7 workloads into the cloud, and do we live in hotels or do we rent hotels? When we come to Las Vegas, we rent a hotel for a couple of days, but I would never move to Las Vegas and live in a hotel unless I was very rich. It does not make fiscal sense. So the benefit of the public cloud is being able to turn on a data center to get to your customers and give them the lowest latency for the eight hours that your customers are up, and then shut that down, and then turn on another public cloud halfway around the world for another eight hours, and then another public cloud. That is the benefit of the public cloud.

We treat the public cloud like cattle. And we get the benefit of it. Hey, Mark, on that note, I have a question. Sure. So often when, again, when I'm having conversations with these customers, they talk about the ability to move workloads and more than workloads, move data- Yeah ... to the public cloud and back. So I'm curious about getting your input with that in mind, with regards of the pets versus cattle discussion we had earlier. Sure. So data has gravity. You've heard the term data gravity.

It's the most important asset of your business. The truth is, a database is a runtime and storage for that persistence, and the runtime engine only does transactions on that persistence. So what we recommend to a lot of customers is start at looking at your database as cattle, and cattle your application needs. Maybe ElastiCache or Redis is the right way to do part of your application caching, and maybe that is cloud native, and it doesn't matter whether it's on-prem or off-prem, because we can replicate very easily between these things.

Relational databases that span data centers require significant network infrastructure investment in order to do really good RPOs and RTOs, right? To have disaster recovery for these things, and you design appropriately. But we try to help customers understand that databases can be cattle in the way that they solve your application needs for your business, and you can rationalize what's the right way to approach the problem. And the more you can adopt a cloud-native database, well, it has this replication and the ability to be eventually consistent, which is the appropriate use case for certain parts of your application.

Things that are lossy, in a sense, right? Your transaction history, maybe that's not lossy, maybe that needs to be a relational database. But your session keys are ephemeral, and therefore, they should be segmented and sharded and put in a cloud-native thing, and then it doesn't matter if it's in every data center or not. It's a local data store that can be thrown away. It's cattle. Yes, sir. I have a question. I was interested in that And you can use the microphone, too.

Right there. It was meant for you. Hello. Hello. I apologize. I'm sure my voice is a bit severe over this microphone. When you talk about databases being cattle, in that scenario, what's the data? Exactly. You're talking about the data storage mechanism can be cattle, i.e., relational database tends to be more pet-like. Yeah. I'm getting us, you mean-- I'm just thinking in the scenario where you say, "Oh, your database is cattle," where's your data then? Well, your data still resides locally, no matter what.

The question is whether or not it can be replicated. Whether the platform of the database or the underlying hardware platform provider can replicate. And the truth is, you may need both. In fact, you might want both. In fact, you should have both, so that you have all options on the table as you change things around. So it's not an easy... Huh? I scared some people away with my voice. No worries. It's okay. I understand that. Yeah. So there is no simple answer there.

Database persistence across multiple data centers is a hard problem. Understood. But you need to search for the solution that supports this scenario so that you can cattle your database. Let's say that is a requirement now for your working vision for how to run your business from this point onwards, then we've done the right thing here for you. Any other questions on that topic? Did I answer your question? Yeah, you did. I think it kind of goes back to... Oh, I might be jumping ahead, so I'll- Yeah ... hold up for one moment.

No, no, whatever. All right. So we talked about cloud first, right? Going to the public cloud blindly is not the right thing. So about a little more than a year ago, President Trump signed into legislation that the cloud smart approach is now the government policy. And let's point to that slide so you can see this. And long story short is the cloud smart strategy is because the government over-rotated on cloud first. So what is cloud smart? It is application rationalization. We find the right cloud, the right operating model, the right vendors, the right fiscal model, the right governance model, the right operational model, the right architectural model for how we run each application. And we decide that application by application.

So where did I put that? Oh yeah, here. So, footnote number two, cloud.gov strategy. So the government doesn't think cloud first anymore. They think cloud smart. And it is really, let's find the right operating model for our workloads, as opposed to blind faith in the public cloud and lifting and shifting to the public cloud. Let's talk about lift and shift. We didn't even talk about lift and shift. That's what I was thinking. All right, so- ... told you a lot of our customers are infrastructure folks.

And the way they look at the world is disaster recovery, backups, snapshots, right? That is the tool that they have for moving persistent workloads, quite frankly. And let's not talk about monolithic workloads versus distributed workloads. Let's just assume, in the simplest use case, that they just need to lift and shift a VM at a time to the public cloud. Can you help us with that? Sure we can. What are we, in essence, doing in facilitating this, is that we're making sure that the disk snapshots happen, and then we have a sync job to make sure every delta for the blocks writes onto that platform locally gets replicated over the wire so that we have a constantly updated snapshot, in essence. A dynamic snapshot, if you will, replicated over the network.

And if you have to change infrastructure providers and hypervisors, well, we also have to do that translation job, and we also have to have that secure channel, right, to do a lift and shift appropriately, right? One VM by one VM by one VM. So customers ask for this all the time. Now, we already know that one year later, they ask, "How can I lift and shift back?" Because it's too expensive to do this as a rental model, right? Can't tell you how many times that happens.And then we try to say, "Well, what's the problem with lift and shifting back?

We don't want to help you do that." They're like, "What? You don't want us to come back on-prem?" "Yes, we want to come back on-prem, but let's do it the right way." The problem with lift and shift is that all we did was kick down our technical debt down the road. We didn't solve the problem of how do we cattle our databases and our persistence. We didn't solve how we cattle our business and our operations and our architecture and our infrastructure. We didn't DevOps this problem.

And what that means is that we have eschewed automation, we have eschewed synthesizing workloads, we have eschewed having the ability to spin up a workload anywhere at any time now, and then globally load balancing and globally replicating appropriately. This is not a mystery. Everybody's like, "You're right. But how do I do that?" And that's where we get into all the real, actual customer discussions, and then we talk about our products and all this other stuff. But when we finally can agree on what the end result is, hybrid, and when we can agree upon what the way is to do it for operations and governments and all this other stuff, cattle, then now the discussion's not about alignment of culture, it's not about how do we do the operational model. It is how do we start on this?

Because it's not going to be an overnight big bang project. No. It's experiments and how can we accelerate even the experiments? And that's what we help do a lot. So what would you recommend if, say, I was a customer that, regardless of the cloud, maybe on-prem, just any cloud, and I'm looking to implement from a technical perspective, more DevOps methodologies. I have my large monolithic application. How do I break that up? It seems like such a monumental task to get started.

So what's a recommendation just for that first step? Oh, you put it in a container and magically you run it on Kubernetes and you're done. Which again, you think customers ask me for that all the time? And then I ask why? No, the answer is that we have to talk to the development team. We have to talk to the test team. We have to talk about what is the application architecture and what would it take to synthesize this.

Do you have push button deployments of dev test workloads? If so, then all right, let's talk about refactoring it bit by bit. Do you have the source code? Do you have those developers? If not, that's the problem to solve, and that's got nothing to do with infrastructure. It's about operational or business consistency. Do you have the source code? Can you maintain the source code? Can you build the source code? So we help them solve those first principles first and foremost. And so then it's educating the developers on how do we do distributed applications.

What is a container? What is Kubernetes? How do we do persistent storage with Kubernetes? How do we start to solve the hard problems instead of just lifting and shifting into containers? Do you see this problem happens over and over again? So I'm giving you the lenses with which to deconstruct the world and solve problems very simply. It's not complex. We make things too complex all the time. Now, reversing that complexity is incredibly hard. Don't get me wrong, but it is the only thing we should be doing because anything else is a waste of effort, because you will just lift and shift back once you fail there, or lift and shift back once you have risked the business by being fiscally irresponsible.

And it's hard when I tell customers that, because I don't tell customers that right off the bat, I say it in a much nicer way, but I'm telling you what we eventually get to when we have honest conversations about how to run business effectively. Cool. Thanks. All right. Should we go back to the menu? I think so. How are we doing? Any questions? Is this okay? Are we doing okay? Very good. Is this valuable? All right.

So we talked about cloud mindset effectively, and cloud smart and cattling everything. We talked about CapEx, OpEx. Agile Sysadmins and cloud infrastructure, is that of interest? I see yes. Please raise your hand if that's of interest.

Agile Sysadmins and Cloud Mindset

What is that, like a third? That's not a majority. Two arms. We're getting some feedback. Tell us. All right. Agile Sysadmins and cloud infrastructure. All right. So when Patrick Dubois met Andrew Clay Shafer almost a decade ago. DevOps is about 10 years ago, 2009. First DevOpsDays was in Ghent, Belgium, and I think it's going on right now. The 10th anniversary in Ghent is going on. That's where Andrew and Patrick are right now. But we got John Willis here.

And we got Gene. It's okay. And we got Nicole. Do you know Nicole Forsgren's nickname in the DevOps community? She's the Chuck Norris of DevOps. She's awesome. So yeah, about a decade ago, Patrick created the Agile Sysadmin group in Google Groups, and two or three months later, we see the term DevOps and the first DevOpsDays planned in Ghent, Belgium. So that's a decade ago. And really, I talked to Patrick about three years ago at DevOpsDays Austin, and I said, "Do you know what Nutanix is?" And he's like, "No, what's a Nutanix?"

You know what a Nutanix is sort of now, but I'm like, "It's agile infrastructure. It's for agile sysadmins, and we automate a lot of these things." So that's what we got. But cloud infrastructure, you now know is a mindset, and it doesn't matter what the infrastructure provider is or where the infrastructure provider is, cloud is a mindset. And Dr. Forsgren also pointed out in the State of DevOps Report that the people that exercise a cloud mindset, that literally cattle all their infrastructure providers, are 24 times more productive than the ones that don't.

So again, cataloging things is really the way we all want to get to go, and that's how we do that. So that's how I want you to look at infrastructure now and your operations with that kind of viewpoint. How we doing? All right. Shall we move on to the next topic?

Demo: Self-Service, Ephemeral CI/CD, and Hybrid Applications

So I think we're in the final third now. Bridging the divide between ops and dev, or how do we do DevOps? This is where I think, if you don't mind, we won't mention products, but we will show you DevOps outcomes with the products in effect. Is that okay? Would you like to see ephemeral CI/CD pipelines? Michael, take it away. All right. So I'm going to hop over into a demo environment, everyone. And holler at any point if it's a little hard to see, too big, too small, let me know.

Or questions. Or questions about any of this. Mark mentioned earlier we have this single pane of glass to manage both on-prem and public cloud workloads. This is the interface that you see right now, enables you to do that. Again, on-prem or public cloud. A lot of our time here we're going to spend within an automation product of ours. So I'm going to hit the menu icon and come down to services and select that product. One thing we didn't really talk about a ton, Mark, was self-service.

Yeah. I don't know if you have any comments there, but- Yeah. The majority of our customers, once Nutanix solves the infrastructure issue for them, the next thing is, how do I do a private cloud, and how do I do cloud first? Those are pretty much the two things, and the 80% use case of that is, please give me self-service VM as a service. Just infrastructure as a service. Give me Windows or Linux. That is 80% of what our customers are still working hard to do, and that is table stakes as of a decade ago in the public cloud. Right?

We have customers that have six weeks of trying to provision a VM because the governance is that onerous, when it's really only 30 seconds of operations. Everybody knows this. So we help customers bring that all down. So self-service of VMs, just IaaS, is a huge problem that most of our customers still have right now. Do any of you still have that? If anyone's willing to raise their arm. No. All right. Developers need a VM now. They need a dev test environment now.

They don't need one VM, they need dev SAP HANA. Right? Splunk, dev Splunk. Give me one of those so I can break it, do a security patch update on it, do a performance testing on it. How do I make Splunk ephemeral? How do I make it cattle? All right, carry on. So this particular management plane we have, you can enable your end users to log in directly. We also have plug-ins with things like ServiceNow. So if you're already a ServiceNow customer, you can just have hooks in that way.

This particular menu you're seeing, you imagine an end user would come in and log in directly and launch a Jenkins instance in this idea. Right. For the business, we try to make things like Google Play Store. Enterprise applications can be one click when you finally have a management system that can orchestrate things in a cattle-like fashion. Right? So this is going to essentially launch this particular blueprint, and as an end user, we can select where we want to deploy this application.

On the last page, there's a particular project that's essentially how we handle our back. So if I, for instance, am going to choose this demo project and hit launch, depending on which public clouds or which on-prem environments you've initiated, you can come in and the end user will then select that particular environment. So we see on this particular project, I have AWS and Nutanix enabled. When we say Nutanix, we're talking about Nutanix AHV. We can also register to ESXii as vCenter, essentially deploy on any traditional three-tier.

When we were showing the chart earlier about what is Nutanix and what do we do, this is where it comes into the public cloud and the vCenter, the legacy three-tier. So we have a lot of really successful customers that are slowly growing their Nutanix footprint, but they still have maybe 90% of their environment on that three-tier- Yeah ... traditional architecture. Yeah, remember the 17,000 developers that we're working with right now? We're giving them push-button Jenkins and Git and a developer workstation and their Gerrit and all this other stuff.

We're doing it as containers, but some of those workloads are still VMs because they're not all the way there yet. So we're helping them modernize this, but we're making sure that the developer laptop, which is they always ask for root or admin into Jenkins so that they can make it look like their laptop, right? They want to make it look like their pet laptop. We give them cattle Jenkins so that they can make the official build system look like their laptop, report the differences, report it back into central IT so that the Jenkins masters can finally update to resemble a build on the laptop. This is controlled, this is version controlled, this is software engineering discipline on infrastructure operations and our applications all together.

So push-button Jenkins. Yeah. So those will take about 10 minutes to deploy. One thing I didn't mention in the marketplace, this is- Yeah. Oh, thank you. Yeah. So on this deployment, how are you dealing with data? Yep. Yeah. Back-end data. Yeah. Question. In particular with Jenkins, or in any of these blueprints, or? So in previous incarnation, I actually got it set up where it'd take last night's backup, restore it, and that's a no-no. No, we talked about that. You're lifting and shifting into your next pet.

You're preserving your pet backups into your next cattle instance, in a sense. Right? Pretty much. How are you dealing with that? So I'm a developer, I need some data, but I shouldn't have production data. So are you talking from a database perspective? Database perspective. Yeah. We can talk about that, and I can show a demo as well if we're interested. I'd say some sort of database as a service product for- Yeah ... correct me if you disagree.

Yeah. But we, Nutanix, has a database as a service product. Could be something like RDS in the public clouds. Could be something like Delphix on-prem as well. Right. Your masters need to persist their configuration, and their artifacts, you should persist outside of your Jenkins and masters, I hope. And your workers, I hope, are ephemeral. Good question. You know what you need to do next. Right now, I'm with a new company, since I did that. I understand. But you understand what you need to do next.

You need to make those workers all ephemeral. So no state, and therefore you can spin it up anywhere at any time. But yeah, your masters, you need to basically figure out what's the persistent strategy you need for it. And the truth is, now that we have Jenkins files, they can be part of the code base. So the jobs aren't the issue anymore. It's only the Jenkins configuration. Can start looking even at Jenkins X if you're at a new company, take a look at Jenkins X. Still a little experimental, but all Kubernetes-based it and completely ephemeral. Even the masters.

Everything gets pulled out of Git. Yeah. Git is also the other answer. So GitOps your CI/CD pipelines is definitely possible now. But yeah, persistence of data is still a challenging problem. Look for systems that are holding you back and reevaluate new systems every once in a while. Jenkins X may not be the right thing right now. It's still very experimental. Yeah. Thank you. So the marketplace also, we, Nutanix, put in a lot of commonly used applications that you're welcome to launch and try out and use.

You can also publish your own internal applications as well. So let's take a look at a very rudimentary application, essentially. We'll tie back later. I have more of a production, which is probably a no-no for Mark. Production Jenkins instance that has longer lived, that is already stood up, just so we don't have to wait about the 10 minutes. Yeah. So let's check out that blueprint. Yeah. When you have ephemeral masters, you start to figuring out when containers are the right optimization for ephemeral operations. This is a journey. It takes time, but carry on.

So you can imagine this is a blueprint. You can think of it as a blueprint to your application, similar to blueprints of your houses. This is how this application is defined. Everything from the various services of that application to how that application is stood up. So I think in one part, Mark was talking earlier, step one is mapping out your current application. Yeah. And so that's what this is doing. On the back end, we're deploying a Postgres database with our database as a service product via API calls.

We have our web servers in the middle, and then nothing complex, just an HAProxy VM, essentially round robining between these. Right. Now, part of creating a master might be restoral from another master or your master backups to make the masters a little bit more ephemeral. Right. Do you keep around-- So for a database, would you keep around an old copy that's for test or whatnot? Is that what you're kind of- That might be an optimization exercise that could bootstrap it.

You might actually export your data only. Or your MySQL dumps, or your Postgres dumps, or your Oracle dumps. Multiple ways to do it. You might use Delphix, you might actually restore the entire database from disk. We have lots of ways to solve these problems. You have HA and things like that. The question is, what's the right thing? And it might be different application by application, environment by environment. No one size always fits all. So we have a little bit of advantage there, with Era, since we essentially understand the entire platform from top to bottom, for our database that's running on Nutanix.

You can have your gold, your production database, and we can spin up clones for that, for your developers, or dev, or tests, and we can refresh those clones. We can do all that in seconds or milliseconds because- We understand the storage ... we understand the storage. So it's not actually duplicating that data. It's just, "Hey, let's do another metadata pointer." Exactly. Do you do randomization on it? I'm sorry? Do you do randomization? Like to- Lines. Yeah, to hide the data? Those would be- Yeah ... post-processes after you've instantiated your dev test database. Yeah.

So you can do a script, right out of the box. I think that's a feature that's coming out this calendar year. Yeah. But our automation can trigger those APIs and do those actions directly, too. So we have some of it. All right, it's a little bit in the product space. We have some of the automation built into the product for that, so that the DBAs can manage their own domain, if you will. They can also delegate that domain, which is really important.

But in addition, this automation can trigger those things and put further automation outside of it into it as you see fit. Multiple ways to skin the problem. Cool. So now that we've essentially mapped out our application, we can go and launch this app a dozen different times, and we have a dozen different applications running. We can set up various runtime variables. We can have drop-downs as well. But once we have this running app, I'm not actually going to launch it here.

I will go to my traditional application. I told you our control plane is web-based. We are exercising all of the restful APIs of the platform. If you don't like the way we do it, or you want to do it a different way, or you want to put Jenkins in front of this, or you want to put ServiceNow in front of this, or you want to put your own APIs or self-service portal in front of this, please be my guest.

So now we have an application that's running that we can manage. We can go to the audit page. We can see I've triggered this update app action. So I'll show what that is in a moment, but that's essentially how we're going to create a CI/CD pipeline. And so this is going to be talking to Jenkins, and Jenkins will just be calling this update app. We can trigger it manually. If we go to the manage here, we can see this update app.

If we zoom in, it's nothing super complex. We're essentially taking a web server out. We're going to be updating one of the web servers, putting it back in HAProxy, and then repeating the process on the second. Right. We try to make the operations visible so that you can even talk about how to better parallelize things, where the right dependencies are. And you can further optimize your operations because it's finally visual and delegatable, and your DBAs and your firewall folks and your storage admins will start arguing about how to do things better when it's all finally on one page.

So let's take a look at this actual application. So this is my very fancy app. I don't think there's any worry about me leaving to be a web developer for my boss. But we can see here, if we refresh the page, it's toggling up here between web server one and web server two. .135 and... Oh, no, that's the load balancer. That's the time. So WB1, WB2. Yeah. Yeah. WB1, WB2. So nothing complex here, just going back and forth between those.

Yeah. So let's go ahead and make a change. Oops. Get that at the top of the buffer. And actually, first, we can do a Git status, see that I'm clean. We can do app.py, and I'm going to change my message. So if you didn't notice... Oh, excuse me. I am- Well, you can change it back. It's Hello- Yeah ... DevOps Enterprise Summit. Is that what the version is right now? No, I'm on Hello World. So let's see what happened here. Am I in the right?

Oh, you were one behind in your Git commit. I was one behind in my Git commit? I think that's what I said. Ah. Nothing to commit. You overhead- Oh, I have not pushed. Aha. Thank you. All right. I have not pushed. Let's do a Git clean or a git... It's real. Yep. We're tempting the demo gods. Yep. All right, so we're just going to go ahead. We can see we have my one commit here, so we're just going to go ahead and push.

Essentially what I have done here, if we do the vim app.py. Yeah, you can push Hello. Yeah. Change it back to Hello. So I have Hello World here, and we saw back here, I have Hello DevOps Enterprise Summit. Yeah. So we made that change and essentially, I was testing out earlier and I forgot to run- Ship the fix. Ship the fix ... the Git push. Ship it. Ship it now. So we will go ahead and hop over. I'll open up our Jenkins server as well, and we can see that get triggered.

And I'll log in here. And we can see this, and we'll see that get triggered. And coming back into our traditional app. Was that too fast? Did you see a job had failed? Here, I will. I'm keeping them honest. Thank you. So we see here, I'm going to be updating a couple. I'll talk about this hybrid app later. But essentially, this first piece, update the traditional application. We can go to our build and do a console output, and we are essentially connecting to Calm right now.

So in a moment, we- There's your Git commit. Yep. Oh, yep. Here's the Git commit, the information. So we should get all kinds of information about the particular commit ID and the branch, and we can see my commit message, updated banner message- Very cool ... and so forth. So in a moment, here we go, we should see this update app action get triggered. So we've already updated the first web server, so I should be able to refresh this page, and we see it change back to Hello World on web server one.

All right. And web server two will follow eventually, right? Yep. So keep refreshing. It'll stay on that, and then web server two will come up. Now, we did not make this the ultimate Kubernetes everything else and completely scale in and scale out right now. That's because for most demos, I have to walk my customers through monolithic VMs. So we have to crawl, walk, run. This is meant to just illustrate things. But the takeaways are Jenkins can be one click.

And then we can put it into pipelines, and then we can make those pipelines stood up and configured ephemerally, and then we can make the application that those pipelines configure ephemeral as well. So you see how we try to get out of the lift and shift of one master at a time, one backup at a time as the way of doing things, to build things to be completely synthesized and driving other synthesized processes so that the automation feeds on itself and the business thrives more efficiently, faster, anywhere, anytime.

All right. Cool. Show us the next one. All right. So maybe from higher up, we have a mandate. Let's be able to deploy to AWS when we- Yeah ... when we need to, or perhaps scale it, burst out into AWS. Cloud first. So let's see how we could do that. So let me- But don't lift and shift to cloud first. Don't lift and shift. Don't lift and shift. So it's as simple as we already have this defined.

Is a web server that's running on-prem going to be that drastically different from a web server that's running in AWS? No. Let's provision a similar VM. Let's provision similar resources. Let's provision a similar operating system. Maybe the credentials change, but those should be ephemeral. Those should not be pets and hard-coded into them. So right there, we essentially switch that AHV VM over to AWS. I did it pretty quickly. Just toggled this dropdown here from AWS, or excuse me, from Nutanix to AWS, and then cloned from the environment.

Essentially, I'm cool with the preset settings. Now, obviously, I can choose or change any of these fields if need be. But now we're ready to go ahead and deploy, both onto AHV and onto AWS. Right. So we just refactored our workloads across a new provider. We added another provider. We cattled. That's how simple it should be because this is the way of the world that you should demand for how you want to work from this point onwards.

This is how you get Google to compete with Amazon to compete with GCP for your business every hour. Make them earn your loyalty. Make us earn your loyalty. We help you have multiple vendors under your control. That's what we do. That's how we democratize and cattle the entire industry on your behalf. So what about Kubernetes, Mark? I've heard- Oh, I need that now. Don't give me just Amazon. Give me Kubernetes right now. The developers are ready to do containers.

Do you want to spin up a Kubernetes cluster real quick? Now, what is a Kubernetes cluster? It's another infrastructure provider. Do I care if it's on-prem or off? Do I care if it's AKS or EKS? Do I care? Do I care if it's OpenShift? Or do I care if it's one of Nutanix's versions? I just want Kubernetes, and I just want to add it in, and some of my developers are ready for containers, and all the others are still building things with VMs. Can I put these all together? Can I hybridize all of this stuff?

Can we do that, Michael? Yeah, I think so. Let's deploy a Kubernetes cluster. Sure. All right. So first choice, prod or dev. Again, single point of failure, maybe fine for a development cluster. Certainly do not want that single point of failure for our production clusters. So let's select that. It's a little bit more interesting. And so we'll name our Kubernetes cluster. We can specify the various versions, the particular actual physical cluster it's getting deployed onto. Could be running, again, in AWS with our AOS on AWS and our host OS. So we'll leave that.

And then this is essentially where we define all of our worker resources or master resources. So you can override the defaults, but the truth is, next. One thing I do want to show, we can put it behind an external load balancer, do anywhere from two to five masters. Mm-hmm. But yeah, for most demos, leave it. Again, you can override any of these, but we'll just hit Next. We're going to handle all the networking for you. Today, we support Flannel.

Again, I can just leave those as defaults. And then finally, we handle the persistent storage for you. Again, it goes back to since we have the whole stack, we push out a CSI provider. So even if you don't use this particular product of ours, you can install the CSI provider on any Kubernetes cluster. Right. We help people make OpenShift that much easier for storage and upgrades. We're disruptive in any level of the stack as you need us.

And assuming I did not fat finger that password, in a moment, it's doing some pre-checks right now, including password check. It'll go ahead and start the cluster provisioning process. There we go. So takes about 10 minutes, but the truth is, this is how we can make Kubernetes cattle. Developers can mess up Kubernetes and learn. That's a good thing. Rip up Kubernetes, rip down Kubernetes as you need, ad infinitum. And then, we're working on all the APIs for all this stuff and stuff.

But then our automation can also schedule workloads on VMs and on containers together so that you can go hybrid. And again, we don't care what the endpoint is, who the infrastructure provider is. Just give us plain vanilla Kubernetes, and we have drivers to all the hypervisors and public clouds. Could be GKE? Yeah. So this is the exact same application. So we saw that I switched over AWS. Just to save time, I pulled up essentially a clone blueprint, and now we're actually deploying it onto a Kubernetes cluster as well.

So again, that HAProxy should be round robining between all three of these, essentially, providers. I want to see it. Show me the app. All right, so we'll go to the hybrid app. And we- Seven entities running. Four VMs, three pods. And here we go. So we have Hello World. If I'm refreshing now, we see it's on web server one. That's running on AHV. Now we see we got routed to one of the carbon containers. So earlier- Karbon's our Kubernetes distro Oh, sorry. Thank you. I slipped.

Right. It's all right. No, I appreciate it. Keep me honest. So we saw here, we're actually building the Docker container directly within Jenkins. So we uploaded, or excuse me, upgraded both our traditional app and our hybrid app through a single pipeline. So you may not want to optimize things this way- Yeah ... but when you look at your build process as also deploying cattle to multiple infrastructure providers, then this is just a packaging exercise and distribution exercise.

All right. And then finally, we round robined onto our AWS EC2 instance. All right, cool. So three infrastructure providers. Shouldn't be hard. Hybrid. All right. And there was the update app that we just saw right there. Cool. All right. All right.

Q&A and Infrastructure as Code

How much time do we have? Any questions? Yes, sir. So why multiple cloud providers when Azure or AWS have multiple regions? Or why the different-- Just right now I'm on Azure with multiple regions. Just curious on- Well, that's good. At least you're treating Azure like cattle, which is good. But I have a number of customers in Amazon, and they treat Amazon like a pet. Sometimes they're only in us-east-1. So that's the first problem. Not your problem.

Then the second problem is I was talking to Whole Foods and they got bought by Amazon. That was fine. But then I work in Texas, and I talked to H-E-B, and they're using Amazon. I'm like, "You realize you're subsidizing your competitor?" And they're like, "What are you talking about?" I'm like-I'm thinking. And then went to AIG. I'm like, "You realize you're subsidizing somebody who actually already entered in and left the insurance market because they were only in Amazon, too."

So long story short is that you need business agility. You need to be able to deploy anywhere as a strategic and competitive advantage. Optimize for Azure, but remember Azure should be competing, not locking you in. And this is what we do for our customers over and over again, because they need that business agility. Optimize for what you need to do. Treat Azure like a pet to get started. If that's what you need to do cloud first and you need to go Azure, yes, Mr.

or Mrs. Customer, you're right. I'm going to help you do that. But because I'm going to help you synthesize instead of lift and shift to it, you already can now refactor to everybody else. So that's the strategic advantage we confer to our customers when we finally help them see the end result of this, with very simple principles applied consistently, relentlessly, intellectually properly. But do what you need to do. We're not here to preach. We're here to help.

Ex- We have a contract with Azure, so Oh, yeah. And ask yourself why you have that contract. Because I'm a big company. Yeah. All right. So should we talk about infrastructure as code? Yes. We haven't talked about that at all. Yes. Let's get even more advanced. So now you understand what we try to do, how we look at applications and infrastructure together, how we try to cattle it in every way, how we even try to cattle the operations through CI/CD pipelines and even make those things ephemeral.

Please show me the next generation of all this. All right, cool. And real quick, we see my Jenkins demo that we launched earlier. It is now running, and we could, if we need to, access it. So just to prove, we first have to unlock Jenkins. So fully- Oh, so that was the one you- That was the Jenkins instance ... that was the one you kind of sort of one clicked. Yeah, one click deploy Jenkins. Thank you.

But yeah, let's check out the Calm DSL. So I'll make... How's the font here? Calm's the automation product, sorry. DSL- Yes ... domain specific language. And what is that domain specific language? Is it JSON? Is it YAML? These are typical infrastructure as code formats. They are data formats. They are not code. How do you do iteration in YAML? Well, you use a special runtime engine to figure out how to hack in iteration. So wouldn't it be nice if we actually used real code, Python, to do infrastructure as code? That means we could CI/CD, or C ICD.

So we also see, real quick before I show the Python blueprint, we see that essentially I'm just getting a list of all of these applications, if I come into the UI. So Mark mentioned earlier, everything is doable via APIs. That's where all we're doing here is the API piece. So Calm get apps again and making an API call and getting a list. Yeah. So let's take a look at our actual application. So this is our hybrid blueprint. So again, just to refresh your memory, it was this particular blueprint here.

So we have that Era backend database, different infrastructure providers for our web server, and then an HAProxy. So this is our Python definition of our application. First and foremost, this is a technical preview. This is not sold yet, so you can't buy it. But look towards the end of the year, if all goes well. Caveat. I'm not hyping the stock. Don't make any purchasing decisions based upon what you see here. Everything else you've seen is a shipping product. This is coming in the future.

Thank you for clarifying. So essentially, this is the definition of our blueprint. So again, Mark mentioned that it's Python, it's actual code. I know we were about probably a third developers, so those of you that aren't developers, I think this is really powerful. As a previous developer in a previous life, this is huge. I can't stand YAML. I often can't remember if the dash gets indented or when it doesn't get indented, or JSON's even worse. Yeah.

Because you're trying to figure out commas. So it's very clear exactly how this blueprint is put together. Yeah. Our JSON blueprints, this would be typically over 2,000 lines of JSON, but how many lines is it in the DSL? Let's find out. 455. So I'm guessing that it's about 2,000 lines of JSON, so it's probably 25%. But long story short is that we can test this now. We can version control it directly. We can upload it and such, so this is- All right. So we do a Git status on that note.

This time we see that my branch is up to date, with my origin, nothing to commit, working tree clean. So let's go ahead and make a change. So, maybe I want to go ahead and add an additional service. So in the UI, I could click on the services and hit plus here and add a new one. But again, I'm moved beyond the UI and I'm implementing infrastructure as code. I need to be able to keep track of my application blueprint via Git.

So we can go ahead and make, let's say, a dummy service. And we'll just write and quit from there. And now when we go and do a Git status, we see that it's been modified. We can do a Git commit. So these blueprints really represent business. They represent not only the infrastructure and the topology of the application, but also the operations for provisioning. But every change of control and runbook can also be modeled, because we can provision it and work, we can orchestrate it.

Every permutation and mutation of it is a change control, is a runbook. These can be captured. We put them under RBAC. These are business artifacts, and they are business artifacts as code. So I think we have run up under the end of our session. Yeah. But everyone's welcome to stay, ask questions. We'll be here for... We're not in a rush at all. So, before everyone leaves, do you guys have any questions or feel free to come up afterwards as well.

All right, so final thing. We're just going to thank you, and we're in Booth 603 if you want to learn about any of this stuff. Feel free to reach out to us. It's been a pleasure to have some time with you today. Thank you for coming. If it's been valuable, please leave really good feedback for us, like the best feedback. Michael did stellar job on that demo. I think so. So thank you very much, everybody. Really appreciate your time.