 Thanks, everybody. Hello, and good afternoon. As you mentioned, my name is Carmine Remy. I'm the lead the cloud engineering team at Workday. We are part of a larger organization within Workday whose charter is to revolutionize its data center strategy. Not only that, but also innovate in terms of how we operate, manage, deploy, both software and hardware devices within our data center. It's been a exciting journey so far. And today, what I'm going to share with you is probably three short stories that hopefully encompasses most of our journey with OpenStack so far. My hope is that through this discussion, there's some of you out there that can relate to our journey. And at the end of this talk, even throughout the rest of this week, we identify others who think like us, who might be willing to work with us and help innovate around the edges of OpenStack. So before I get started, a little bit about Workday. Workday got started in 2005. We focus on applications in the HCM space, human capital management, as well as financial management, talent management, time management, and payroll. Recently, we have an application around big data analytics. And more things will be coming down the path. But we are a enterprise software as a service company. And about two years ago, we launched an integration platform as a service. And so I can see on the screen there, Workday applications and the APIs that we made available. We're already being consumed by our customers. And at some point in our journey with our customers, it was brought to our attention that you have a great application, great service that runs up in your cloud. These integrations that we build integrating with your APIs, wouldn't it be great if we can actually run these in your cloud as well? So sure enough, we built one of the first integration platforms as a service. It was really successful. As a matter of fact, within the first quarter, there were hundreds of thousands of integration workloads that we executed. And within Workday, this was a pretty fundamental shift. Up until this point, all of the software that we ran in our data centers, we created. So we're totally in control of knowing the software, but the security, the workload, the operational dynamics. And it was at this stage, launching this iPass, where we started to integrate and run untrusted software in our data centers. And so that was a sort of order of magnitude increase in complexity in terms of how you actually do this in a secure, scalable way. And so we did that. We crossed that chasm. And it was, by all measures, I think, a success. And afterwards, we took a step back. And we marveled at how much power we gave to our customers and the applications that we ran in this iPass. With very little setup, once you're set up and you're allowed to run your integrations in our cloud, there was no further touchpoints with our organization. So we completely reduced the friction, allowed them to run these integrations at any time. We obviously monitoring the scale of the workloads and the scaling the proprietary infrastructure as a service to support this. And so on the back of that, our customers probably have a better experience than our internal developers building their workday applications. And at that stage, we sort of said, OK, well, what would it take for us to turn this over to our internal developers and give them the same kind of capabilities that we just gave to our customers? It's a great question. The challenge is our proprietary infrastructure as a service was an MVP, a minimally viable product. It was designed specifically for the iPass. And so the features and the functionality was sort of a small subset of what you might expect. In order to have this technology and use an infrastructure as a service power our entire data center, which is kind of what our goal is, we sort of felt like we needed something more robust, more scalable, more industrial strength. And that's kind of the beginnings of how we got to evaluating OpenStack. Naturally, when you begin a journey and you think about, OK, well, let's figure out what it takes to sort of close the gap in terms of functionality and features. One of the first questions you tend to ask is, should you build your own? Should you continue with some technology that you already have? Or should you use an existing open source framework and technology? At the beginning, this was back in January and our team was actually fairly new. We sort of put on the shortlist OpenStack, CloudStack, Eucalyptus. And if you've been using OpenStack in anger, it might seem strange to evaluate all those. But from the outside, looking in, it wasn't clear at that time who the clear winner was going to be or is. And so to help us navigate this and make this decision, and certainly even just in terms of building our own, we had a healthy appreciation for how much work was involved just by building our iPads. We came up with our own list of criteria. Most of these probably seemed fairly intuitive. Earlier, they talked about the openness and how important that is. And certainly that was important to us, both the community, the technology. But just to talk to some of these, easy. We played around with each one of the three that I mentioned. And how easy was it to download? How easy was it to install things for OpenStack? Like DevStack? It was great. You can put it in a virtual machine and then run the entire OpenStack solution. But then how easy was it to actually do this in a distributed way, whether it's distributed virtual machines or even within the data center itself? How easy was it to deploy and manage? And that's why things like Mirantis Fuel, Rackspace cookbooks in the private cloud, and other solutions have come down since then, struck us as, OK, that's an exciting part of OpenStack that we didn't exactly see in some of the other solutions. How flexible is it? Does it have a plug and play kind of architecture? Can we swap out components? Can we add in our own integrations? Because certainly with Workday, it takes security, like most you do, very seriously. And for Keystone and other aspects of security within OpenStack, how hard it would be for us to add our own sort of secret sauce. I'll skip down to number seven. And one of the things we looked at very closely was how vibrant was the community. Specifically, at the time, we were looking at OpenStack and CloudStack, how big was it, how many contributors were there, the actual number of issues, blueprints, all those kinds of information that you can get through OpenStack. We sort of did a comparative analysis to see which one has a better story. And then lastly, momentum. You'll see a lot of graphs like that. I got that from Randy's blog over at Cloud Scaling. And he got it from somewhere else. But back in the middle of that graph, when we first did our analysis, it was like, OK, OpenStack looks pretty positive, got a better story. And since then, it's just got even better. If you're buying a stock, you'd probably want to buy OpenStack, right? And so that was our criteria. That's what we use. And certainly if you're on the fence, and some of this criteria makes sense, we have additional criteria. I didn't put everything up here. But that was probably a good start. And it helped us kind of defend the fact that let's do our proof of concept with OpenStack rather than some of these other technologies. Once you've made that decision, so that was probably our first part of our journey, the next part of our journey was, OK, now let's do a proof of concept. And that's where the next set of challenges came into play. It's kind of like going to a buffet, whether it was at lunch today or at breakfast. What do you do? What do you eat? What are you going to consume? Or you're like me and go to dessert first and then carry on from there. Within OpenStack, there's a lot of decisions you have to make. And I listed some of the ones that we had to look at from the very beginning. And certainly as part of our proof of concept, we actually played around with the various different values for each of these questions. Starting with the operating system, go back six months. That was our first OpenStack conference we attended. And you come away from that thinking, OK, everything's got to be in a boon to. And if you don't do a boon to, you're going to be lost and you're going to be sort of out in the wild on your own. But we have a lot of expertise in sentos. And so what does that mean for us as an organization? Virtualization. So our initial solution of proprietary infrastructure as a service was built on Zen. Should we continue to use Zen? Should we use KVM? For similar reasons, as I mentioned, it seems like everybody's using KVM. Or some other kind of virtualization technology. For the networking, we're heavy into L2. Should we move to L3? Do we adopt SDN? What should we do there? For provisioning, you saw with a boon to, you got mass. Should you use crowbar? We use cobbler internally. Is that what we should stick with? What's sort of the best thing here? For deployment, we like Chef. Should we do puppet? Should we do juju? Hard to know. And what actually I should add at this point, what makes this even more complex is the combination of the various settings that you have and the combination of choices you have and do they all play nicely together? Certainly we found that there can be rough around the edges as soon as you get off a well-defined path and it behooves you to sort of think about number six and vendors. And can you get some help? Should you go with a pre-baked solution that some vendors provide? Or do you stick with the OpenStack framework and instead leverage puppet or Chef to make some of the choices that you want to make but sticking within the mainline trunk? And then finally, you know how do you contribute back? As I mentioned, these are some of the things that we like. We like CentOS. We use Chef, KVM, cobbler, VLANs, a few other things like that. I put up here teamwork. As I mentioned at the very beginning, we're a small team focusing on the infrastructure as a service layer. But we're part of a larger organization and we really wanted to tap into the strengths of the rest of the organization. We are, as some of the earlier presentations talked about, we're more of a traditional data center. We're not necessarily a data center that whether it's the Shutter guys we're talking about, something along those lines. So it's very traditional, very enterprise-like. And so we wanted to leverage their strengths. And that was, I guess, a very important turning point for us because it allowed us to not only focus on more of the OpenStack-related stuff, but at the same time, it did create some problems for us. Some things aren't always tested on CentOS, as an example. And not everything worked, like to Jerry tunnels or something along those lines. But their rewards are worth it. And the entire team is on board with what we're doing. So with all that, you've selected OpenStack. You have your evaluation criteria. You made some decisions based on what flavor of the OpenStack you're going to run with. At that stage, we kind of dove in, started to build our proof of concept, comforted by the fact that we're not alone. Other people are doing it. I mentioned some of the problems. And so it's kind of good to be able to phone a friend. We have a relationship with Rackspace and with Morantis. We leverage both of those organizations. We think they have some really good strengths in the technology choices that we've made. And that relationship has been really helpful for us in terms of keeping us on path with our proof of concept. And so I can't emphasize that enough. We probably waited too long to actually reach out to those organizations and get some help. But once we did that, it was a much better experience for the developers on the team. With all of that in place, we just followed some solid engineering practices to kind of make our proof of concept more of a production candidate. Starting with narrowing your focus. Some of the people mentioned that earlier. For us, that means each of these levels here, I kind of call those horizons, compute, networking storage paths. For us, this could be many months and or a year cycle where right now we're only focusing on the compute side. And just enough networking and just enough storage to make that work. And I can't emphasize enough with all the complexity around OpenStack how that's helped us deliver and deliver sooner and just focus on a narrow subset of problems. And again, back to that whole MVB process. That in itself is worthwhile for workday as an organization. But we will tackle these other areas. And as a matter of fact, right now we're going to go with the contract team to sort of investigate their SDN solution. And we'll obviously see where that goes. In addition to that, it makes sense to think about your simple use cases. And so the workloads that we're moving over to OpenStack, we're starting with our iPads and those workloads that get submitted to us. And so we're running some of these integrations on OpenStack today. It's pretty exciting. And also with the, and so that's there in the stateless and stateful area, some people have referred to cattle and pets. For workday in our application, our components that are more scale out, we're moving those on top of OpenStack first. And then as we get more operational experience and build this out to our other data centers, that's where we'll get more of the stateful scale up kind of components in our application stack. So I think that's a pretty challenge strategy. The next area that we really kind of focus in on, and we're not there 100%, there's, I think, a lot more work to do here, but the whole deploy globally, develop locally, and keeping everything reproducible. This is, I think, a really critical aspect of development. And I'm not sure that it's necessarily been nailed yet in OpenStack. Maybe it has, I don't know. And this goes a little bit beyond just DevStack and running everything within a single virtual machine. Some of the problems we've found is we'll have our solution that runs on our laptop. We'll go to a small sort of integration environment. And then as we deploy that solution into a larger data center, something as simple as a misconfigured IP address for a syslog server took us two weeks to find that problem. That's a long time. And if we were able to actually do some of the things that you do with dependency injection and software in Java, for those of you that have used that technology in Java, a lot of that is designed around helping you run your unit tests and do things locally so that you don't encounter these problems later down the road. So I won't talk about that anymore, but I think that's a really critical part. And one of the things that we're actually trying to do is look at, how can we create a virtual data center all within your laptop? From a router, a switch, SDN, OpenStack, Cobbler for provisioning the whole ball and wax and put it all in your laptop so that we can have a better experience when we actually deploy this in the wild. And so that brings us to this last phase of our journey, which is we're at right now. We've got a production candidate. Works great. This next, let's say, three or four months, we're going to be deploying this to all of our data centers throughout the world. And that's where an additional set of functionality and problems that we're working through right now is, how do you manage tens or hundreds of instances of OpenStack, both in terms of a rolling upgrade process, in terms of monitoring, troubleshooting? How does that work? How does that work in a seamless manner from a single pane of glass? And so that's some of the things that we're working on right now. We don't have that solution in place yet. We're working hard to put that solution in place. But it's going to be a fun story once we get there. And so that's most of our journey. We're just getting started. As I mentioned, we started this in earnest back in January. We've had a lot of fun since getting using OpenStack in Anger. We plan to have more fun. We're here to see where the technology is going, where we should place our bets. And ideally, we find other people who are innovating around the edges, as I mentioned, that would like to work with us and help build some of the technology. And with that, come ask me any questions that you might have or send me an email. Thanks.