 Good evening. My name is Philip Glebo. I'm the director of pricing architecture at GAP. At GAP, I'm sure as many of you know, we make clothes. This is actually from Banana Republic. These are our new traveler jeans, which I love. And we're comprised of the GAP brand, Old Navy, Intermix, Athleta. So we have a bunch of different brands. And today I want to talk a little bit about how we've used something called Garobi, which is a linear optimizer, integrated this with Cloud Foundry, and also worked a bit with Amazon to do this. It's a little bit of a technical talk. It's going to be a little nuts and bolts. So I'm going to assume that people are generally familiar with Cloud Foundry and with Amazon a little bit. This is not an endorsement. That's our company policy. That said, I really appreciate the opportunity that Pivotal gave us to tell you a little bit about what we're doing, both with Cloud Foundry and with Garobi. So here's a quick overview about what we're going to talk about today. But let's start with what's optimization. Probably not a lot of you, though. Some of you do have a background in operations research. The first example is the diet problem. You walk into the Mel's diner, and you want to find the meal that has the least calories with the most protein and balanced fat. That's an optimization problem. All of those parameters are somewhat at odds. Another example that you see a lot in this area is facility location. We've got a distribution center. We've got some stores. There's a cost to go from the distribution center to the store. Where do we locate physically the distribution centers and the stores so that we can minimize the cost and make the most revenue? So that's a lot of what we're doing with GAP in terms of price optimization. So I'll start with what we call localized promotional pricing. At GAP, we have several thousand stores, and inventory is constantly coming into those stores. So we need to move it. And one of the levers that we have to move it is the price. But we don't want to do something silly and say, well, this shirt isn't selling. Let's just take 50% off that shirt everywhere. Different parts of the country respond differently to changes in price. There's also weather to take into account. Short sleeve shirts go really well in San Diego, not so well in San Francisco. So there are those components that we need to take into account in our optimization model so that we can adjust the price and still move through the inventory. We have some pretty sensitive timing deadlines here. We need to complete essentially 6,000 instances of a very complex optimization problem in about four hours. And for those of you not familiar with Amazon's optimized compute instances, that's what C4, 4x large actually means. We use about 90 of these machines to solve 6,000 instances of this problem a couple of times a week. So it's very computationally intensive. Well, why did we go with the cloud? Why didn't we just set up a bunch of servers and open stack, put Garobi on them, and go about our business? Well, with the cloud, we're able to vary the cost. If the business needs more optimization this week, great. We can do that. They can pay for that. And we can deliver that capability. We can vary the performance if they need it faster or they need it slower. We can vary that with the cloud. And the ability to have an elastic pricing solution that can scale on demand is very powerful for us. We also just don't need to build a bunch of servers that sit around in the data center sucking up power that patched, that take up space that would otherwise be used for other things. So it's been very useful for us to move this into the cloud. And you guys know this. Maybe I'll skip this slide. But why did we go Cloud Foundry? Cloud Foundry really accelerates the process by which we're able to deliver these capabilities. Continuous integration, continuous delivery are very easy with Cloud Foundry. If we need to change the algorithm, fine. We can run it through a unit test. It flows automatically to production. So Cloud Foundry has been very powerful for us. It's something that would normally take perhaps days or weeks. We can compress that cycle into a few minutes. It's very quick to scale. If we find that we're not meeting our timing deadlines, very good. We can just simply scale it up. It's not a problem to do it. It simplifies our infrastructure. And I think more importantly, as an architect, for me and for my developers, it imposes a set of useful patterns. It constrains somewhat what people can do, but in a way that I think is very empowering. So I'll give you a little bit of an overview, technically, of how this has been integrated. Here's our tech stack. Sitting on the bottom, of course, is Cloud Foundry. As I mentioned, we use Pivotals as our vendor. It's a Java-based application that talks to Mongo, Rabbit, and Garoby, which is that linear solver that I mentioned earlier. We're Spring Boot Shop now. We migrated a lot of our applications to Spring Boot. And while that's still ongoing, that's been a really powerful thing for us. We also use Spring Actuator for some of the endpoints. And we allow clients to interface to our system, either through a web browser or through a set of REST services. So that's sort of the tech stack. There's sort of the tech stack in words. I'll just go through this really quickly. But I think one of the things that I haven't mentioned is data virtualization. At a company like the Gap, we have a lot of very different data sources that have been around for a very long time. And we need to impose some sort of order on this chaos. And one of the technologies that we use to do that is data virtualization. It essentially provides an interface layer across the DB2s and the Oracles and the My Sequels and the Mongos and pick whatever else you've got. It allows us to expose an interface layer that can look very much the same across brands. And for us, that has been very powerful. There's a quick diagram on it. If you can see that in the green labeled PCF, that's Pivotal Cloud Foundry. We have a set of services that do process orchestration, acquire and provision data. We use Spring Cloud Config to provide the configuration to all of our services. And then we have some of those other layers. We have Denoto. We have a database called LPO, which is just something. It's an Oracle database we use. And Denoto sits in front of that. Now, we're a little bit early, and we installed Pivotal Cloud Foundry internally a gap in our own data centers. We did not go with the public option. So there were some services that we didn't have access to that we needed to have access to, so things like Mongo. We had an existing Mongo database we needed to talk to. RabbitMQ, for certain reasons, had already been in existence. And we needed to get on that same platform. So those run an open stack. And our services speak from Cloud Foundry to our open stack cluster that runs internally. And then, as I mentioned, Gorobi runs in Amazon. So we're able to interact with the public cloud through that avenue through Cloud Foundry. One of the things I think that comes up, and you say, well, why did you build that process control? Why is this a little bit more complicated? Well, one of the things that we've done here is that we create what we call create cloud. But basically, we create cloud instances with the compute servers. Since they're very expensive, we don't want to run those all the time. We don't want to pay for those all the time. So we turn those on when we need them. If we need more, we add more. And when we're done, we tear the whole thing down. So continuing with the theme here, we're really just getting rid of it when we're not using it. And we build it again when we need it. That process takes a good two minutes. It doesn't take long. When we build messages, one of the things that we've done is we've used Rabbit to provide essentially a central queue for each of those 6,000 optimization jobs that I mentioned earlier, based on the queue, and we have a group of workers. So we're able to scale that problem and solve those problems in parallel because they're independent. So that's how Rabbit sort of fits into the architecture here. Again, we process messages. I borrowed these diagrams from our development team. It's a little bit detailed. But basically, there's a lot of process control that goes on there and a lot of reporting at data as we go. Now, there are some organizational issues that we ran into this. Chief among them is that Java really is not the preferred language for data science and for optimization. People prefer to work in Python or MATLAB or SAS. So it was a real big cultural shift to migrate something into Java, run this in the cloud when people are very used to working with something that is SAS and is internal. And we're still fighting that battle. I don't want to say that that's necessarily over or done with. But Cloud Foundry gives us options. If we were to run Python, that's something we're looking at. But Java works very well for us right now. The other is when agile development organizations conflict with something that's a little bit more waterfall. Scientists really want to be good scientists. They want to prove their theories. They want to have a lot of data. And that takes a lot of time. That's an expensive process. But turn around the agile development methodology where we're not aiming for perfection all of the time. We don't want the perfect to be the enemy of the good. So we continually deploy and we're happy to make mistakes as long as that blast radius isn't too large if it fails. So bridging those two mindsets has been a little bit difficult for us. But the fact that we're able to turn things around very rapidly has been very effective as a tool to get people to come around to that mindset. In the interest of time, I'm going to skip the Q&A. But please find me afterwards. And I'm happy to answer any questions you might have. Thanks very much for your time.