Fueling resilience: Phillips 66’s journey with VMware Cloud on AWS

So one of the, my favorite parts of my job is throughout the year, I get to hear customer stories. I get to hear about the success they've had with VMR Cloud and AWS. And one of them that came across uh ear earlier this year was uh hearing the story about Phillip 66 and, and Rick's team and what they were able to accomplish. And when, when I read this thing, I was like, wow, this is incredible. I this is the kind of story we need to be able to share with others. I, I feel like this would resonate really real well uh with, with other folks and, and Rick was kind enough to, to be willing to join us uh here at Re:Invent, share the story uh of, of what they accomplished and what his team accomplished. And I, I think you will find it fascinating and I hope you will find uh some of the lessons learned and some of the the real details of, of a real customer experience um fascinating and helpful for you on your journey as you look at moving into the cloud.

Uh hi, everybody. My name is Andy Reidy, I lead the product team at AWS, which is dedicated to the VMware partnership. So I work on services like VMR Cloud on AWS from within the EC2 engineering organization. Uh I'm joined by Rick Snell. Uh Rick is the CTO of Phillips 66. Uh and we're gonna share with you a little bit about their journey about some of the, the challenges that they over overcame and, and how they used VMWare Cloud and AWS to accelerate uh some objectives that they had within their organization.

So I'll lead off and just give you a little bit of a background on VMware Cloud and AWS just level set, make sure we all understand kind of the, the core technology bits because Rick is gonna dive a little bit deeper into some of the specific components uh that, that they uh went through. I wanna make sure you have a, just a basic understanding and, and really uh can, can follow along as he goes through their, their bit.

Um we will be around after the session. Uh you know, we, we have a pretty decent amount of content, but as, as soon as we finish, we're happy to stand around here in the front and answer any questions that you may have. So please, if there's something specific that we didn't cover, we didn't dive into uh that you'd like to know about. Uh we will stay in this room until they give us the boot and kick us out. So feel free to, to grab us afterwards if there's something that you wanna wanna chat about.

So again, just to kind of level set start off, what is VMware Cloud and AWS? So VMware Cloud and AWS is a managed cloud service that allows you to run the VMware stack directly on AWS bare metal infrastructure. So about seven years ago, AWS started working on uh the Nitro platform, if you've had any other sessions or got a chance to learn about Nitro. Uh it's a really incredible platform. It allows us to take a lot of the virtualization components that traditionally we're in software, bring those into the physical hardware. We we build physical cards that are running in these servers that allow us to essentially remove the hypervisor bits completely from the software piece and allow uh allow software to run directly on the bare metal.

So like for example, a VMware hypervisor can now run directly on AWS bare metal instances. So we, we launched this technology and VMR was one of the, the very first customers to take advantage of it. And we, we built the VMR Cloud and AWS service with it.

So, VMware Cloud and AWS allows you to run the VMware hypervisor, the VMware software defined data center stack directly on AWS bare metal. It is a fully managed service. So this is a key piece that a lot of folks uh I it takes just a minute to like really wrap your head around the value proposition of this. Uh but with, with uh it being a fully managed service VMware takes care of all the patching, updating and upgrading.

So traditionally, in an on prem environment, there are teams that are focused on actually having to manage uh the, the esxi versions, NSX versions, vSAN actually do the patching and upgrading. And especially if you have a large environment. Uh ii I talked to customers and they say, yeah, we have a team of folks, this is all they do all day long is patch VMware environments and our environment is so large that by the time they're finished, they essentially start over and are having to patch again.

Uh with this being a cloud service that VMware manages VMware is responsible directly for patching, updating and upgrading the environments. Uh and since it is running in uh in an elastic environment, they can do some really cool things. So for example, rather than uh having to take a host and put it in maintenance mode and, and pull it out of production and then update it and put it back in, you can simply just add a new host into the environment that's running the new version and then pull the old host out of the environment.

So you, you, you take something that's like a, a traditional VMware environment and you now marry that with the cloud and you take advantage of the elasticity uh and the the capabilities within the cloud.

I briefly mentioned some of the components but there's ESXi, there's vSAN, there's NSX- VMware bundles these together and refers to them as a Software Defined Data Center. Uh you may also hear kind of the VMware Cloud Foundation bits be referenced, but these are the components that are, that are running within VMware Cloud and AWS to and it's all running on the AWS global bare metal or on the AWS infrastructure and it runs on bare metal instances.

It is important to note VMware is not running a nested virtualization. This is not vert on top of vert. This is the ESX hypervisor running directly on AWS bare metal.

Um one of the key advantages of this uh that, that we see is this is the same software that uh your engineers, your administrators, uh perhaps you are, are familiar with running in your on prem environment. So it's not like you have to learn something new or, or suddenly you're, you're taking somebody who's worked for 15 or 20 years in VMware and they're now just kind of thrust into the cloud space and they have to figure out how to, to do the same things they've always done in a new platform.

