 I'm Bill O'Neill. I'm a senior systems engineer here at Spreadly. I'm going to start off with explaining the title of my talk, because it's kind of weird. How many people here have heard of the analogy of servers as pets versus server as cattle? OK, more than I expected, which is great. So us at Spreadly, we're in the middle of this move from physical servers in a data center behind the crazy vault and lock and everything. We're moving into the cloud for scalability and, as David mentioned, for tools such as S3. So right now, we're in the pet stage, and the problem with pets is pets are awesome. You name them. You give them cute names like Grover. When they get sick, you nurse them back to health. You have a one-on-one relationship with your pet. Versus cattle, farmer has a whole bunch of them. If one gets sick, you take them back. And you shoot it, and you replace it with another one. So it's a horrible analogy. So I tried to come up with something that was a little bit nicer than shooting your cattle or getting rid of your pets. So I came up with this idea of raising kids versus raising rabbits. So these are my kids. Using the same analogy, the problem with kids is they have a long provisioning time. It takes nine months to make a kid. They're two boys, so they're in many ways Petrosa unique snowflakes in their own sense. And their uniqueness is what makes them special. So you want to get to the point where you could have more, but you want to preserve the snowflake-iness as well. So the problem of trying to expand too quickly is you end up in the rabbit stage where your video did that move. Anyway, this video is a cute video of there's this island in Japan that has rabbits running a rampant. And so that's where we don't want to get to. We don't want to have servers in the cloud to high-cost operation where we don't know what's going on in the servers. But at the same time, we want to be able to build them out as needed for flash sales, higher capacity for experimentation, things like that. But at the same time, we don't want boring clones. We don't just want to have one of the same server a thousand times. There's the video. OK. So right now, we're using a tool called Ansible. And we're using it on our physical servers now. Those of you from the Durham area, you're probably familiar with Ansible. Red Hat bought them a couple years back. So we have a lot of history with Ansible. We have a lot of playbooks that work great. Going back to the kid analogy, the way we run it now, it's kind of like the way of telling your kids one time to do something. How many people have kids that do something after you just tell them once? No hands. So it's great for doing it one time, fire and forget. But we're getting to the point where we're going to start building more and more machines. And so we're using a tool called Packer. Packer is great for you can build a machine for AWS, for Docker, for Vagrant, for various platforms. And we still use Ansible in a lot of ways for doing our provisioning. And we're familiar with it. We're used to it. So now we're getting into the rabbit level growth. We want to kind of rein it in a bit. So how do we make sure that we're not just building random machines that are all different from each other? So we start off by using a tool called Goss. Goss is a really neat tool in that it does the audit level of your image. So you can make sure that you have the right files in place, with the right permissions, with the contents in there. Using the kid analogy again, this is the like telling your kid, why did you do this? You need to do it this way. Don't ask why, just do it. And really, how many kids are going to do that as well? If you just tell them to do something, they're not going to do it. They want to know, why? Why should I do this? Why should I do that? So we switched to a tool called Inspec, which is by the folks at Chef. So even though it's a kind of a competing product with Ansible, they're nice tools to use independently of each other. So with Inspec, we kind of get the why story. Why did you tell me to do this? Well, because we want to make sure that we're turning off legacy TLS implementations across the board. The nice thing about this, if you see this URL at the bottom, there's a set of prepackaged Inspec rules that we can apply to our machines to help with PCI compliance, with security, and also repeatable. So we'll use these during our build process, but we can also go back and use these to audit against the servers we already have in place to make sure they haven't drifted out of compliance. So for example, the TLS is supposed to be turned off at the end of this month. We want to make sure that we have turned it off across the board. We haven't turned it back on as an exception somewhere. So this is the making sure that the kids don't go to mom and say, can I do this? And they say no, and then they go to dad, and dad says, okay, yeah, sure. Okay. The idea is that good neighbors respect one another's property. Farmers, for example, maintain their fences in order to keep their livestock from wandering onto neighboring farms. Came from Robert's Frost home mending wall. And so we're kind of using this idea as well. We're fencing things in by making sure that Packer can build our multiple images for multiple platforms. We're using Ansible to provision inside the images using the processes we've already established and we're using Inspec to make sure that we're not making unique snowflakes. I love talking about this stuff. So if you have any questions about this, we want to go into more detail, come grab me at the end of the conference or the rest of the day, and I'll be more than happy to talk to you or off about how to server provision. Thanks.