 Okay. Hello everybody. I'm Allie. I lead the advanced storage team at Seagate, and we are going to talk to you a little bit today about Kinetic. Kinetic Drive was introduced yesterday. I have some big news this week. It's the first, the world's first Ethernet and key value hard drive has some really important big implications for all of us for storage and for total cost of ownership in storage. We're going to actually do what people say you're not supposed to do on stage. We're going to do a live demo. So Jim and Ignacio are going to come up in a minute. But first I'm going to take you through a little bit about what it is and why we're so focused on object storage. First, we did the press release yesterday announcing the drive. Also, really significant industry support coming along. Some of you may have heard we introduced the technology first a year ago, and that was really for the purpose of bringing the ecosystem along with us. We worked closely with Swiftstack, with Scality, lots of other partners, Ink Tank, Red Hat, because this is truly a fundamental leap forward in storage, and it requires not just that the devices are new, but also the software stacks and the systems. So we're really, this is an industry movement that's happening here, and we're really proud of how far it's come. So why are we so focused on object storage? Kinetic is all about object storage, and the reason is if you start with some pretty standard industry numbers about the zettabytes of data that are going to be created in the years to come, 44 zettabytes is a fairly common number, 40, 44 in the year 2020. And then further assume that about a third of that is probably valuable to companies if you can store it. So you're at 13.3 zettabytes. If you put 56% of that in the cloud, which is the forecast, you're at 7.3 zettabytes, and 90% of that is unstructured. It's object data. So six and a half zettabytes of data that wants to be stored if it could be. The problem is it wants to be stored, but it can't be, because with today's architectures, even commodity gear, there's a budget gap somewhere on the order of about $240 billion, even assuming dollars per gig declines as they have historically done. So we think that for all of us as an industry to realize the opportunity that sits in front of us, we need to totally rethink what the storage architectures look like. And to start with that, we have to start from the device, right? Because you need a different device if you want to do the rest of it differently. So just a very simple picture of what most storage architectures look like today. You have object storage applications at the top. They are forced because of the way the stack works to sit on top of file systems that are today for these use cases, mostly overhead. And then they sit, they talk to storage servers in Iraq, and then ultimately to devices which are tethered by SAS cables, because that's the only way you can connect to a device today. But what's true is that this architecture, and especially these middle layers, were designed for very different use cases, in some cases as much as several decades ago. And we think that today, these applications are just trying to put objects and get objects, predominantly. And yet they're going through all these layers of kind of machinations to get to blocks and sectors and then do the same in reverse. And it's inefficient from a software perspective and it's very costly from a hardware perspective. So Kinetic breaks that paradigm and lets those object storage applications talk directly to devices as first class participants on the network over Ethernet, standard Ethernet. And the way we do that is two key things. So the device is still a traditional three and a half inch standard form factor device. It now speaks Ethernet instead of speaking SAS. So we've added a little chip to the device. That chip does two important things. It speaks Ethernet and it does the space management on the device. We've also added a key value interface. This is really important. The combination of those two things let us eliminate the file system and the storage server. So what used to be two tiered systems in all cases, whether it's Swift, SAF, Scality, any of these object storage systems can now be a single tier. So now the picture looks like those object storage applications at the top, they communicate to devices through open source tools that we've provided and that are now community projects. Open source API, Kinetic is fully available under the LGPL as are a series of libraries that are designed to let the API be easily implemented and integrated into software stacks. Runs today in Swift, runs today in Scality. We're going to show you Swift in a little bit as well as SAF, Bashow, React, HDFS, a number of other applications. And you talk directly over Ethernet over the open source API to devices that are attached anywhere on the network. Yesterday what we announced is a 4TB hard drive, that one sitting right there. We're also going to show you a cool technology preview of an SSD. It's designed to be the first in a class of devices from both Seagate and any other device manufacturers and across tiers of storage. What people need is an object storage protocol that enables total disaggregation of storage from compute and that has really important benefits that go along with it. Principally TCO, so when you pull those storage servers out of the rack, right, because you now have devices attached to Ethernet, you can eliminate a lot of CAPEX, you lower the power of the overall system, you lower the human costs of managing those systems because you've removed this higher order failure domain from the racks, right? So if a server goes down, it's no problem. There's another server somewhere else that can fire up and talk to those devices. And if a device goes down, no problem, that data is erasure coded or replicated and can be easily recovered. So, OPEX is a big impact. Performance also benefits. Many of the use cases we see in object storage is people trying to kind of fill the can as fast as possible. And the servers end up being a bottleneck, especially as people get more and more efficient stacking tons of devices behind servers and optimizing those servers, suddenly it's a bottleneck. Now instead of having that bottleneck, you can gang up a series of devices across Ethernet and really open some of those choke points. In some cases, we're seeing as much as 4X the performance. And on the TCO side, lots of data points, I'll talk to a couple in a minute, but anywhere from 30, 40, 50%, up to 75 or 100% in some cases. Rack density also improves for people who are space constrained, pull out all those object storage servers and put in more storage, right? So that's another important benefit. And then finally, device innovation. Many of you are probably familiar with some of the industry transitions that have been painful in the past. Device level innovation that needs to happen for things like improving aerial density. Those are hard because host systems need to accommodate them. They need to adapt and change file systems and so forth. Shingled magnetic recording is the next one that's coming. We need to do that to get you guys 20 terabyte drives in the future. But it's going to be hard because all the host systems are going to need to change. With Kinetic, we've changed the level of abstraction to the device. So now the application is just putting in getting objects and we worry about the space management. And therefore, we've broken that tight coupling, and we can innovate at the pace that we need to. You guys, the host systems can innovate at the pace the system wants to innovate. And those two things can happen independently. So architecturally, much more agile and flexible. So one case study I want to showcase is kind of indicative of how these customer conversations have been going. As I mentioned, we introduced the technology first a year ago. We have been working long in advance of announcing the drives yesterday with customers and partners. This is an example of a case study that we did with our partner Swiftstack. And this is indicative of the customer conversation. So remember, this is all about scale out object storage. So people are not coming and saying, run Iometer and show me your absolute highest benchmark workload. What they're saying is, my performance requirement is X. In this case, it's 50 megabytes a second. So show me that you can deliver me that performance and then tell me what the cost is going to be. So in this case, the customer said my performance is 50 megabytes a second. My networking infrastructure is actually one gig. So I have an upper bound of 120. Show me that you can meet that. We tested four different configurations, even in the worst case with very, very small object sizes, which is not very practical. We meet their performance requirement. In all the other cases, we actually exceed their networking requirements. So they checked that box and they said, OK, this is interesting. Now tell me about the TCO. And it turns out that in this particular case, the impact is maybe as much as 36%. And remind you, this is not against traditional OEM gear. This is against Swift on commodity systems. So the fact in this customer's case, what they want to do now is say, I can store 36% more data. It's a life sciences company. They know exactly what to do with that data. And now they have the opportunity to get a lot more out of their environment using Kinetic. So I'm going to turn it over to Jim Ignacio. We're going to show you a quick view of performance. It's supposed to be the demo theater. We're going to actually do a demo. And we're going to show you a tech preview. This is not a product announcement, but we do think and we hear from customers repeatedly that there's absolutely a need for this technology and this protocol to span tiers. So we're going to show you an SSD in action. And then we're going to tie into our cluster in Longmont, Colorado, and show you Kinetic working with Swift. Good evening. My name is Jim Hughes, and I'm going to give you a live demonstration. And everybody knows how well live demonstrations go. There are always surprises. What I have down here in this little... Oh, sorry. This is something we call a developer kit, which is a little device that has four disk drives in it, 16 terabytes. You plug it into your office computer, your office LAN, and it gets a DHCP and brings up four devices. What I have down here on the floor is one of those devices. It's getting DHCP from a little Apple airport and it has three hard drives and one Kinetic flash drive. This is the tech preview. This is a very low performance flash implementation. We're using the same processor on this as we use on the hard drive, so we don't expect a lot of performance. And it has a flash drive and a lot of metal. And we're going to demonstrate the difference between those two. So let me bring up the... So what we have is the system level performance. This is one disk drive, another disk drive, and these are two other disk drives. So there's four disk drives. So what we're going to demonstrate is random write performance, random write performance. And we're able to turn around and say, OK, now we have about 60 megabytes per second, 50 to 60 megabytes per second going into that one disk drive. And that's using keys and values. This is not sector level writing. This isn't actually writing at the lowest level. This is writing as if it was in a file system. And down here I can start another drive and now we're getting around, well, a total system performance of about 110 megabytes per second. 110 megabytes per second is the capacity of this Ethernet cable. And that's only two of the four drives being pushed. And this is random write workload, not sequential write workload. This is random write workload, which is a pretty impressive feat as far as I'm concerned. And now we can stop this and we can turn around and say, OK, we want random read performance. OK. And let's go ahead and random read performance. And in this case, this is actually reading the data that was just written and being able to show, again, around 95 to 100 megabytes per second reading this data back. And I'm going to continue to go ahead and stop this. We can write very small blocks, random writes of 10 bytes. What's interesting is the device itself is log structured. So as data flows in, it's immediately streamed to the disk. This means that we get very, very high random write performance. So this is showing about 1,010 byte records. We are randomly writing 10 bytes. We're getting about 1,000 per second and 1,000 per second for a total of 2,200 key value operations per second. Now, that's just streaming the data to the disk. The hardest thing to do, the hardest thing to do on a disk drive is to read random data. So these are two devices. This is two devices. One device is a standard four terabyte disk drive. And the other is the flash device. This is just a 300, a 240 gigabyte flash device, but with the kinetic API. So we're able to read random read 10 bytes from the hard drive and random read 10 bytes from the flash drive. So the hard drive, the flash drive, we'll start, we're getting around 500 key value operations per second. And these drives are just powered up. There's nothing in RAM. There's no caching. And then we can run the same test on the normal disk drive. And the normal disk drive, you can expect, it's a disk drive. It's got an arm. So we're in here in the 40, 50 range. And up there, we're in about the 500 range. We fully expect that we'll have some very much higher performance processors on future flash devices. And that's my demonstration. And it worked. Now it's my turn. I'm going to show you guys a little bit about Swift running with kinetic drives underneath it. Swift has evolved a little bit since the initial inception of the kinetic drives were actually now down to the second generation, second iteration of the Swift code. What we done before I actually show you the code running is we created this concept of proxy object bypass, which allows the proxy server to detect the fact that there's an object server that we need to talk to that happens to be running locally in the same box. And instead of actually going through the HTTP and the whole target and the whiskey interface from the proxy to the object server, which is what Swift traditionally does, we actually bypass the code and call directly inside the Python of the proxy server the code for the object server. That actually gives us much higher throughputs and much lower latency on the operations. There we go. We have slides for that. Awesome. So in the case of the kinetic Swift configurations, the deployments are usually looking at what is called actually Swift apaco, which is a proxy that can only contain on the object server running on the same box. And if you have 10 servers, all the 10 servers are running pagos independently. And the other cool thing about the kinetic servers, like even if you have 180 drives, if you have 1,000 drives or 20,000 drives, each single pago can actually talk to all the drives regardless. It's not like you have one server for 10 drives, another server for another 10 drives. Now, four fingers, awesome. Now I'm going to show you the system running. So top left, what I have is the hdab of one of our servers running in Colorado. It has two chipsets, 12 cores each. So we have 24 cores up there. And now what I'm going to do from another couple of servers is actually exercise the server directly through the Swift interface. And I don't want to remember the thing. There we go. So in that case, it's just one guy. And what I'm showing there is, again, Python is a single process. So on one single thread on Python, that server is putting about 280 megabytes per second into the cluster. And the gigabytes on the other side is actually what's happening on the back of that. After replication towards the drive. So we can see that it's actually outputting to the drives 6.8 gigabytes per second. Now I'm going to launch a second guy from the same machine into the same server. And the aggregate between the two wants to stabilize this a little bit. In this case, from that single machine, it's somewhere on the neighborhood of like 300, 400 megabytes per second in, which is like eight gigabytes per second out. And now what we're going to do is actually start a third guy from another server. Again, against the same pack. And we can see between the three guys, we're looking at anywhere in between. That guy's doing 5.3, 4.2, and 3.3. So let's average to like 14 gigabytes per second coming out of that proxy server into the drive mesh. And in this case, the pack was completely maxed out in terms of CPU. So with those chips, the max thing we can do is about 14 gigabytes per second on the back. And mind you, the server actually only has 20 gigabytes max anyway. The other cool thing is actually the server is connected to 180 drives. So actually the drive mesh, it's operating on a fairly low capacity, about 30% of the total drive capacity is being exercised by this single pack, but it can actually drive almost a 20 gig interface from a single server. So let me close those guys up. The other cool thing is the configuration. And in the case of kinetic deployment, it's actually fairly simple. You create the object rings. And basically, you tell each of the proxy servers, well, each of the object servers that you will configure one per computer or per server that he can talk to every single drive in your infrastructure and off you go. Now you basically do the load balancing at the proxy level. And all your requests can go to any single proxy and from the proxy directly to the drive. There's no extra component in there. Jim? Thank you. Thanks. You're not, Joe. Thank you, Jim. So real live demo, it's working. The key thing there is obviously you saw some performance data. In all the customer cases, what we're seeing is what I described before, which is, OK, oh, that's interesting performance. I see that I'm getting what I need. Now talk to me about the cost. And TCO is really the story here. So we encourage everybody to come see the booth in D11, hear more about it, talk about your specific needs, and then also lots of tools available at developers.seagate.com. There's a fully functional drive simulator there. It'll point you to where to get on GitHub all of the code, which is, again, all open source. And please get involved and come see us to learn more. Thank you very much.