Uh you log into vCenter and you manipulate vCenter, just as you went on, prem, if you can create a virtual machine on prem uh within vCenter, you can do the same thing in VM or Cloud AWS. So familiar tooling. Also a lot of the scripts that are available or that you've used on prems. If you've built out your own automation or your own tooling or use third party off the shelf products. If they talk to the vCenter API endpoint, they will, they will function here as well. So it allows you to basically be able to move from your on prem environment into the cloud without having to deal with a complete repla exercise. You're essentially reho the the environments that you are running and you're being able to do that within the cloud without having to completely relearn everything and start over.

Um the, the interesting thing too with the Software Defined Data Center running within the AWS environment. It is also connected directly into VPC into your VPC. So one interesting piece to note is this is not, if you were to look in your AWS account, you would not see a bunch of ESXi hosts running as EC2 instances within your AWS account within your VPC.

When you go to deploy VMware Cloud and AWS, you log into a VMware cloud console, uh you are able to, to provide all the input parameters that you need to deploy an environment VMware deploys this within an account that they own and operate. So this is running in an AWS account that VMware owns and operates. You don't directly get into the AWS account. You can't see it, you have no access to it. So VMware is operating this as a service on your behalf. So it's, it's all within an account that they have, but they connect the Software Defined Data Center into your AWS account into your VPC.

So one of the input parameters that you provide whenever you're provisioning the service, as you say, here's my AWS account that I want you to connect this SDDC to. And you'll notice kind of the NSX connected to the Elastic Network Interface that is that connection point. What this allows you to do is actually have virtual machines that are running within the VMware environment and they're able to talk to uh to uh resources that are sitting within your AWS account.

So imagine if you had two instances or you had private link endpoints or any of those types of things sitting within your AWS account, those VMware virtual machines running inside a VMware Cloud and AWS would be able to communicate with those privately without having to go back out over the over the internet. So this allows you to treat these VMware VMs just as you would uh other resources and access private resources like S3 buckets or, or, or EC2 instances that are running within your VPC.

And another piece of this is, you know, on the left hand side there, you'll notice uh vCenter in your on prem data center environments. One of the cool things that VMware has built out of this is the Hybrid Cloud Extension or I'm sorry, the uh Hybrid Linked Mode. This allows you to connect your on prem vCenter environments and your AWS VMware Cloud and AWS environments together so that you can manage both of those within a single pane of glass.

So you know, if you're looking at vCenter, you kind of see your tree of resources, you're able to see VMware Cloud and AWS just as another data center just as you would if you had multiple data centers on prem today, uh allows a lot of just seamless management. You're not toggling between, you know, your VMware Cloud and AWS vCenter and your on prem vCenter. You can't connect those things together and manage it all within a single pane of glass.

Uh which really makes it super easy to, to be able to manage these environments. Another kind of cool technology that VMware built as a part of this is their Hybrid Cloud Extension or HCX. You'll hear hear Rick mention this quite honestly, this is, this is some of the magic uh really with accelerating migrations to the cloud HCX allows you to do some cool things like actually extend the layer two networks from your on prem environment into the cloud environment.

And what we've actually learned is, is this is one of the hardest parts of the cloud migration is having to re IP your your VMs, especially if you have a lot of, of older legacy workloads or, or workloads that are commercial off the shelf that you don't own. You would, you would think in this day and age you don't have to worry about IP addresses. Everything is DNS. Well, it turns out there's a lot of things tied to IP addresses. There's firewall rules, there's, there's systems where uh e especially in large complex environments, they're just things that care about IP addresses. I know we would all like to think it doesn't matter but it kind of does.

And, and so with HCX being able to actually take these workloads and move them from point A to point B without having to re IP them uh is super powerful and it allows you to accelerate and, and migrate really, really quick. And that really, really quick part is kind of the, the main reason that we see customers using VMR Cloud and AWS.

So I get this question a lot like why would I want to use VMR Cloud and AWS rather than just going and refactoring and building directly into, into AWS itself? Like why would I add this, this component in there. And the answer is speed if you have a compelling event, if you have some reason to move quickly, that is the number one reason that I hear customers come to us and want to talk about VMR Cloud and AWS.

I have, I have a data center evacuation. I have a contract that's expiring. I have a server refresh where my, my servers are going to be out of support and I have to replace them. So I have a choice to make, I either have to spend a lot of capital and buy new servers or I have to renew this data center contract for another three years. And that's not necessarily an investment that I want to make right now.

There are even other compelling events. We, we talked a year ago about the situation in Ukraine where there were financial institutions in Ukraine that were really worried uh about their physical environment and the, the the safety of that physical environment being able to protect that data. Uh and we had customers uh in, in that situation, actually evacuate entire data centers in a weekend, the entire thing.

And if you talk to a lot of customers and the concept of moving an entire data center in a weekend is terrifying. This is something that normally takes months for folks to do and they were able to do this in an entire weekend.

So the the main reason that I, that I hear people wanting to use VMR Cloud AWS is speed if I can lift and shift, if I can get out of that physical data center environment, get into the cloud that buys me a lot of time to figure out how do I want to leverage the rest of the native AWS services? Do I want to extend those applications and, and have them consume uh those native AWS services in a, in a, you know, bespoke basis on a one by one basis? Am I going to rebuild some of those applications completely and move them into native or am I going to move those applications into AWS as a solution?

