 Welcome Steve and Joel from Best Buy. Morning, Steve Eastam here, director of web architecture with me. My name is Joel Krabb. I am the chief architect for Best Buy.com. So Joel is gonna cover kind of the background of Best Buy, what we're doing in our program. Yeah, so let's just get started. We're presenting today in another breakout session. And, but today what we'd like to talk about first is just a little bit about Best Buy. If you didn't know about us, we are considered the largest multi-channel consumer electronics retailer in the world. 11th largest e-commerce site, 1.6 billion visitors last year. And we have a very large award program. So, let's talk about our cloud re-architecture. Over the last year, Best Buy has gone on a quest to re-architect our e-commerce platform. And part of that was to move our browse and search to the cloud. So, if you take a quick look at this graph in the corner here, that's our traffic graph from Wolfram Alpha. And as you can see, we got a really large spike that spikes right around Thanksgiving. And it's about seven or eight times our normal traffic loads. And so if that doesn't scream out for elastic scaling, I don't know what does. And over holiday this year, which holiday for us is Thanksgiving, we actually served 25% of our traffic off of our new cloud architecture. And this is the first time we've actually even talked about the fact that we have a cloud architecture. So we're rolling that out here. Really, really simply, this is what our architecture looks like. We have a global traffic manager sitting in front of a couple different clouds from different vendors. And then we have our data center in the background. But as consumers, it's really what you see that matters to us. So on the left side, you'll see our old, what we call our product detail page. And on the right side is our new product detail page. The new one is served off the cloud architecture. And you can see the timings on the top, the things that this really did for us and the value that it brought to Best Buy were that the old product detail pages took anywhere from seven to 30 seconds to load. Part of that was because a lot of the page was rendered, post-rendered JavaScripts on your client itself. And we had no control over how fast our third parties responded. What we did as part of our cloud architecture is serve the entire page off the server. So all those third parties now are integrated on our server side. And we can serve that page out to you in about two and a half seconds. And then why we're actually here today is to talk about our continuous delivery cloud. So we've built, we have about 40 development teams or so that are developing in any particular time on Best Buy.com. And all those teams are using different integration and testing environments because our infrastructure for testing really wasn't that great. And so what that caused us is lots of problems in teams using things that didn't quite correspond to production. They were making their own test services. And so what we wanted to do was make that something that was consistent and easy for all of our teams to use. So we created what we call the Continuous Delivery Cloud or the CDC so that our teams could have consistent architecture. And Steve Eastam here will start talking about that. Cool. All right, so what our CDC, as we call it internally provides us, an innovation catalyst. So all of our teams that are developing new NoSQL platforms or new caching platforms, they have a place to go, it's self-service. Want to do a quick shout out to everyone that was involved in Essex. We launched this a little over a year ago. It launched on a beta version of Essex. Along the way we did a few patches here and there but it's been rock solid. We're gonna talk about it in our breakout session today but just wanna say thanks to all the development and testing that went into that. Our teams have a push button. They've developed a push button development environment. They codenamed it OmniTank. I have no idea why it's OmniTank but it's an awesome name. Self-service APIs so teams can go in, they can launch their own environments. We were speaking yesterday about this and we used Jenkins to actually launch Jenkins so teams can have their own push button Jenkins. We have also used it for early integration. One of the things you wanna do in web development is not wait a really long time to integrate with the other teams. If you do, you'll run into trouble and that kicks your development cycle way back. It's all about speed. And again, automated testing at scale can run a lot of Jenkins executors and really reduce our automated testing time to just a few minutes. You can run through a full regression suite and really getting away from manual touching and changing of our environments. Getting to the point where everything's automated and that reduces the variability. So, talked about that, one more. All right. What we knew, when we went into this, we actually didn't know we were gonna have our new platform approved and this is back in mid-circuit, mid-2011, we ran a VSM or Value Stream Mapping exercise and saw that our major release for BestBot.com was consuming $500,000, mainly due to environment setup, discrepancies, availability problems. And we talked about that parallel development really needed a way to support a lot of teams running on all in parallel and then the high cost of infrastructure, our current ecosystem of partners, they were charging us upwards of $20,000 just to provision a managed VM with monitoring and everything. So, what we didn't know, didn't know that we're gonna have the green light for a new platform that Joel covered, didn't know how fast we're gonna have to get to actually get it out the door before holiday. And what it does for us as far as a culture, we're building a culture at BestBuy around self-managed developer-driven teams. And we really wanna let them run, do their own, launch in, run their own environments, kinda get away from the blame game, get away from that center of excellence. You know what's missing in the center of excellence, probably the excellence. The parallel development, we talked about that, I don't know how many times about parallel development, and then allowing the teams to innovate, they wanna test some new cache platform, some new NoSQL platform. Here's an API, here's a Jenkins job you can run, run your OmniTank, and then finally, it's all about reducing that cycle, that going through test dev, test dev release, so really reducing the delta to get code complete to get all the way pushed out to release to world. And this is one of our teams, it's a Transformers team. They are working on some of that complex middleware, what we call aggregate services, and they use a heck out of the CDC. It's totally transformed their work, so cool. Here's another team, Customer Graph. You'll start seeing big changes and then the way we deal with profiles, some of our personalization in the site, and these guys are actively working on that and using the CDC, cool, all right. So thank you guys for coming and talking with us about this today. One of the things that you were telling me before was how you got started with OpenStack, that this was really kind of sort of a side project almost. Yeah, I mean we have a lot of things to do and we were spending a lot of money, we talked about that just to get a provisioned VM for our dev teams or to run a Jenkins executor, and so we kind of put together that business case and it started with just one rack of servers and we took a couple of our dev teams, mainly Java devs, some of these guys are out here, and they learned Python, they learned, we also use Chefs, so they learned the Ruby, so some of them don't want to go back, right? Kind of converted, so. Well, that's great, thank you guys for coming and talking about it. Thank you, all right. Thank you.