00:02
Thanks for joining us. Uh, we're gonna talk about, uh, platform engineering and AI and VMs and modern world and containers. Uh, before we do that, let me just quickly introduce myself and our chief guest here. Uh, my name is Rajiv Tucker. I, uh, run AI solution marketing for Pure,
00:21
and, uh, previously, just, just about a month or so ago, I've been with the Portworks part of marketing team ever since they were acquired. And uh we have with us James today who'll share a lot about the platform engineering best practices, but before we go into the presentation and also take some questions along the way, James, do you want to introduce yourself?
00:39
Yeah, hi, my name is James Webb. I'm a senior director at Pure Storage. I've been with Pure for about 9 months in my previous role, uh, for 8 years prior. I was at T-Mobile and I was the infrastructure and practice lead for. They're on-premise container platforms. We deployed Cloud Foundry in 2016 and then in
00:58
2018 deployed Kubernetes and uh We're, uh, we're both Portworks and pure customers for, for those platforms, uh, very successful within, within the company. Uh, we, when I left, we, we had a couple 100 clusters, uh, north of north of 10,000 nodes, uh, uh, that was, that were running workloads, uh, very, very successful team,
01:20
and we started doing, you know, I, I think we started doing platform engineering before platform engineering in Vogue. We didn't really think it was, we didn't really know that it was platform engineering, but then once it kind of, once we saw the platform engineering movement start to emerge, we, we, we really fit to some of the, the conform to some of the,
01:36
the uh tenants of it, and, and it really helped us actually. Kind of shape and really formalize our practice into something that was very successful. We ran a very large platform, very efficiently with, with a small team, right? Probably too small, but we would, I, we, I, I don't like to think of how it would what it would have been like if we hadn't uh taken
01:55
some of the practices we're gonna talk about. Yeah, that's fantastic, James, and, uh, folks, how many of you, we, before we start our conversation, by the way, this, let's keep it interactive, right? We, we are a small crowd and if folks want to stop us and just ask a question, just raise your hand and We'll have a mic uh over to you.
02:12
Uh, but how many of you have a platform measuring team, uh, you just do a show of hands in your organizations? That's great. Or do you guys call it DevOps, I guess. I just saw one hand deps engineers platform teams. What is your platform?
02:28
You, you, I I thought you was drinking. Yeah, OK, OK, you, you guys have an answer to James like what, what this is. Platform makes a lot of takes so we're Ubernetis side we have pretty big CICD that's kind of built into that and also HR could be. We're Wrapping that out.
02:56
And it was supposed to be for. Yeah, it's, it's interesting because it's a lot of us came from the like open open systems world, right, where you have very siloed functionality and when you're, when you start to merge into a platform engineering team, it kinda You have to redefine races and people's job descriptions and what they have
03:14
access to, what they don't have access to, and anyways, uh, yeah, so what is platforming, right? It, it's a, it's platforming is really just a discipline, right? You're, you're, um, you're We, we like to, we, we thought of ourselves as an internal, like almost like an internal company or internal organization that was serving.
03:33
Customers internally, right? And we went that T-Mobile at the time, we had a, a saying it was Big C and Little C. Big C was the customers out at like the customers holding their phones, making calls. Little C was the internal customers and our internal customers were, uh, I was part of the infrastructure infrastructure organization.
03:50
Was, uh, the database, the database teams, the application teams and development teams, and they, they approached us with a real problem, right, which was it took us 6 months and 72 steps and have done some presentations about that story, right, our, our journey in the looundry to it, to take something from development to production. So they were looking for a platform to help
04:12
simplify that story, right, is to reduce the complexity so that the developers could be doing, could do what they do best, which is developed why we did what we did best, which was manage the platform and create an offering that, that really empowered our user community. So when you talk about platform engineering, who are the key people,
04:28
right? First off, your customers, right? That's the, your customers are the most important, right? You are, you're being funded or your team is forming to, to build a platform for those customers. Right. You need, you need a set of platform archi architects.
04:41
And the interesting thing is this is not a discipline that like most companies have. It's not something, it's not a, it's not a job role or job title. You have to kind of change, you have to find the right people in your company, change your, change their mindset to operate this way, and then, and then act, act as act as a platform uh architect and really plan for the
05:01
future. And you have your platform engineering team and then you have your developer, your developer experience engineers. So, um That, that kind of, that's kind of the, the hosting view for like a Kubernetti's platform that you know, like you said, there are many different platforms, you know, we're seeing AIs emerges of platforms, so there's some different roles that may be in
05:18
there, but really, really you just want to get people talking to each other, right? I think that, um, I think the infrastructure world had Kind of fell into this pattern where it became very transactional. You didn't, you didn't really understand what your customers are doing. You just had them open a ticket, right? You create a VM,
05:35
you give them back a VM, and they opened a ticket to the network team to create a, a load balancer and then they opened a ticket to the firewall team to talk to something. We wanted to extract all that away, right? So that was our, that was our, our number one goal was customer focused, right? We wanted our customers to be Not just more productive, but we wanted to make their
05:53
experience coming to work and, and pushing their code onto the platform, right, just something they really enjoyed. And James, just for context here, obviously T-Mobil was a highly scalable organization with millions of customers, but the, the small Cs, how many developers did your team support? So you give folks so uh T-Mobile, T-Mobile had any given time between 8 and 10,000 developers
06:18
and a lot of that was a lot of that. was contract, so it was a very interesting was It it was contract for short term based projects, but we use the same, we used the same organization over and over again, right? So they were almost, they almost acted like employees, right? Because it wasn't like they were here for 6
06:37
months, delivered something and it went away. They actually, um, Uh, a lot of, a lot of times they, they recycled through and actually we leaned a lot of those folks to help us define what the platform was. But, but one of the thing, one of the benefits of the platform was is that I think we talked about this a little later, is that onboarding becomes a lot simpler,
06:53
right? is once you have a defined platform and when people know how to operate within the construct of your platform. Onboarding and shifting teams and kind of all the things associated with that become much easier. Awesome. And how many uh folks on your team roughly supported that 8, 10,000 started with 3 and then we,
07:10
when I by the time I left, uh, it was, you know, we, we, we reorged a little bit, we adopted a new platform for Curban Eddies. It was probably 15 to 20 people in total, yeah, and, and a wide range of roles, right, because It wasn't just now engineers, we had product managers, uh, program, program managers for just, you know, uh,
07:30
things like upgrades become, you know, a huge thing and you have to, you really have to communicate with your You're, uh, it's almost like you're running in, when you run a private cloud like that, it's almost the same kind of communication you get from Amazon in terms of product updates and, and upgrades and what you need to be aware of and when they're, when they're going to do activity, when they're not.
07:49
We, we had, we had to fill that same sort of role for our internal customers. Wow. Life cycle is a true product that, that brings us to the next topic. Uh, could you talk, for those of the audiences here who want to learn about how to build a practice or a platform internally, what's a typical journey like? Excellent.
08:08
So I'm gonna stand So, this is, this is where we, and this is how I've approached things, new technology in, in my career, right? I've always, I've always been very keen to automate things, but I've always wanted to really understand what I'm automating before I automate it. So when we, when we looked at the platform engine, when we looked at our platform engine,
08:28
when we built our first cloud founder foundation, we did it pretty much manually clicking buttons, putting in values, clicking buttons, putting the values, right? But we knew that that was just to learn and that eventually we would automate that. So your first step really is like, understand what you're doing,
08:43
right? And this is in the context of the Kubernetes of a Kubernetes environment, right, is like, You know, install your clusters manually, really understand what you're doing, right? Do some, do some ad hoc ad hoc scripting, right, to, to do things faster, but don't try and do the complete integration, right?
09:00
Try and build some stuff in. And then you get to foundational automation, right, which is now you're really starting to OK, what, what is, what's the low hanging fruit? What can we automate? How can, how do we, how do we get to where we can deploy a unit or something, and uneployed unit or something in an automated fashion, right?
09:16
And this is where really start embracing things like infrastructures code, right? Really lean in and this is a challenge for most infrastructure teams, right? Because they're not developers. So when you say, I want you to use the CICD pipeline, they don't understand the context of what it is. So, What we did actually is we went actually
09:33
found some developers in within the company who are interested in becoming part of the platform team, interested in the platform, and they were there, they were waiting for, they were waiting for us to invite them, invite them. They came on the team and then we got this, we had this nice balance of folks who understood sort of development life cycle and then folks who really understood the infrastructure life
09:52
cycle. And, uh, you know, just build your, build a basic set of CDCI uh pipelines, standardize your monitoring and alerting, right? And now you have kind of the, the foundation to start extending and start doing some really cool things. Then 3 gets into the operational efficiency. And so it's a part of my job at Pure is I'm a
10:13
field, actor, a field CTO. I go, I go and talk with a lot of customers. One of the things we're finding right now with especially with Kubernetti's deployments, that the hardest part of that job is maintaining the life cycle. Everyone is 345 versions behind. Kubernetti's, Kubernetti's releases so often, they just can't get the change windows,
10:32
they can't get the, they can't get the organizational buy-in. They have one upgrade go bad, that shit that that shades, that shades the customer's view of that platform, that they have to be super cautious. So there's, there's, this is something you really need to practice and build a practice and build a practice around is how do you upgrade?
10:50
How do you make sure your customers are ready to absorb what you're, what you're doing. And part of it too is like you, your, your resources are probably gonna be slim, especially your, your most talented resources. So you want to basically have them build something. That they can hand off and create run books for
11:10
to, to more junior staff to run and run through those things. And then finally, full livestock automation and this is, this is kind of 4 is kind of in Nirvada. Nobody, nobody ever really gets there, right? You, you kinda, you kinda hope you land somewhere around 3, 3.2, right? And then if you can do that,
11:25
you're actually doing pretty good, right? You're not, we're all not Amazon, we're not hyper scalers. We don't have, you know, we don't have the, the talent and the, the resources to do that, but, but you can get to a pretty good place. So with that, uh, what are some of the best practices in building what you call James,
11:43
like a golden path to platform engineering. So, so we, we had a very interesting experience. We, uh, When we first launched Cloud Foundry, I, I had some real doubts about it being successful, and my doubts were that it was way too opinionated. And what we found out is that actually became a feature, right?
12:03
You need to have opinions. You're, especially in larger organizations where you have a myriad of development teams. Everyone does things a little bit differently and that creates a lot, that creates a lot of, a lot of snowflake environments, a lot of snowflake practices. It doesn't really lend itself to, uh, when, when you're on an outage bridge or an incident
12:20
bridge, people being, you know, uh, folks who are working on that incident trying to understand what's going on, right? They really need to understand each environment separately. What we found is that when our developers moved on the cloud foundry because it was pretty prescriptive, it, it kind of, it kind of forced, forced and funneled them into a standard pattern.
12:38
We saw lots of outliers, but more or less, most of our applications were, were built and deployed the same way. And what we found was, is that really, that really not just increased productivity, really increased our ability to support incident times were lower, right? Just we got all sorts of benefits out of that.
12:55
And then, then Kubernes came along and we lost a lot of that because it became, all of a sudden Kubernetes became, you had a lot more optionality in terms of what you could do with the platform, even though we crafted it to kind of look like the cloud founded platform we're running, it still had way too many, too many options. So what we found, what we need to do is After a couple of years,
13:15
our, again, our development partners and the, the SLT that was investing in the platform said, we will support you being more, more prescriptive, right? We want you to, we want you to put boundaries around us so that we don't do the wrong thing. And some of the areas we focused were things like the language frameworks, right? We ran a lot of Java Spring boots, so instead
13:35
of everyone having a bespoke way to deploy Java, we gave them what we call a starter pack, and we actually got a patent for it where when you start a project for, for Crier Denis that's running Springboot, you click a button, it would go into Gitlab and scaffold out all, all your code for you, right? So that you started it from a good place,
13:52
uh, ingress and egress. This is something we work very closely with our security team on, right? We, everyone wanted their custom chrome-plated names, their own, their own certs, right? And we were able to kind of use security to, to really focus them on like, hey, no one cares internally what your name is,
14:08
right? You just, we want you to use a standard cert. We want to be able to, we want to, we want to manage the centrally, the certificate and all, and all the rotations and everything that go along with that. So we just provided that to our customers. Uh, application configuration, uh, right, uh, standard, you know,
14:26
every team is trying to solve their own problems their own way. What we found is if you were on the platform, right, we could provide a standard, you know, part of the, part of the benefit of the platform is you provide a horizontal set of services. We could provide something like Dynatrace or, or some other, you know, some other products along those lines so we could give a much more
14:43
common observability view, right, from team to team within the platform itself. Uh, security was a huge one. One of the, one of our early customers on Cloud Foundry, um, they were, they were running TIPCO, a lot of TIPCO, and what they found was that they had a separate, a separate set of staff that was that was responsible for managing just the patching
15:06
for those TIPPO servers. And the way the TIPO servers worked, it was so critical to the business that they would essentially always be patching one night a week, one or two nights a week, pretty much year round. When they moved to the platform, they didn't have to do that anymore, right?
15:20
The, the patching they were doing had nothing to do with their code, nothing to do with their application, right? It was just burden that was put on them because they're running on VMs. When they came to the platform, we absorbed all that burden for them and they, and that's what the, the, uh, director of that organization has given er given several talks
15:38
on it, says. For even if there's no other benefits to the platform all, that single benefit made up for it. And then finally optimization. This is kind of a late game thing, right? It's where uh you, you need to be careful, containers are weird, so you need to understand how they behave once,
15:54
you know, if servers become too loaded. But once, once you, uh, once you kind of get your pattern down and understand what your work, what your workloads look like, you can really start bin packing containers into your systems. And again, that same TIPCO team, we went from, I think, 180 basically silos at 3 silos at 60.
16:15
Uh, servers to, uh, less than 30 in our cloud bounded platform in two locations, one for business continuity. So, so there's the, the takeaway here is that It's, it's interesting. Golden Path is kind of a debated term in the platform engineering space, but even if you don't, even if you're not trying to,
16:35
to create the whole package, the idea is what you want to do is you want to create a framework that works for your customers, that makes their lives easier and that makes your life easier. That's kind of the whole point of the platform. Absolutely. Take notes, folks, this is a lot of, lot of learnings, but James, you also have some lessons that you learned along the way,
16:53
both from a You know, day 0 standpoint and and day 2. Do you want to walk us through that? Because I know what the next slide is. I think I'm talking way too fast here. Uh, yeah, so the It was, we had, we had a lot of, we had a pretty cool chance to start over, right? Cause we started with Foundry,
17:13
we learned a lot. And then we built our Kuberna environment from scratch and We took a lot and we still made some decisions wrong, but we at least had a much more informed idea of what we should do. So when we went from cloud Foundry to Carinnetis, the, the first thing is to plan, plan what your platform looks like.
17:31
And I think the, the The real takeaway here is, is that plan for growth and plan for operations. Um, it's been interesting because we, again, in my, in my new role, um, talking with customers, I'm finding that there's a lot of customers that are still out there and where the architecture team is separated from the operations team and the architecture team will build something and just throw it over the
17:57
fence to the, throw it over the fence to the operations team. And I think that, I think those days need to, I don't, I don't want to say need to end, but There needs to be a lot more collaboration because um what ends up happening is that You, you architect something that you don't have a real clear understanding of what it's gonna take to operationally maintain, and the world's changed a little bit in that regard because I
18:19
think we all knew how to do VMs, right? It's just like you just patch VMs at scale, schedule individual downtimes, but when you start to get to these platforms that are multi-tenant, you have a lot more constraints on you, that you don't really, unless you have the experience, you don't really think about up front. So, Uh, a lot of it is just a plan for growth,
18:38
right? You don't want to be, you don't wanna be too successful and then be painted painted into a corner. Uh, think about, think about cluster scale and trade-offs, and what I mean by that is, is think about, um, when we first started thinking about Kubernetes, like we had these dreams of running like Google, right, where we'd have like 1 10,000,
18:55
10,000 node cluster that was bare metal. But then as we really got into it we realized, no, we really need to have much smaller, much smaller fault domains, much smaller blast radius. Our customers are different, so we need to, we'll have clusters that are kind of purpose-built for databases, clusters that are purpose-built for stateless workloads.
19:12
And, and so on. So, so just think about what your customers are gonna do and then help that guide your cluster scale and think about the trade-offs between managing a lot of clusters and managing a big cluster. Uh, think about your tenancy model. Are you providing, and again, this is fairly Kuber Das focused,
19:29
are you providing clusters as a service or namespace as a service? And what we found is like in 95% of the organizations, it's namespace as a service, right? So you, you have multi-tenancy within your clusters. Multi-ten and, and I, I've, I've talked with people, talked to some friends about this, and who, who have truly multi-tenant clusters,
19:49
which is where they have different external customers on the same clusters. That's a different kind of multi-tenancy than multi-tenancy within your company. And then think about how you can futureproof your, your, uh, deployment. And then the next thing was, and we didn't do this enough,
20:04
is we were always under time pressure to deploy and then hand off as soon as we deployed to our teams. But the day one, the day one takeaway is like test what you're doing, like tear down your cluster, rebuild your cluster, tear it down, rebuild it, migrate, migrate applications, cluster to cluster to understand what that looks like before you start taking live traffic.
20:21
Right? This is the opportunity to really, really, uh, you know, kick the tires on what you're doing. And then finally, uh, run, right? This is, this is where um You need to, uh, again, really work with your customers and your, and your, the, the folks that manage your environment on how do we,
20:43
how do we keep up to date? How do we keep upgraded? How do we, how do we actually make it so that we can do our work any time without informing customers because if you, if you always wait for a response to an inform. You just never get things done. So how do you, how do you work with your sta, how do you work with your customers and stakeholders to build
20:59
their applications in such a way that you can do what you need to do to maintain a healthy platform, but their applications remain stable. And PDBs was a big one for us, right? It's like, cause we, we actually, uh, one of our first big outages happened when I was at a conference and we, we upgraded a cluster and the repay actually went through through the cluster so
21:18
fast that the applicant that it, it took down all the healthy instances of the application. And their start time was so slow that the cluster repaid before those applications could come back up, right? And we said, we found it was some HP settings, right, very interesting, but, uh, basically, you need to practice how you're running. And then finally, make sure you have Raines a lot of these probes,
21:37
right, that unders so there's business log some hopefully some business logic in your application before it says it's ready to come up and, and really look for CPU thrott and Kuberne deployments. That's actually something we found that that uh CPU throttling just kills, kills your workloads, even if it doesn't look that bad,
21:55
it actually has a huge negative impact on your system. And that happens a lot. It happens a lot because everyone puts quotas, everyone puts quotas on there. Basically, you put, you put limits on your, on your deployments, limits on your, on your, your container deployments and as you approach that limit,
22:14
you throttle and it causes a lot of problems. Wow. Well, anytime I talk to James, and we've done this talk a few times, I always learn something new. Hopefully you guys uh got some good takeaways here. Uh, James, I can bring us home and talk about uh footworks,
22:29
but before I do that, do folks have any questions for James? All right, keep thinking and I can take the opportunity to talk about Portworks. And obviously, James, thanks for uh the overview here. Uh, how many of you are familiar with Portworks? You've been show fans? OK, I'm getting less than half, so that makes this worthwhile.
22:53
Well, um, so Portworks was acquired by Pure, um, almost 5 years ago now, and uh they started as a cloud native storage offering and they've evolved the platform. Uh, including helping early customers like T-Mobile, who, uh, all of those, uh, small cs, uh, their 80 to 10,000 customers use Portworks, uh, to get access to storage, and, and James's team actually,
23:18
you know, uh, leverage Portworks to deliver all those SLAs that he just talked about, right? But our customers, uh, typically use us for automating cloud native storage for building container-wise apps that are mission critical in production and, and at massive scale. Uh, the beauty of the portworks architecture is also that,
23:38
uh, we don't care about, well, we're a pure storage company, we don't care about what your underlying storage is. So you could use a heterogeneous on-prem or in the cloud storage to build your containerized apps, and portworks would just work as a unified layer across the board, delivering all the automation capabilities, all the data protection capabilities and the backup
24:00
SLAs and You know, your compliance SLAs that you would need, uh, many customers like to keep 3 copies of the data, often like 2 of them in a separate location and in a different cloud region or a different disaster recovery, uh, policy for making sure your banking applications or healthcare applications that are containerized are not missing that heartbeat that just James just talked about,
24:21
right? When they're live, uh, serving millions of customers or billions of transactions, you want that. You know, uh, disaster recovery, uh, and making sure that, hey, AWS has an outage or if your node went down, uh, that your applications are still functioning the way they should,
24:38
right? And without any user disruption, right? Uh, and that's what Boworks really delivers. Uh, on top of all of that, uh, we also work with any Kuber and provider, right? So we're also agnostic from an architecture standpoint. Whether you use OpenShift or Souza Rancher or
24:55
any of the cloud Kubernetes the stores, or even some vanilla Kubernetis, um, right, which is open source and free. So we support all of those customers and you don't have to buy a different flavor. It's the same software that works across the board. Uh, very recently, we've had a lot of interest from customers who are looking for uh cubeboard
25:13
and bringing cubeboard into production. And we've been talking about that in the show today. You heard SiriusXM, uh, talk about it. Uh, that's another, uh, evolving use case of Portworks. Uh, this slide kind of talks about our joint wins with Pure and because we're at Accelerate,
25:28
I wanted to show you guys the, the joint wins, we have a lot of customers who are non-PR customers too, uh, but these are some of the massive logos that, uh, have invested in us, and, uh, this is not the full list, but as you can see, we're, we're prominent across all industries, right? So containers are Operating at scale in all
25:47
enterprises now, it's the way to build modern applications, including AI applications, which we'll talk about a little bit as well. Um, so what are some of the business outcomes, uh, that we've driven? I mean, James talked about his, uh, talked about his T-Mobile experience with us before he joined Pure, um, but you know, mostly it's about that little see,
26:07
the developers, right? It's all about making sure their experience in building applications in. You know, maintaining life cycle or, you know, bringing the next, next new innovation or solving the next new business problem quickly, how can storage get out of the way in, in that acceleration of app modernization is something
26:26
Portworks has always help with. So you can do a lot of our workflows, which typically take uh days uh within just minutes after you've deployed Portworks. So I, I'll actually. Uh, try to, instead of making this seem like a marketing slide out, ask James, like, how long did it take your T-Mobile developers back in the day?
26:46
Not long, provision or cluster, yeah, and the, the, the, we're a confoundry, we actually, we actually had a customer who's running batch jobs and one night we scheduled a repay during their batch jobs and they would, they kept asking us, where's, where's our data? Well, that's you're running ephemeral stateless stateless workers,
27:03
so your data is gone, um. So they were one of our first, they were one of the first customers we put on the, on the, the data layer, but that was one of the goals of, of, of using of building the Kuberne platform, right? It Kuberate is you want it, it's almost like a data center,
27:16
like it's almost like a data center, right? The, the, you get, you get compute, network storage functioning out functional out of it and storage was a critical piece for us. And we messed around with a couple of different options uh to, to provide that level of, provide that to our customers and we, we landed on Port work pretty quickly.
27:34
Uh, it, it actually gave us the best, it, it gave our, it gave our, our It would let us expose. Uh, software or, or sorry, storage to our customers without them having to worry about it. They could actually just build something they didn't have to worry about whether or not it was on a, on a, you know, their data was durable, stable.
27:54
We gave them, we gave them options to, uh, to back up, right? We, we, we created it, we created a service offering off of it. So that's really, again, part of the key for platform engineering, right? I think about the full life cycle of what your customer require, require and try and meet all those individual needs and port works really
28:11
help us meet that need. Thank you, James. And one of the other, uh, examples of why Bodworks is so valuable is it's really bringing that cloud operating model for storage on-prem, right? Because to James's point, developer Team A would need a t-shirt size of like highly dense storage, but not necessarily developer team B, right?
28:31
And you could actually optimize and make those tweaks available in different t-shirt sizes. We would allow customers to do that. And the, the autopilot capability actually also increases those t-shirt sizes so you can also implement that sophisticated programming because your apps are going to grow, your data needs are gonna grow, and what you don't want is you don't want to do
28:50
overprovisioning, but you also don't want the apps to be hungry for more storage and autopilot, let me touch on that. The other, the other part was facing down, um. And, and this is, this is not just for storage again, sales pitch for the storage, but you want, you want, you want your products to be uh support your automation story and Port
29:10
Works did that. And it, it really Um, it lets storage almost be in no op, right? We had a, we had a resource and a half who reports experts out of the, out of a, you know, team of 8 to 10, and that really helped us, uh, that really helped us do what we want to do as a platform team, which was focus on offering a platform that, that had a lot of different,
29:32
a lot of different options with a small team. Fantastic. So, we've also, in addition to the autopilot capabilities and the serving millions of developers. Uh, we can also implement XORPO, right? So, a lot of the top banks use us for that, uh, healthcare companies, uh, even service providers, uh,
29:52
such as T-Mobile. Uh, you also heard from Sears XM today. We have many more customers. I'll say a large automobile provider has us in production for keyboard. Uh, 30% is a very, uh, small number. It's at our low end of the savings we can bring, uh, if you're looking for re-platforming your VMs into containers.
30:12
Um, you know, our customers are actually able to realize more than 50% savings, and that's not just with by moving to Portworks, this is a combination of the total cost combined with the OpenShift license purchase to on top of Portworks. So your, your, your comparison point is the VMware license renewal to what uh the Portworks and OpenShift solution together would cost in the saving metric.
30:37
Uh, and then, you know, with data protection, it's just so easy to do backup and Uh, we, we typically, in fact, don't even need customers to choose Port Wors Enterprise. If you're only using us for the data protection workflow like some of our customers are, eventually they start with backup and then they use the automation of Portworks and do DR, uh, but there are some customers who, you know, just use us simply to back up all theiruber
30:59
these clusters in Amazon or, or Azure, let's say with just a few clicks, um, in, in the backup UI. So with that, uh, I'll kind of try to round this up with James a bit uh on what our top use cases are and folks. This is a good time to actually interact and ask questions because you may be considering
31:19
sort of your organization may be going down a specific use case and leveraging the platform and engineering best practices here um to, to sort of take that uh to the next level of maturity. So we have modern virtualization, we have AI and we talked about, you know, developer self-service, uh, all these applications leverage containers.
31:41
And the value of board works can be seen across the board. We can talk about our examples here. We're seeing some modern virtualization, it's gonna be interesting because, um, you know, there's a lot, there's, there's a lot of decisions companies are making right now whether or not to stay with Broadcom and VMware, move away.
31:57
The companies that are choosing to move away, they have a unique opportunity to kind of reset how they think about deploying VMware at scale. Or, or a, a virtualization environment at scale and it can be daunting. Um, it's, it's, uh, there's a lot of complexity, a lot, you know, you, you, you're gonna have to go in and rethink about how you do some things,
32:16
but there's gonna be, we, I feel like we've got this, this, this enormous opportunity in front of us to actually pull what were a lot of legacy platforms into modern platform engineering practices, which is, think about your automation day one, think about how you're gonna deploy things day one. Don't don't make the, you know, most VMware practices evolved over 10 to 15 years and,
32:37
and there were compromises made on the way. Don't make, you know, don't make, try not to make the, and I realize business is business, but try not to make the compromises up front, right, and, and hold to where you can really, uh, uh. Leverage The work that a lot of teams have done to build these new modern platforms and bring
32:55
that, bring that, that capability to your older, your older environment. So it's uh it's gonna be, it's gonna be, it's it's already interesting to see, uh, you know, to see the different practices that are popping up, that are popping up around in industry around the, you know, that are, that are supporting these new use cases.
33:13
Absolutely. Are any of you considering modern virtualization or cue word in your organization? You wanna talk about some of the hurdles perhaps? Uh, The one I've seen kind of so far is uh even with work works, uh, right now we're gonna do where you shop, so I get a lot of visualization into what the VMs
33:33
are doing but you have works on Oshift through the other uh convert based systems. It turns out to Fort Worth just, it's. You know a couple of lines on the ear. Yeah. combined it to that, so we really to layer up to works. I figure out a way to to.
33:54
Makes the. Yeah, that's it because you're, cause the, the, the, it's actually one of the, uh, one of the ways I've describedworks is that when you think about VMFS at the, at the right at the VMware layer, right, where you have data stores and then you then you carve virtual vis out those data stores, it's like, what was,
34:13
what was the purpose, what's the purpose of that abstraction, right? It's to make, make it so you don't have, can you imagine. Uh, could you imagine a world where you had hundreds of VMs, thousands of VMs, and everything mapped back to individual ones on the arrays, right? That's a pretty chaotic world.
34:28
So, there's this facade layer that makes it easy, easier to interact. And Valves was another Valves was an extraction layer to make that in to make that same thing. So, conceptually, it's the same, right? It's that you're, you're uh You're creating a storage layer and then you're carving virtual volumes out of that and you're letting the software kind of help manage all the,
34:47
you know, all the data management happens at that layer instead of trying to orchestrate between your VMs and back in stor, you know, heterpeneous or even a homogeneous uh storage environment behind the scenes. So it's uh, it's been interesting. So we've, we've, again, talked with a lot of customers, seen a lot of testing that's happening and, and just the, the complexity, the, the com if you,
35:09
if you're just using like the native CSI drivers from your arrays, right, it tests work at small scale, but then once you ramp up to like, you know, you know, VMware clusters of 2030, 40, 50 nodes, you, you really start to see the complexity come in and that's where something like portwork can really help abstract out that complexity and make it more manageable.
35:28
But you're Uh, we're the issue of time because, uh, REA expires in 5 at the year. So, uh, we are aggressively working on as much not. We got great success with that, but it just became a timing issue of the complexities looking chips or to where we just needed a way to go to another hypervisor and we're not that
36:01
our hypervisor solution not going to go onto a solution, but it's a solution we need right now. It's easy but I assume we're looking, we're starting to look at virtualization. More holistically rather than rushing into like virtualization because what we're expecting is once our conditional hypervisor. Situation now within the next 3 years to move in to be
36:29
more in a situation when we're ready. And that way we're not making compromises as far as the migration that would impact us. So it's a combination of of our platform and DevOps teams moving those workloads organically into the the stack getting more more um persistent workloads into into into that but then also then we're just kicking the can down for a little bit it's so
36:55
we circle again. If I had another 24 months, I would definitely do things differently, but I don't, so that's I know, I know everybody has business these cases what. Yeah, that's a, that's a common, like a lot, a lot of, a lot of folks are reupping for 3 to 5 years, 3 years, right? And, and, and then, and, and there,
37:16
and it's, it's a bitter pill, but then they're, they're the, the key there is you have to then almost start immediately, right, with, you can't 3 years, well, that just goes by in a in a blink, right? So yeah, you really need to start uh uh preparing for your, your next generation and And the,
37:33
I mean, I'm just be frank, the, the, the vert ecosystem is not 100% there yet, right? You have a very rich ecosystem for VMware that, that is, it's emerging for ubert, but it's, it's, um, it's not there yet. And so, so, you know, buying yourself a little more time is gonna resources that
37:54
aren't deployed if we have those resources to just focus. but we see this as part of the, yeah, and that that question comes up like I can't I just have my team run it's like you're. That what how your Kubernetti's team manages their manages their customers and how your VMware team manages their customers really two different experiences.
38:21
And that's something I've, I've, I've actually gotten some heat for this comment because like I would not mix those environments. I would keep them separate for now right tell because what the, what it takes to run a cloud native set of workloads and what it takes to VM set up a VM set of workloads, that's really, it's really a different practice and if you try and overlap them to save a little money.
38:41
You know, by, by again by packing things together, you're gonna, you're gonna run the problems when it comes to upgrade time, right? Your, your VMs, you should, your VM environment, you should be able to upgrade, you know, almost like you do today, which is evacuate a node, drain a node, do what you need to do it,
38:54
bring it back in, go to the next one. When you do that in a in a in a container environment, you're you're cycling apps, right, that you might see blips yeah, it's it. It's very easy to have a platform engineering, uh, stance on paper, but one thing that was a positive slash negative for us was We're rancher managed
39:19
cubernes and you don't find out what platform engineering means so you have to move from our on our because you have all the tabs. Then your development teams got to redevelop to make sure that they get RKUT. Then you have all the connectivity all the bills and aress and ress, all those things that are in the developer slash infrastructure a lot of the you to think
39:40
about and tell. You can't upgrade a place. There's no upgraded place, so that I see it as a positive because we're learning all those lessons. Under fire we're learning those lessons which makes us more integrated in becoming a true platform engineering, uh, organization because we have to,
40:03
right? Our CICD teams all the way through the debt, all the way from depth all the way to infrastructure have to understand how its applications interact because we can't just move an app that's using native East West that doesn't have the ability to shell out to your agree that that that is, that's the. We ran, we ran the same problem,
40:24
right? Is, is we went from one version, we went from PKS to a different version of Kubernes, right? And we, we We couldn't just, we couldn't just ask teams to redeploy. They had to do more. They had to do more, more work than that. So yeah, prospect there's a huge CICD yeah CI really does.
40:43
Yeah, and I think that can be really opened my eyes as to what we can do, yeah, and, and as a platform team, the lessons learned there should be is how can we build more abstractions so that it becomes a more seamless, like I, I've, we. Uh, but when I was a customer, vendors asked me what, what's your kind of golden idea for
41:02
Kubernetti's. It's actually Kind of like VMware, when I can, when I can take a namespace and drag it from one cluster to another cluster, you know, and and use that to evacuate a cluster to to rebuild it, patch it, whatever, and then move back, that's kind of the nirvana and It's, I think things are going that way. It's just not there yet,
41:19
but so you have to build in some abstractions. You have to help, help your customers by building some abstractions that make it easy, right? Can, can help with the migration? Uh, it's, it's funny. We actually just had a, a talk with a customer who's going through that experience.
41:34
They're using Portworks tools where essentially they're using PX backup and PX migrate to move work to move workloads from cluster to cluster. It, it, it really, a lot of it just depends on how you're deploying and how you, you know, it, that it's really, the PIX migrate is really good to move the data. It's actually really good to move everything because it moves all the objects.
41:55
Um, over if you want, but in a lot of cases, if you have a more mature practice, you just put your CICD, you know, platform in a new cluster deploy, and then you're good. But the hard part is what's talking, what's the, what's the boundary above and what's the, you know, what are your boundary systems above and below and how are they gonna react to that
42:11
name change and to that IP change and that's the tricky thing. He is the because Then you have to create the ability to transverse those clusters that you the specific uh migrations. Mhm yeah, yeah, we look, we looked at actually and mess around a little bit we like build, we were gonna build a set of ingress clusters, a set of egress clusters,
42:37
and then workload clusters in the middle. So these would never change and then your, your real workloads, you could move them in theory laterally or anywhere, anywhere within that workload layer, but it's a lot of work to, to do that, so. Um, thank you. Great, yeah, good feedback.
42:53
Thank you.