You know, those things take time to analyze and figure out what your strategy is going to be. Uh and in the, if you're up against the clock, if you have a contract date or some kind of renewal date, uh it's hard to make those decisions super quickly. And so being able to move into something like VMR Cloud and AWS and get out of that environment uh allows you that time to figure out what is my strategy for my workload modernization? What is my, my future plan that I'm gonna end up doing with these things?

And, and ultimately, that's aaa major use case. The second use case that we hear a ton about is disaster recovery, disaster recovery is, is, it's wild. I, I've had so many customers come to me and they say, hey, we had a situation where we had an audit or we had our board got involved and, and basically, we're, we're very unhappy with our current DR strategy.

Uh we went in and we ended up using VMware Cloud and AWS or we used AWS SDR uh which is a, a capability that VMware is built on top of AWS. Uh and within 24 hours we had a, a disaster recovery solution in place. And it was working interestingly enough.

I had a, a Re:Invent talk a couple of years ago where uh I had a customer come on stage. These folks had done a, a disaster recover. They were setting up DR and they were using VMware Cloud and AWS. They did a test where they actually failed over and ran their workloads in VMware Cloud and AWS. They were going through all their validation pieces and they're like, wow, this is a lot, a lot faster than our on prem environment. We should just leave this.

And so they ended up like they did a fail over test for DR stayed in, in VMCLOUD and AWS and then made their on premises environment. Uh the actual backup to that.

Uh so DR is another, another really compelling use case that we see a lot of folks uh use, it comes in um very, very handy if you, if you have, um I, I, if you have kind of like old DR environments or no DR environment and you're having to maintain that, that uh equipment I mentioned earlier, the patching, updating and upgrading, talk about undifferentiated heavy lifting.

If you're having to patch a bunch of software, replace failed hardware or, you know, a power supply or a hard drive in an environment, that's your DR environment. Like, like we're spending engineering time or administration time working on a piece of hardware that's sitting there, burning electricity or heating the air for no reason. Other than just to be a backup, that's a great use case to be able to take advantage of something like uh like VMR Cloud and AWS or, or the VCDr capability.

So I wanna uh hand this over to Rick and have Rick talk about their story.

I mentioned the piece about speed uh and the criticality uh the scalability of vm ore cloud and a bs being able to scale up and down as you need it. Uh and, and really that flexibility. I, i uh hope you find this as fascinating as i did. I was so impressed with, with not only rick and his team but, but the company, as i learned more about phillip 66 i was, i was blown away. Like, you know, i think when you, when you hear about some companies, you think, oh yeah, like i've heard this name before. This is, you know, a pumps and pipelines company. Uh i get it and, and then the more i talk to rick, i was like, wow, these people are doing so much more than, than i had uh an appreciation for and, and i was totally blown away by their commitment to safety uh and, and just innovation and the things that they are doing and, and how uh how much they are embracing innovation and technology. Super impressed uh rick, thank you also for taking the time to share this with us and uh i'll hand it over to you and, and uh have you run from here? Ok. Thank you.

All right. Thanks everybody for being here. It's 830 in the morning. I know it's uh it's pretty early for most, but um i want to start out and really talk about who phillip 66 is just a brief, brief overview on phillips. So we are a fully integrated uh downstream provider. And for us, phillip 66 is, you know, we, we do a lot. So we are a fortune 220 company headquartered in houston, texas and we have about 13,000 employees. So if you look at our lines of business, we have four lines of business, probably most of us think of phillips 66 as a refining. But as you can see up there, we have about 1.9 million barrels per day capacity within our refineries on the midstream side, we have about 72,000 miles of pipe in the ground in chemicals. We partner with c pc m. We're 5050 partnership there and we have about 28 locations and two research facilities. And then in marketing specialties, we have about 10,000 branded outlets for our, our products.

So we started our digital transformation in 2017 when we became a cloud first company. And so for us that said, get everything into the cloud as fast as humanly possible. Fast forward. In 2023 we have about 98% of our identified workloads in the cloud today. And so we use the power of the cloud to really accelerate and work with the business and partner with them on all sorts of innovative projects.

So when it came down to our journey, i i brought this quote up, we were in an acquisition last year and we had one year to to fully integrate our, our company. And so from an infrastructure perspective, that's the first thing that has to come across. And you know, everybody said this is going to be impossible. You guys don't have enough time, you got to make it happen. So with, with v more cloud, we actually did make this happen and i'm going to go through that journey with you.

So a little bit about where, how we understood vm ware cloud from the beginning. So back in late 24,021 we had a series of pretty impactful outages um in the cloud. And so we started to rethink about our architecture and say, how can we do this better? So, our executive sponsor is david brown and he came back and said, you guys are thinking about this wrong. We came from an old data center perspective where you do east and west data center, one to data center two. But we, what we didn't do is really architected well using availability zones.

