 So let's go ahead and get started with our spotlights this morning. Shutterstock is a company that if you work in the creative industry, you're probably familiar with it. And I'm very excited to have the VP of Technology Operations at Shutterstock here to talk with us today. So please help me welcome Chris Fisher. Morning, everybody. So a quick show of hands. How many folks in the audience are familiar with what Shutterstock does and what the business is? Great. So a fair amount of you. For those of you who aren't familiar, Shutterstock is a marketplace where photographers, videographers can upload their content. And we provide an opportunity for them to be able to sell that content to a broader market segment, people who need stock artwork for creating Christmas cards or a PowerPoint presentation or doing something like creating a catalog. Before we kind of get into that a lot, I want to talk a bit about what OpenStack is doing for our business. And I'll give you a little bit of a brief background in myself as well as Shutterstock's founding beginnings. So first, a little bit about me. I've been building scalable systems for about 10 years, as well as the teams that are responsible with managing those systems. From the get go, I've always been someone that's been really interested in high levels of automation and being able to build a very strong operational organization that can add business impact, not just manage your environment. I'm a huge, huge open source enthusiast. I mean, there are very few times that you can get me to buy a black box solution unless it's really, really exceptional. And that comes from a real belief that if things really get tough, you can control your own fate, get into the source code, figure out what's going wrong, and really solve your own problems. One other key point is that I have a pretty deep systems and network engineering background. I'm an ops guy by trade. The only language that I've coded effectively in is C, which is pretty much irrelevant in a modern web company. But I'm going to talk a lot about building the type of stack that your developers want to interact with. I really believe in it. It's done great things at other companies I've been at and at Shutterstock. And effectively, I think that's one of the key cornerstones of why OpenStack is something that's super effective for us. As a quick aside, I now spend most of my time, it seems like, learning how to use Excel and PowerPoint, and trying to explain to the rest of the executives and people out in the industry why these cloud systems are so important and so efficient. So a little bit on Shutterstock's founding beginnings. We were founded in 2003 by our CEO, John Oringer. He was our first developer, which from the beginning really created a dev-centric organization. It's pretty cool. It's from inception to our IPO last October and beyond. We've remained very focused on creating a great, great technology platform that developers really like interacting with. Our tech stack is another kind of note. Pre-dates the modern cloud. AWS was launched in 2006, maybe, I believe. And effectively, a lot of the modern technologies for building a cloud or interacting with the cloud just weren't there when we were already handling pretty large volumes of traffic. So a lot of the needs that we have are solved by OpenStack that provide us an environment that we can create a super usable cloud for developers, but at the same point help us alleviate certain constraints that come from having an application that's been around since pre-cloud days. So inside our organization, we have this developer ethos. And this isn't it. I wish it was this simple. But if you read through that document, you'll find that there are a couple of key themes that just happen over and over again. One, we build things that are core to our business. A lot of organizations really focus on the product. And I think that's fantastic. But we really ask ourselves if this functionality is core to our business, orchestration or deployment or the ability to speed development, we want to be building that. We don't want to buy an off the shelf solution. Secondly, we want to stay open source. Again, I kind of talked a little bit about when things get rough, it's nice to be able to read the source code. But beyond that, there are great recruiting efforts and great capabilities that come out of using community supported software. It's just something I believe so much in. And it's treated us really, really well at Shutterstock so far. Three, we want to invest in things that create collaboration and innovation among all the individuals at our organization. People don't talk a lot about how much tooling or your platform is important in that. It's really easy to think about process or being agile or having can band style type groups to really help foster collaboration and innovation. But if you get inside a lot of developers' heads, they think about collaboration and innovation via pull requests or working within a technology framework, everyone being able to write and read code. And this is another one of the key points why OpenStack is pretty great for our environment. And fourth, I think there's a lot of people out here who probably agree with this, just automate everything. If it's something you don't need a human to do it, don't. You'll find something better for that human to be doing other than sitting there and running scripts recurrently at midnight every night. So a little bit about the platform. It seems pretty easy to upload and download photos and videos, but it is a pretty large system that we've created at Shutterstock. It's got thousands of nodes across multiple data centers. We're managing several petabytes worth of storage in an open source technology called MogulFS, which is backed by all kinds of heterogeneous disc from white box servers to appliances that we buy from a company called Co-RAID using ATA over Ethernet. We also collect over a terabyte of logs every single day. That's about 70 times the volume that the Hubble telescope downloads to Earth. I realize it was put in space 15 years ago, and it's in geosynchronous orbit. But still, I like that stat a lot. And on the Ops side, as well as the Dev side, we remain being pretty language agnostic. We code in multiple different languages. The key takeaway from our application stack is we really try to go fast. We're pushing code hundreds of times a week, and we needed the type of platform that was going to allow us to do this and get lots of dev interaction. So a couple of challenges. We were trying to work with creating an environment that worked in low latencies. AWS, you can have pretty high latency between nodes. OpenStack, being able to create a cloud environment where things are sitting right next to each other, we could kind of conquer a lot of network latency problems. We also wanted to create an environment where the culture and the workflow of both operations teams and dev teams really was identical. Read the code, the documentation is the code, and interact with each other in a way that developers really understand. The goals, of course, are the same as many of you guys have. Have it, be resilient. And the other ones that we care about is keep it dev-centric, create an API-driven platform, and work as much as you can with being open source. So this is where everyone kind of screams like dev ops. Oh, dev ops is the way to do this. And I disagree. I think dev ops is a great idea. But when you have a singular dev ops team, you've just moved responsibility to another group of people that can also write some code. What we really want is a platform that creates a culture and a workflow where everybody, effectively, plays that role of dev ops. We want our developers, as well as our operations folks, writing code, sharing code, sharing knowledge, whether it's application or the actual infrastructure platform. So ultimately, what these things kind of create for your business is an environment where you have a super, super strong staff. Everyone can contribute back to the org. Everyone can write applications. Everyone is able to triage the same, communicate the same. We go crazy collecting metadata from all of these instances to look at efficiencies and resource planning within the groups. And it's a really powerful system where you can get everyone really working with the same platform, application side and dev side. So that's effectively, on this slide, when we really looked at what platform was going to help us do this the most successfully, we went throughout of OpenStack. It has great community support. We have the ability to get in the code and get 30. Everyone's building against an API, as opposed to looking at using config management systems like Puppet and Chef. That may be a part of your environment. But building against an API is something that developers are going to embrace a lot more. Everyone can read the code. And effectively, it encourages both ephemeral use and things that don't have persistent data, as well as allowing you to integrate with systems that do have persistent data. So thanks. If everyone has any quick questions for me, you can tweet stuff at me or send me an email. It's just chris at shudderstock.com. And thank you very much. Thank you, Chris. So don't leave yet. So when we've talked, one of the things that I found really interesting is you're obviously a technologist, and you were throwing out some great stats about the kind of environment you're running. But the thing that really hit me when we talked before was you have a business need, which is you have this application that has specific requirements that maybe don't fit into a menu-driven type technology offering. But you have developers who are developers, and they want to have an agile environment to work in. And so how does OpenStack allow you to meet both of those needs in your business? Absolutely. So one of the key points that's been OpenStack so successful for us is that at first, we thought we could solve this with just config management. We laid down a big puppet tree and tried to teach all the developers how to work with a DSL or in a right scripts to interact with controlling their environment. And it had some good success, but really, they kind of hated it. They were like, I just want an API to do this thing. And so effectively, as we've been transitioning our provisioning systems over to using OpenStack, we're able to get everyone to really be excited about, I can just write code that's going to call the OpenStack's API, interact with it, provision my VMs, do all this work that before they had to do in a language that was a little foreign to them. It didn't make a lot of sense. And at the same time, we keep our ops team very happy and that we know a lot about what the metal's doing. It's not completely abstracted into a way that we feel we're losing control. And so it's really helped bring those groups together in just a common language via being API driven. So it lets you keep your application happy, your ops team happy, and your dev team happy. Correct. All right, well, thank you very much, Chris. Thanks. So Shutterstock is focused on the needs of creative types and including individual creatives. The next user we're going to bring up is the