 All right, thanks everybody for coming. My name is John White. I'm the VP of Product Strategy at Expedient. And today I'm going to talk about building and operating a Swift S3 environment as a service provider. So to give you some context about who we are, Expedient is a service provider focused on cloud co-location and managed services. We operate our locations in seven different markets. We have a pretty big and heavy focus on network. That was where our background actually came from. So we actually have all of our data centers interconnected with 10 gig low latency fiber. We have cloud direct connects to AWS, Azure. So we sit in Equinex Pops that we can connect to pretty much anybody. And then we have a lot of public internet access coming into our data centers. The one important thing to note here is who we service and who our customers are. So we roll up and aggregate IT services for a lot of different companies. And they're focused on enterprise applications and enterprise architecture. So why that's important? Majority of these shops are actually on the pet side of the pets versus cattle analogy. So they're the ones that are actually building maybe 5 to 50 VMs that powers their whole environment, whether they're a software as a service company or they have some sort of maybe they're hosting health care, traditional IT applications, whatever it might be. Now these customers started coming to us and had a demand for object storage because we also had a demand for object storage inside of Expedient as well. One of the things that they came and asked for, and this might be something you hear inside of your world, is focused on archive data. They didn't want to actually put it to tape anymore. They wanted to have it online and running in disk. They wanted to have a lot more information about that data though. So they needed more enhanced metadata to actually figure out what they're doing with that data, how long they need to keep it, why they're keeping it, whether it's compliance or they just were afraid to delete it. They also wanted central file repositories. So a lot of people were running multiple web servers. They needed a place to put their PDFs, their video files, something like that. They needed a single point that they could then scale out their web servers as they were starting to move towards, a little bit more towards the cattle side of things. A lot of people just wanted to migrate a file server. They had terabytes sitting in file servers. They just wanted a place for it to go. They wanted that file server access still from it and they just needed to archive it that way. And a lot of people were asking for API interactions and they were asking for API interactions not really to program against but to then use traditional software that they had today and have it as an S3 repository. So a lot of people were running Commvault Veeam. They wanted to quickly extend that data store to from that application into an S3 object storage. On the expedient side, we saw this as an opportunity to go and roll out something with a programmable storage layer. We didn't want a lot of people to actually run and operate this. As we were going from gigabytes to terabytes to petabytes and our whole kind of evolution, we wanted to make sure there was something as it scales. We didn't really have to scale the people one to one. We could have a few people run this big platform. So what we created is what we call Evermore. And Evermore is just an object storage that's focused on being distributed, redundant and geographic diverse. The goal for this project was to keep it very, very low cost. So it was more for archive data. That's where we were focused on. So we wanted to have a lot of data available to either access via API or NAS gateway and then just to store that large amount of data. So what does it look like? Because I told you I'd give you the architecture. This is really what the product looks like. And these are all built out in three different markets. So you can see in Indianapolis, Cleveland and Boston, the user will actually come through multiple different protocols. So they can use S3, they can use Swift, they can hit it from their website to just store files that way. And they can also use it via SIFS-NFS. That's coming into evermore.expedient.com and that's something that's globally server load balanced. So it's gonna hit any one of those three markets to actually put the data or then go and get the data. So when you're actually going and doing the put of the data into the system, it's gonna land in Indianapolis, Cleveland or Boston. Once it lands inside of there, that whole file we're replicating across that 10 gig ring I mentioned across to those other sites. So what does this actually look like? In each one of these data centers, we design these pods, these object storage pods. And it's pretty simple. We're running Swift stack as our software. We're running a controller server and that controls a lot of the metadata. We have a proxy server in each one of these. Obviously we need some network switching. So we have dedicated switching to the stack. We have a storage server and a storage J-Bot and I'll go through each of these in detail. So the VM is pretty basic. It's actually gonna hold all of the understanding of what is inside of the metadata for all your objects. It's a basic VM. We actually have it just running inside of our hosted VM infrastructure inside of Expedient. Proxy server is pretty simple. It's a Dell PowerEdge R730 and all these slides will be up on YouTube so you can get all the specs of it. But it's a pretty basic server. We don't even back it up because it's something that if it breaks, we just go and we put another one in there, blast an image on it, we get it up and running. Storage server detail and this is where some of the magic starts to happen. Again, another basic R730. This is actually gonna process all the objects down to the disk. And then on the back end, we have just a big J-Bot. It's an MD3060E so there's 60 drives inside of here, four terabyte drives, near line SATA drives, near line SAS drives. It's big dumb storage. It really doesn't do much as the storage server above it actually handles all of the right requests and the re-request down to it. So the goal here was to go cheap and deep with this storage environment. The one thing that we really focused on when designing this and we balanced it out across a lot of different ways to do it because you can build this thing out a lot of different ways using regular servers and just filling it up with drives or going the J-Bot way. We focused a lot on the watts per gig. We wanted this to be very, very cheap and deep for our customers. We wanted this something to be cost effective to compete against some of the bigger players out there. And last but not least, we needed some switching. So we have a Juniper switch inside of the rack, non-redundant for the time being because there's multiple sites here. So why would I wanna do this? Why would you wanna do this? Why would anybody wanna do this? Well, there's some real cost benefits to be had here, whether you're a service provider or if you're actually an enterprise. Now, so I've created a little bit of a cost kind of breakdown here from the other big three providers that are out there and it's kind of hard to do. If you've ever done cost analysis on an object storage, you have to fill in a lot of stuff. And so I made some educated guests on get put requests, transfer out, that kind of deal. But if you take a look at really just that total solution cost number, so we sell this out to our customers at five cents a gig. So it's 500 bucks a month to run this and it's in a multi-site fashion. Same goes with Azure and Google. And Azure and Google orders of magnitude larger than expedient. We're only about $120 off a month. So if you're thinking about doing this inside of your environment, inside the enterprise, obviously it costs less than five cents to run this. We're a service provider, so we have to try to make some money somewhere. So you could actually do this inside of your own enterprise for actually cheaper than what you're seeing here. So there is a whole reason to have it local, but there's also some cost benefits here. Now I said I was gonna talk about the architecture as well as the operations running this. Really, operations is pretty easy on this. Swift Stack, definitely the software makes it easy. The hardware just kind of runs. It is in three different sites, so it's pretty easy to have change windows really any time of day because you always have two sites available if you take one down, which is nice. But we did learn some lessons along the way. We've been running this for about two and a half years now. We actually built this out initially using one gig network. Definitely build 10 gig networks now. It's a lot cheaper than when we were building it, but it also allows you to scale your environment to start using a racial coding, which is definitely a little bit more heavier on the network side. Create some tiers of disk. Your consumers will all say yes, they want cheap and deep, but I guarantee you then they're gonna come with you with another use case where they want some faster disk. We learned this lesson. So create some tiers to create the ability to handle a lot of different workloads. Using an API for storage is a lot easier said than done. A lot of people wanted this. A lot of people needed this. A lot of people demanded this. They had problems actually programming their applications to use the storage layer as an API. So what do they do? They start to use it as a file server. And this is something where I don't think object storage really lasts a long time as a file server. There's some parts about it that don't really work that well, that don't scale that well. The object storage is meant to be object storage, so that's what you should use it as. So if they want to use it as a file serve, make sure that's a short term solution and not a long term solution. So what can you do? There's a lot of free books that are out there. I read a lot when we were actually building this environment a few years ago. Swiftstack has some on their site that you can just download there, they're for free. I put one, I'll link over in here too to an IBM book that's pretty good. And then play with it. There's a lot of different ways you can play with object storage today. A lot of community editions out there. Swiftstack has one, Nuba has one that's pretty cool. Scality actually has one that if you're using Docker containers today, you can actually just go onto their Docker hub, download it there and get it up and running. So that's all I got for my 10 minutes of quick lightning talk here, appreciate the time. If you have any questions, love to keep it going after this or feel free to hit me up on Twitter, LinkedIn, email, whatever, glad to answer any questions you might have and help you along your way. Thank you.