So instead we changed our philosophy and said we are going to use availability zones to the max. So in a w in east one, we use all seven to protect our stuff, energy industry is we say very conservative in the way that they do a lot of their applications. We have a lot of legacy apps on windows and it's very difficult to protect those because they were not built with h a in mind. They're not built for high availability. So how do you protect those in a single a z? You really can't. And so vm ware cloud came up and we said that's where we're going to go.

So for us when we look at vm ware cloud, we kind of use it in a multitude of different ways. So for our production workloads, we use the stretch cluster. So that's active, active across multi az and that gives a lot of protection for our windows apps and specifically the windows apps. I'm looking at here because those are the ones that are really legacy off the shelf type of apps, you know, non stretch, just regular old esx cluster. We use that for our test of de we can have outages there and we're ok with that, you know, when we started getting to vm ware cloud, we were able to reduce our footprint. And so that helped on our licensing costs because we were able to get some efficiencies that we weren't having on ec2. And then we improved really our uptime and our reliability. So for us, it's key, we have some by 24 hour operations. So any outage is a is a big deal for us and we have potential of losing, you know, millions of dollars per minute. So we are trying to make sure that we're protected and then for, for the, for the infrastructure team, they want to have a single pane of glass. So we use vm ware at all our refineries, we use it on prem for a lot of different things. But in the cloud, we also want to have a single pane of glass and bring all of that infrastructure to to a single pane. You know, my team is not huge. So making this very easy to manage was very important to us.

So let's talk about the challenge. So in 2022 we, we went through an acquisition right at the end of the year. And so at the beginning of this year, we told investors that we are going to have this thing fully integrated in one year. And so that means we are going to have to bring over all of their servers. So we were given three months to move 1000 servers from on prem in denver to the cloud. And because of that time frame, we had the inability to do any optimization as part of the process we were moving like for like just getting it up. And this is ska pipeline control legacy apps, their hr er everything. So we were we were having to move that in three months. They're a seven by 24 hour operation again like us. So unplanned outages were unacceptable.

So we had to do this, making sure that the business continued to operate. There was a lot of data that we had to move so that they had terabytes of terabytes and terabytes of data. So we were having to move that onto fsx along with trying to move these applications across our setup was we had a vpn connection and we did everything across the vpn ip sec tunnel to the cloud. And so we used equinox and our on ramps to be able to get to our direct connect and be able to move those workloads immediately into the cloud.

So if we look at kind of our goals, we laid down some some basic foundations that we, we had to live by. So first was we had to move these workloads without changing the ip addresses, without changing their server names and without removing from their active directory domain, easier said than done. The great thing was is that we had very little ip overlap, which never happens. But in this, in this case, we did not have much ip overlap. So we were able to maintain their servers.

We had to build a security boundary. These were still two separate entities. We had to make sure um as part of our goal was we needed to build an inspection of pc and make sure that everything that came across into our enterprise was secure. We also had some ot stuff that was there. So we had to make sure that was very secure as i talked about this a lot, but there's seven by 24 hour operations from midstream. So midstream is, you know, pipelines and so they had regulated pipelines and nonrelated pipelines. And so there's a lot of things that we have to consider when we get into the regulated space, especially around t a. So we're under a lot of audit obligations for t sa. And then as part of this, we also had to maintain their socks. So that was the, that was our goals. Those were, that was the problem at hand and we had three months to make this happen.

So let's talk about what we did. So we started with the, with the, with the published reference architecture and we did a little modification. As i said, cybersecurity is a big deal for us, you know, being a fortune 20 company, we're, we're a target for a lot of folks. So we had to make sure that we maintain that, that solid security boundary.

So if you look at the reference architecture, this is what you'll see on, you know, on the web. So we do, we do a connection through our transit gateways uh directly into to v mc. When we updated it again, you'll see. Oops went the wrong way here. There we go. So we start, we added an inspection of vpc and the reason i'm talking about this because there are some things that, that challenge us with. We also had our stretch cluster and our nonstress cluster. So this became our new reference architecture for v mc. The beauty about this is that, you know, we didn't have to go and try to rebuild this from scratch. And we talked about, he talked and he talked about, you know, the difficulty in trying to maintain the entire infrastructure to make this happen in the cloud. If we had to build this, there had been no way we would have been successful in our, in our journey to the cloud for um dc p.

So next we started, we said, oh, well, you know, we'll make this work. Um we'll use a single cluster. I think we'll be able to fit it all. We use the stretch cluster for everything. But we found out is that there are some limit in the cluster, especially around how much data you can, you can put in a cluster. And we also need to be compliant. So you know, oracle is very strict with their licensing model. So we had to build clusters to maintain those licensing obligations to to oracle.

So if we go look at kind of the clusters, i'm not going to read this out to you. But you can see this is kind of typically what a cluster looks like. The one thing you need to notice is when you get into stretch, you no longer have 16 nodes that you can deal with, you only can deal with eight, it runs active, active, but you still got to be able to fail across on multiple azs. So i guess we were not up to speed on that in the beginning. And that's why we thought we could put everything on a single cluster. So we had to, we had to build some extra clusters. It's not a big deal, but some of the things we just need to make sure you, you, you remember. Um so we had a false understanding of vm ware

You know, we've been using VMware forever. I mean, like all huge enterprises, VMware is, is a core foundation. But what we did find out is that there's, there's a lot of little nuances that we were not, I guess it's not that we weren't aware of, but they came back to kind of bite us when we did when we started doing our implementation.

So the first was, was the MOD feature. There's a great feature this keeps traffic local to the cluster instead of going back to the gateway. You know, for us, this, this started to to become kind of a challenge because we did subnet by subnet migrations. So we could not move the gateway when we started to do our migrations. So we had, I think 100 subnet migrations that we had to do. And so what happens is with the MOD feature because we had the inspection of VPC, we also had the VPN tunnel, it was trying to, it would create what we call an out of state network or out of state traffic. And because of that, it would start to drop data packets or block data packets. And that became a huge problem because we had a lot of VPNs and we had a lot of other third-party connections. And so trying to figure out every place that MOD was being enabled, we had to go and disable it across the board. And even though we, we knew we had to do this all the time, it still came back to bite us nine times out of 10. And it's just something you have to watch out for. It's a great feature, but it's something that you, you definitely have to make sure that you understand. And again, if you're just doing a pure migration, you know, over the weekend, you won't have to worry about this feature. We were doing this over a month, period of time moving these subnets and so we could not move the gateway and this came back to bite us.

So Rick it sounds like the the MOD feature was, was incredibly important for actually being able to accelerate the migration. You mentioned earlier, you have a ton of data that you have to do that security VPC that you were talking about, ended up creating asymmetric flows and it couldn't see both sides of it. So when you say out of state, you're saying like the asymmetric flows were were by design, it was important, but it also broke some of the the acceleration and optimization features. But on some of those subnets, it was really important. You needed that accelerated data transfer to be able to hit your deadline, but you also needed to inspect traffic in other cases. And and that was more important. So you had to ultimately make those tradeoffs and decide on a subnet by subnet basis, which ones needed MOD. And which ones did not exactly. That's a great lesson. That's a great insight where I think coming into the beginning of it may not have been completely obvious, right?

So another thing was um the way that VMC treats S3 or um yeah S3 traffic. Um it, it, it pushes it, you know, to the directly connected interface. Again, we had the VPC, we had the inspection of VPC, we had to kind of break that workflow, otherwise we were starting to get blocked traffic again. Um you know, there's a lot of little like just little things about how, how VMC treats traffic.

Um we use SFS or FSX for a lot of our data FSX uses a basically a registered IP address. So it, it sees it as it needs to push everything out of our internet gateway versus keeping it local. So there's like little things that you just that, that will catch you off guard, but you know, you can always work around it and they're, they're not a big deal. It's just things you have to be aware of.

Yeah, I mentioned the whole ability that ENI to connect across to AWS VPC networks. So if you were to visualize this for a moment, imagine you have kind of an edge, an edge device and that edge device has a connection to your inside networks, a connection to your, to the internet as well as the connection, the VPCs to your AWS VPCs. And so in some cases, you actually can make the choice. Do I want to connect to an AWS service through the the private link to the endpoint that's running within the VPC or do I want to connect to the public API endpoint? So if you're familiar with S3, for example, S3 has a public API endpoint, these buckets, you, you can connect to it uh just publicly, you don't have to, it's not traversing an internet gateway or coming inside of your VPC. But you can also create a private endpoint for S3 where it can only be accessed. And you can put a bucket policy that says I can only access this bucket from within this VPC. That's just kind of a native, a native AWS capabilities. You can choose to access it publicly or privately. And in the case of here with, with VMC and AWS, they could make that choice. Do I want to access this publicly or do I want to access this privately? And those are configuration options you can choose actually within, within VMC and AWS. There's an option to select, saying I want to route S3 traffic that, that registered IP space that Rick's talking about. I want to be able to route that traffic across the ENI and have it talk privately within the VPC or do I want it to go publicly? But those are great considerations to think about as you're laying this out or planning it. And I know you all are moving very, very fast and it may not have been something to catch up front, but something you guys certainly figured out and were able to work with, which is, which is great.

And then lastly, you know, how are we going to do the migration tools? How are we going to make this, make this happen? So when we started out, you know, again, we looked at, we could do backup and restore some, my 24 operations, can't have downtime, too much data that wasn't going to work. We then started looking at some, some typical third party migration tools that we had experience with fantastic tools. But the problem was that they weren't certified on VMC. So they needed root access. VMC is not going to allow that. So we had to bypass that. We were probably less familiar with the native HCX offering, but that actually saved the day the HCX. I think it was coming out of private preview. We were still getting familiar with it. But what it really allowed us to do is do mass copy differentials up to the cloud and then we would do subnet by subnet migrations. We didn't have to change IP addresses, we didn't have to change our servers names. We can keep everything within our active domains. That was kind of the key to us being able to make that happen.

So let's talk about a little lessons learned. First and foremost, the network layer has to be major consideration when you're starting to, to work on these type of projects. You know, we have some world class network architects and they do a lot. But again, if, if the network layer is not operational and it's not working, you must have the transit gateway or it's just gonna be too slow. So you've got to really concentrate on your network layer two. You know, we use Direct Connect, we have three on ramps to AWS through each of our uh cloud connects, which is our Equinix facilities. And so that is, that is a major way to, to, to gain access to AWS. So the transit gateway gives you, you know, 50 gig throughput. Um and it, it does a walt when you're trying to do your migrations, you know, we had a lot of VMware skills in house and that was great. I think we have more VMware skills. Now after this project, uh we really had to learn a lot of new things on the fly. But again, you need to have some VMware skills, especially if you're going to do this in a, in a quick time frame.

Um so that by some cut overs take a lot of planning, you know, when i say a lot of planning like plan, plan plan and then have plan B and D when it, when it may or may not work. Um you know, we were coming into this a little bit of blind. I mean, it was an acquisition. So until we signed the paperwork, we really didn't have a lot of exposure to their back end infrastructure. So because of that, we were coming in blind and so we knew how to do it, but we didn't understand pretty much all of the, the interdependencies immediately in the beginning. You know, i think if you do have time using vRealize Network Insight or vROPs will help you with your dependencies. You know, as the connected enterprise starts to grow and grow, it becomes a spaghetti bowl. And so trying to figure out what servers talk to which, which other servers which subnets need to go with with each other. That tool was invaluable in helping us try to decipher what we were going to move, especially in the subnet by subnet planning dependency mapping is something that I hear come up from a lot of different customers is and especially when you have to, to move quickly like this.

Uh and in that acquisition where you may not necessarily know what applications are talking to each other, having a, a tool or having an ability to just figure out what apps are actually communicating with each other. Um e especially if the, I don't know if the existing environment, were they running NSX at that time or was it, was it all just standard VMware? Yeah. So, so like if you're moving from an environment where there's no NSX and all of a sudden, you're going into VMware Cloud and AWS where you have NSX, you have an opportunity to put in east west firewall rules and actually segment that, that traffic. But in a lot of cases, you go ask like what's talking to what? And you know, you mentioned 1000 servers like I'm sure that's super difficult or nobody keeps track of exactly what's, what's talking to. What? So being able to do that lay of the land, get an assessment of it and then bundle those things together to say, oh, these things are gonna move in, in waves or groups. Uh I'd imagine that was a huge benefit.

We got to be experts at diagnosing firewall rules that, that helped us a whole lot. Palo Alto and us became very, very close friends and trying to figure out our firewall rules. And then lastly, you know, we had to, they were a little bit back, back level on their ESX so that we had to, we had to actually upgrade a lot of their platforms to be able to, to make these migrations. And so we didn't really think about that. We thought, you know, hey, it's, it's VMware to VMware, we can move, we can move these workloads, no big deal. But in, in retrospect, it took a lot of time and effort to, to get them so that we could make this migration.

So, you know, that's kind of our journey that we took um as i said, a lot of people thought it was going to be impossible. I think some of our people thought it was impossible. But uh they worked a lot of, a lot of hours, they dedicated a lot of time to make this happen. And we did this in three months and we had about a month and a half of prep planning. And on top of that, we were doing all sorts of other migrations. So this was just 11 of the links in the cog that we were, we were doing at the same time. But getting this across made a huge difference because now we are in the final throes of, of the, the integration with DCP into Phillips 66.

I mean, that's an interesting point like all these folks who were working on this uh this migration still had their day jobs, like they were still doing their day jobs. And all of a sudden, i could imagine you, you walk into a meeting and you're like, hey, everybody guess what? You get to migrate 1000 servers in three months. I'm sure everybody was cheering and super happy about that. And they said, yeah, Rick, we got this.

Um i was unpopular for a while. Uh it, it's such a, an incredible story and, and i mean, really just think about it. If you, if you had somebody walk in and say you have to, we're acquiring a company, you have to move 1000 servers uh in, in three months and you still have to do the day job that i'm sure was not. Like you were sitting around playing solitaire all day to begin with. Um like this is a, a monumental undertaking for that team. Uh and, and all the, the planning and you mean the kind of like all the little gotchas. I, i love that Rick can come up here and share with you the, the reality, the real world. You know, we can talk about this is the way it's supposed to work all day long. Uh but it's such a gift to be able to hear from somebody who's lived through this and said, hey, here's the, here's the reality, like, be sure to make sure you, you think about, you know, upgrading ESXi in the source environment that may not have been something to think about or IP overlap or um the, the firewall rules and, and grouping like these are, are really great things to hear that hopefully will shed a lot of light uh on folks who are thinking about using this type of uh a approach in their migration.

Yeah, so the VMC saved the day and it, it uh it continues to be our, our go to for all of our production workloads. So i guess i'll hand it over to you. Thanks. Thanks Rick

Really appreciate that. Um wanted to talk a little bit about next steps. If, if Rick's story was interesting to you and, and what his team was, was able to accomplish, sounds like something that, that may be valuable uh in, in your space and in your use cases, um I wanted to leave you with a little bit of, of next steps. Like what are some things that you should be thinking about uh a as far as um getting started or learning more or just diving a little bit deeper.

There's other sessions throughout the week that, that talk about uh VMware Cloud and ADBS. Uh there are also uh the VMware booth and the expo hall stop by. Talk to those folks. They have some demo set up where they can actually show you uh the environment. But seeing it and hearing about it is one thing uh I would say there's no, there, there is no substitute for real world hands on access and, and, and in real world results being able to put this uh in your, in your team's hands in your hands and actually try it out and, and see how it truly works.

Um what's great about a cloud environment is, you know, we talk about being able to use it for experimentation. Uh that is uh a major thing that folks do with ADBS and that's where a lot of innovation comes from. Being able just to try things out, test it, put your hands on it, you're not investing hundreds of thousands of dollars in capital to go do an experiment for a week. You can, you can uh fire it up, turn it on, try it out, turn it off, uh turn it back on again if you want to try something different.

Um I I highly recommend if this is just, just give it a try, just actually go in and fire up a VM or cloud and ADBS environment. Uh you can spin up an environment, you can deploy VMs in it, you can connect it to a test or a lab uh environment uh on prem uh and then migrate a virtual machine, set up hcx, migrate a virtual machine. The, the setup of the network bit is, is really a where a lot of the uh a lot of the lessons come come uh from, you know, Rick was mentioning, you know, one of the things his team had is like the the networking expertise and like working through the networking bit is super important. And I I completely agree with that.

Um I, I hear customers say it took us, it took us a few days or a few weeks, even in really complex environments to get the networking stuff figured out to get the connectivity established. And quite honestly moving the virtual machine was, was like a right click and a and a go again, that part of it was so anticlimactic actually moving the bits over it just it just kind of worked but did have to spend a few days or a few weeks in really complex environments, getting the networking stuff figured out getting the, the prerequisites and the connectivity put into place.

Uh and I encourage you if you, if you uh if you have like a, a test environment or something that you can just try as an experiment uh go spin up an environment, give it a give it a try uh you know, kick the tires and, and see what you uh see what you think about it. Uh and then when you're done, you can destroy the environment and, and turn it off. There's no, there's no long term commitment for this just to experiment and try it out.

Um we, we do also see a lot of customers use VMware Cloud and ADBS for uh kind of temporary uh temporary life rafts uh for environments that they need to make changes for. I've seen customers actually, they're, they're doing power maintenance or they're doing some kind of uh environmental maintenance in an on prem data center and they would spin up VMware Cloud on ADBS, migrate their workloads over as a temporary housing location and they would, you know, completely tear down their on prem environment, rebuild it, move things around, do the physical work they needed to do and then move back.

Like how many times have you had teams internally say man, I wish I just had a, a temporary cluster for a few days. Um and this is a case where that can be uh be useful as well.

Al also just in the case of like bursting or expanding environments, uh we see folks do this a lot as well. They have an on prem environment. They're, they're depreciating it over aaa long period of time. So they're not interested in and, and migrating today, but they have a big event coming up, you know, think of like a, you know, uh uh an organization that is big around the holidays or big around, you know, a particular uh sporting event or something like that where they need additional capacity.

Uh but they already have their templates and their tooling and, and everything is already built around the VMware ecosystem. Uh being able to actually spin up an environment and expand and burst into the cloud. Have that elasticity of, hey, if I need to add a host to an environment, I click a button and within about 10 minutes, I have a host available. It's, it's ready to go. I it's, it's ready to operate, you know, contrast that to an on prem environment where you have to buy a server, wait for it to show up rack and stack, burn it in configure it, you know, that is a weeks to months operation. Whereas getting a new server in a cloud environment, it is a single digit number of minutes operation. So being able to use this as a, as a burst use case.

So just I encourage you to think about ways that you could experiment ways that you could uh just kick the tires and leverage this. There's you, you can read about it all day long, but there really is no substitute for just giving it a try and uh and uh actually seeing real world results.

Um one thing I would recommend uh is, is I'm sure Rick, you also had this happen within your organization, but you really have to bring the teams together around this. If you have kind of siloed or siloed teams within your organization, where we have a networking team, a security team, you have a vSphere team or aaa compute team. Uh and all those teams are completely independent.

Um it is very, very important to bring those teams together and, and really have them work within a cloud center of excellence or form a cloud center of excellence. If you are moving into a cloud environment, there's so much more that you can do uh with integrating into native services and, and taking advantage of all the native capabilities within a WBS.

Uh one of the first things I recommend folks do is don't let, don't let VMware Cloud and A WBS be a siloed project for the compute team. You really do need to bring a team together, have representation and folks from the security team from the networking team uh from, from storage, from, from all those different parts of the organization, compliance, everyone, you, you really do need to bring those teams together and have this be a joint initiative, a joint effort.

Um that way they can all be a part of the, the transition and all have a voice in the configuration. Uh I, I have seen it, you know, honestly, the political aspects of this where one team has built it and they made it work. And then, you know, they didn't bring in uh the compliance team early enough. And so now it delays migrations and delays projects just because they're trying to bolt that on uh at the end, that could be a real challenge.

So, so bringing in those teams early, uh it is super important bringing the group of folks together uh is critical uh proof of concept environments. I mentioned these are uh I, I can't say enough about them. I hear so much feedback from customers saying, you know, I met with my solution architect, I met with VMware and we heard about it like, yeah, it made sense. Everything seemed great, but we really didn't get it. The light bulb truly didn't go off until we did that first virtual machine migration. And when we moved it over and we saw it in action, that's when it really clicked for us. And that's when we started thinking about all kinds of other things that we could do.

Uh so I, I just, I can't say enough about deploying a proof of concept environment and actually trying it out. Uh and I, I get that migrating a workload may not be uh migrating a real production workload is probably not the, the safest thing to do, probably not the thing you want to test with. So I always encourage folks if you have aaa lab environment or a demo environment, a dev environment, grab some non production workloads and let that environment be your test case or, or, or stand up synthetic workloads or synthetic VMs uh if you want to test in that way but, but actually test with something real like uh find something that is meaningful that you can actually have performance indicators before and after and you can see those results and me measure those results.

Um and, and, and uh and be able to, to report on that. I also wanted to share uh we announced this week here at re invent. Uh we made an announcement earlier that we have launched a new instance type. So I mentioned earlier that the VM or cloud and ADBS runs on a DS bare metal instances. We have a few different instances that are out there. Rick mentioned the I four I instance and he showed the, the, the page with what the specs on that look like.

Uh we also have the I three EN instance that we uh we operate today. Uh and we have announced uh earlier this week, uh the M seven I metal uh 24 XL variant. So with M seven I metal, we actually have a couple of different sizes of, of metal instances there.

Um and the uh M seven I 24 XL instance was, was announced this week. What's super interesting about this for those who are familiar with vSAN, uh the way vSAN works is it actually aggregates the local storage within the physical server itself. So you have uh local instant storage and vSAN aggregates that together and forms a distributed data store.

So if you want to um if you want to add additional storage, you add an additional compute node and you scale compute and storage uh together linearly uh with the M seven I do metal 24 XL instance. Uh we are not using vSAN for local instance storage. In this particular case, in this case, we are using external storage, the FS XN that is an ex external file-based storage solution.

So if you're familiar with NetApp ONTAP, this is the A W FX version using NetApp ONTAP. And so you have decoupled storage from the compute and you can see the, the instances themselves are a little bit smaller in size than what we have with the I four I.

So I four is are are much larger instances, much more memory and cpu capability. Uh the M seven I do metal is a much smaller instance. This is really great for proof of concept testing as well if you want to test with a much smaller instance. And since it allows you to decouple the storage from compute, uh if you need a really small compute footprint, but you have a lot of storage.

Uh this allows you to scale that storage independently of the compute. Whereas I four I is going to be a much beefier, more powerful instance, but it is also it's going to have compute and storage scale linearly. Uh and the same thing with I three EN uh I three EN is a, a much more storage dense instance. So it has a lot of local instant storage. And it's a great use case if you need uh kind of the, the performance of local NVMe storage um uh aggregated with vSAN uh that, that is a great instance use.

So the goal here is to give you choice uh you have multiple instances to choose from. You can pick the, the best use case or the best instance for your particular use case and you can deploy multiple clusters. So you could have a, a cluster of I four I metal instances. You could have a cluster of I E in instances you can mix and match.

And the same thing is like what Rick mentioned, they mix and match where they had one cluster that was stretched. Uh within um across multiple availability zones. So you're actually taking that, that VMware NSX environment and the storage environment and you're stretching it across multiple availability zones.

So that is a really interesting option because not everything is sitting within a single AZ and you're having to, to replicate it out. In this case, the cluster is stretched and BMR is taking care of replicating that and making sure the network is coherent across both AZs.

Um and then you can have the, the non stretch version where it's just isolated and independent within a, within the availability zone. So you can have multiple instances, instance types for clusters, you can have um I'm sorry, multiple instances that form a cluster, you can't mix and match.

So you can't have an I three EN with an I four I in the same cluster, but you can have different clusters deployed and then you can have those clusters in both a single AZ and a stretch cluster configuration with that.

Um we are available to answer any questions. So we were, we were shooting for about 15 minutes left that we could, we could shoot down here or sit down here and answer any questions. We're at, we're at 14 minutes, we made it. That's a, that's a win.

So uh we will say with that, we'll say thank you. We'll be uh down front if you'd like to come up and uh ask any questions really appreciate you taking the time to join us this morning. We hope this was informative.

Uh I would ask if you have a few minutes, please take a chance to or take a moment to open up the app. Uh, fill out the survey. Let us know uh what you liked if there's something that we could be doing better in the future. Uh that, that information, that feedback is so critical to us. That's how we choose what sessions we're gonna be looking to do in the future.

Uh, and, and what topics are most of interest to you. So, if there's an area that, that we could focus on, uh, more that you'd like to hear more about, please give us that feedback. We'd really appreciate it.

I hope everybody has a great rest of the show. Thank you so much for joining us. Have a good day.