 OK, let's start. So thanks, everyone, for attending this session. I'm Denis Janot, so I'm principal system engineer and field CTO at Dell EMC covering elastic cloud storage, ECS for the Europe, Middle Eastern Africa. I'm working at Dell EMC since 2007 and on object storage since 2010. So I started with Atmos, which was our previous platform. And now I'm working mainly on ECS. I develop applications. I like to develop applications a lot. And I do that for generally to promote why object storage makes a lot of sense for people. And I like to share that on my GitHub. So take a look if you are interested. I do a demo at the end on one app that I developed. And I put the source code there as well. So feel free to check out. I also use Cloud Foundry for many years. I really like it for one reason, is that you have to build your code correctly. You cannot build your software in the wrong way if you want to use Cloud Foundry. And that's really what I like a lot on Cloud Foundry. You'll find also my contact details there, even my blog that also run on Cloud Foundry. So that's just a side thing. So the agenda will go through what is typical application deployments. What are the different options that developers have when they want to store and structure content that they need to manage in their application. We then go through why object storage makes sense. We'll speak about why it makes even more sense when we speak about pass and Linux container. So obviously here, more about Cloud Foundry. I will speak also a little bit about the way I think people can simplify the steps to modernize applications. And I'll speak about some other benefits that I didn't highlight in the previous slides. And as I said, I will end with a demo. So first of all, if you want to deploy your application and let's say in a virtual machine or in a physical server, and you need to store some unstructured content, some PDFs, some pictures, one very simple way to do that is simply to store your unstructured content in the VM itself, in the VMDK. For example, if you use a VMware VM, that sounds kind of weird. But I can tell you that many, many people are still doing that. I have even an example of one bank I'm working with where they have around 5,000 applications that are deployed like that. So it can be only 500 gigabyte here, 1 terabyte there. At the end, it's two or three petabytes of very expensive block storage. And the other challenge, obviously, is that you have no HA, because the data can be accessed only by this VM. So it's quite expensive, and it doesn't provide any scalability, any high availability. The second option that doesn't look very good as well is to use a database. Again, I can tell you, I see a lot of real-world examples where customers are doing that, and even sometimes with a lot of data. And obviously, here, you get a little bit of high availability. You can have several instances accessing the same data. But it's even more expensive, because now you add the cost of your database software. And backing up a database is also something very complex. One example of this deployment is, for example, SharePoint. You have a lot of customers who have deployed initially SharePoint, where they were storing all these documents in a SQL database. And then they were, at that time, I was working on the backup sites of the company. And they were coming to me and saying, I don't understand why I cannot backup this 5 terabytes SQL instance. And I was telling them, OK, why do you put like 5 terabytes of PDF in the database? So obviously, they are not best practices, but this is something we still see today. But the main behavior is really to use an ass, to say, OK, I want to be able to scale a little bit more. I want to have several instances accessing the same data. So why not using just NFS Share? And that sounds like a good idea, especially if you come from the two other solutions. But if you think about it, it's not that good. First of all, the first thing will happen is that the application team will come to the infrastructure team and say, I want some storage because I want to run my application that way. And the first question from the infrastructure team would be, OK, that's fine. So how much storage do you want? It sounds like a very normal question because you are the infrastructure team, and you need to provide storage to this application team. But the application team has no idea. They don't know if the application will be successful. They don't know if they need one terabyte, two terabyte, 10 terabytes. At the end, if they guess they need one, they will ask for two. So it's a lot of waste. Everyone provisioning more storage. And for the developer, it's also very complex. If I want to store 100 million PDF or pictures, I will not put all of them in one directory. I have to think about the directory structure and what is the best directory structure based on the technology of the NAS I want to use because some NAS parts will work better if you put the directory that way or that way. So it can become a very painful process. Then you have to manage hackers, and you have a lot of other complex things to do, like making sure that your share is mounted, making sure that you have space available. So a lot of painful operations on the developer side. Let's say now my application is successful and I need more storage. At a certain point in time, probably the infrastructure team will tell me that I cannot extend my share anymore, and I need to have a second share. That sounds like a very simple and good solution for the infrastructure team. But for the developer, it's like, how can I manage two shares? How can I know where I need to write? Should I write here or there? Oh, you can check the capacity. OK, that's fine. So every time I will do a write on my application, I will check the capacity. Do you think it will scale? Do you think it will get to reference? No. So as a developer, I will have to now implement a background process that will check the capacity of my two shares, report that somewhere in a way that my application knows where to write. So imagine how complex it is. And that's only the beginning, because you see here I have more and more web servers from here to there. But now if I have more and more users and I start to have people using tablets, I start to have sensors, and so on, then I have the needs to deploy more and more web servers, a lot more web servers. And the reason for that is that every time I want to upload a photo, every time I want to upload a PDF, I need to send that document to this application server. And this application server needs to store that document in the NAS. Every time I want to display my pictures, I need to do the same, read from the NAS on the application server side, and send that to the web browser. Makes sense? Very expensive. A lot of infrastructure that is needed for that purpose. Now if you use Object Storage instead, you can develop your application in a way that every time you want to upload a picture, the web browser will ask the application server for a signature that will be valid for a minute, and that will use this signature to send the picture directly to the Object Storage platform. That means that now my web application server is not in the data pass anymore. And the same when I want to display some picture that are stored on the Object Storage platform, I can request a signature just to be able to display that for a certain period of time. So now I need a lot less infrastructure. And I will illustrate that with the demo I will do at the end. So if it's not clear yet, no worries. It will become clear. I hope when we do the demo. Now we see all the changes when you use file. That's fine. But if you now want to deploy your application in a pass, like Cloud Foundry or in Kubernetes or any other Docker orchestration layer, then you have additional challenges, because it was not a NOS. You didn't have a NOS challenges. Now you introduce new challenges. So it's not that before I had to mount my share in my VMs where my application was running. And perhaps I had like 10 VMs. And I was going to my NAS device and say, OK, I want to allow these 10 IP addresses. But now it can run in any of the cells of your Cloud Foundry infrastructure. So it means that you have to put all the IP range, basically, where your cell can be where you have a cell. And that becomes very insecure. And it's only the beginning. We could go deep dive and just spend 15 minutes in this topic, because you have to provide your own UID. So are you trust that you provide this UID or not another? You have some good work done on the volume services. But even with a lot of efforts, you'll never go to something that will be 100% secure. And you'll always have this ability for someone to hack that system and to be able to access your data. So you still have all the challenges we spoke before. You still are in the data pass. You still have to manage your file system. You still have to manage the fact that you can have two shares. But now, you also introduce another issue, which is the security. So that's what I described that one. Again, even if you go to the volume services GitHub repository, you will see a lot of warnings telling you that in many ways, you could have some security issues. If you are a developer and you understand all these problems and you don't have object storage, in your company, they don't provide you object storage, what can you do? The only thing you will do probably is just use under SQL database. Why not? Now, I don't have this security problem anymore. I can start my Cloud Fundry instance, my app. And I will get the environment variables. I will get through the environment variables all my user and password I need for my database. And I'll be able to just use a GDB SQL and store my pictures there. That sounds like a good plan. But a NoSQL database is clearly not designed for that. It has been designed to store a lot of XML documents and to do some very smart things with these documents. When you store data in these NoSQL databases, you have generally to protect them with two or three copies. So when we speak about scale and you want to store hundreds of terabytes of unstructured contents, that means that you need two or three times, generally, this capacity. So that's another challenge. And you have not solved the problem of being in a data pass. You cannot expect a web browser to send a GDB SQL to your database that is in your data center. It will never work. I understand that some people are doing that because if you don't have any object storage platform in your company, you don't have any other option. That's probably the worst bad option. But that doesn't mean it's a good option. Now, I have also a lot of discussion with customers who tell me that they want to modernize applications. For a long time, I was thinking that the biggest opportunity for us on the object storage side was people developing new applications. But I see more and more opportunities where customers explain us that they have challenges with their existing applications and they want to modernize them. And I think that I see now more opportunities that way than people developing just full, fresh, new applications. And here, if you have this monolithic application that is running in VMs and you have many different services inside these monolithic applications, it can be the service that helps you to manage pictures. But it can be also the service that helps you to manage the users. Obviously, you don't have the same challenges. I describe the challenges when you want to upload tons of pictures and that you need all these resources for that. But managing a lot of users is not a big deal. I mean, you can have one instance, we'll be able to scale and manage a lot of users without any problem. So what you want is that you want to focus on modernizing the part of your application that is causing a problem. And in this case, we can speak about the picture, upload, and download, for example. So if you want to modernize your application by extracting this service and running this service as a microservice in Cloud Foundry, for example, then what is the first thing you need to do? In my opinion, the first thing you need to do is to start by modifying the application to use object storage. Don't start to do anything going new services or things like that. First of all, just make sure that instead of using file, you can now use object storage. Don't change anything on your application apart from that. And when you are at that stage, everything becomes a lot easier because I can now extract some of these services. As I said, for example, the picture service. And I can now run it in a Cloud Foundry environment. And I get all the benefits that I discussed before. I am not in a data pass, so I can modernize the way I interact with my clients, the way the clients are sending data through the application layer, instead of sending the full data just asking for a signature, and then sending the data directly to the object storage platform, and so on. OK? In the ideal world, you would migrate all these services, and you would have everything running as microservices. But I don't think it will happen that often. I am pretty sure, and that's what I see when I discuss with many different customers, that we will be, in that case, very often, where you will still have a kind of monolithic application, part of your application that will be monolithic, and then some microservices around it. And I was just before in this Kubo session. And I think it's kind of a good fit for that, where you can run your still monolithic part of the application on Kubernetes and run your modern, scalable microservices on the traditional past site. And this is just some of the benefits that you get from object storage. You get a lot more. For example, if you deploy an object storage platform while you use Cloud Foundry, you can use it as a blob store to store your apps, to store your build packs, and so on. If you want to provide, if you have consumers in different countries, let's say in Switzerland and the United States, and you use a traditional file approach, even if you deploy Cloud Foundry in Switzerland and Cloud Foundry in the US, you can still access your data only in one of the country. So it will not help. Now, if you are using object storage instead of using traditional file storage, you get an active, active access. Most of the platforms, not all the object storage platform are doing that, but I would say most of them. And in that case, I can have the instances running in the US accessing the object storage platform that is located there. And at the same time, the instances running in Switzerland accessing the same data that is replicated there. As I said, you don't need to provision storage. We spoke about the challenge where the application team needs to tell the infrastructure team how much storage they want. This is something that you don't do with object storage. Obviously, you will probably continue to discuss a little bit, because if the project involves 10 petabytes of data in the next year, probably you want the infrastructure team to be aware of it. But you don't need to be very precise and say, I want exactly that amount of storage and I want to have some provisioning on it. You just share the same platform and you just make sure that people don't abuse by doing this kind of charge back or internal billing so that everyone kind of pay for what they use. Also, the ACL management is a lot simpler with object storage. And I always use this anecdote where I discussed with a police department and they came to us and say, we really think we need object storage for storing all our evidences. And we discussed about the benefits and like all the things I just discussed before. And they came with something else that was very interesting. They say, you know, one of our challenges is also that when a policeman in one district is working in something and needs to access some evidences that are stored in a NAS in another district, then it looks simple. The other policeman in this district that owns this data will just right click on the directory and say, I give access to that policeman. But after he does that, it can take hours before hackers are propagated on the subdirectories and files and so on. And we speak about police department. I mean, they don't want to wait hours to access to these evidences. And with object storage, you get something like called bucket policy where you can just say, I want to give access, read only, for all the files that start by that prefix. And this is something you store in the bucket. That means that you don't have to propagate that rights. At the object level, this is a bucket metadata. Again, it's not supported by all the object storage system, but it's quite common, quite popular. If you want to store your data for, let's say, let's keep the example of the evidences. If I want to store my evidences for 10 years and I want to make sure that nobody will delete that data because it's very important and sensitive information, then the best thing you can do with object storage is just apply retention. Just say, I want to apply retention of 10 years on my storage system. So if I receive a delete request on that object before these 10 years, I would just reject it. So even if there is a bug in my application or someone tried to delete the data, you cannot. It's just completely enforced by the storage platform. But now, what happens generally that you want to keep the evidences for 10 years, but in the law of your country, generally it tells us well that you should not keep it for more than 10 years. Because there is no reason if someone made a mistake in the past, he has paid for it, and you should not keep information about it anymore. And if you look at GDPR, I'm sure that everyone speak about GDPR in your organization, they really want to enforce all these things. And one of the good things you have with object storage as well is something we call bucket lifecycle policy, where you can say, I want to automatically delete the data after this period of time. So you can combine everything together and say, I will keep my data under retention for 10 years. And after 10 years and one day, I will get rid of it. So we get really the benefits of protecting the data and the benefits of making sure that you respect all these GDPR requirements and so on. Obviously, when you store all these evidences, let's keep this example, because it's something that everyone can understand very easily. If I store all these evidences, generally, if I organize these evidences in a file system, I can say, let's say I will have a directory called district1, and then I will have the case number. Easy. If someone wants to search for this case number, it goes under district1, and you find the case number. But now, if I don't know which district was involved in this case, I have to go through all the district's directories one by one until I find the number. And perhaps I want to look for data not based on the case number, but perhaps I want to know based on the date. Or perhaps I want to know based on something else. And I cannot organize my data in different structure. I have to choose one file structure, and that's it. With object storage, you can store some metadata with the object themselves. And in ECS, we also provide the ability to do some search on that. So you can say, give me all the evidences that concern issues that happen in that specific region of that country, for example. And I'll do a demo of that as well, so you will see that in practice. And finally, you have all this data, all this unstructured content, and you want to extract some value from it. And many customers are evaluating different solutions, generally based on Hadoop, or Spark, or other technologies like that. And the only solution you have, generally, is that you take all your data sets, and you copy that data set to a Hadoop cluster. And then in this Hadoop cluster, you analyze your data. And it can take more time to just copy the data compared to analyzing this data. With ECS, we also provide this ability so that you access the same data that you have stored with DS3PI on object storage. You can access it with HDFS and run some analytics on big data queries on that. OK. So I'll do a quick demo so that you can see that in practice. So I just started my app here in Pivotal Cloud Foundry, so you see it's a very, very highly consuming application where currently I'm using 10 megabytes of memory. And I have only one instance. And I am using an ECS system, which is based in the US. You can register as free, so you can go portal.ecssdrive.com if you want to play with the APIs. It's completely free. So here I will have my application running in Pivotal Cloud Foundry and Pivotal Web Services. And I will have the picture stored in ECS in our own data centers in the EMC. So the first thing I will do is that I will take the picture that I have just selected the picture I just taken before when we started the session. And what you can see is that from this picture, I have extracted some metadata. You see here the size of the file, but you see also the width, the height, the latitude, and longitude, which is the one of buzzer if my phone is still working well. And what I will do now is that I will upload that file to my Object Storage Platform. And what I want to demonstrate is that my application server is not in a data pass. So in a traditional model, what I should see on the right, where I can track the network calls here, what I should see is that normally the request should go to my application server, which is ecspix.ecssdrive.com. And that application server should write data to my storage platform. But in that case, I want to demonstrate that that application server is not in a data pass. So what I should see is that my web browser should directly send the request to ecspix.ecssdrive.com, which is my ECS. So when I will click on Upload File, it will send a request to the web server just to get a signature like this here that has been computed by my application server to let my web browser uploading the data directly to ECS. And if I look at the network request here, you see that I did a put request on this bucket.public.ecssdrive.com. So you see my application is not in a data pass. I really directly sent that object to the ECS platform. Now if I want to see what I have in my bucket and I click on Search, I get the content of my bucket. What I forgot to tell you is that in pivotal web services, you see that this application is not bound to any service. There is no database involved at all. It's completely stateless. I just ask my object storage platform, give me the object that have been stored. And at the same time, it gives me all the metadata of these objects. And part of this metadata, I have the latitude and longitude. So I can now very easily use Google Maps to display them there. And if I'm not so bad on geography, which I am normally, then I can try to find a picture that has been taken in Switzerland, where we are now. And if I just click on that button, what it does now is that it does a metadata search, telling I want to see all the pictures that have been stored with the metadata where the latitude is between that and that and the longitude between that and that. And that gives me a picture that if we are lucky, should be you guys. And what you see here as well is that the URL is the one that is directly from the ECS system in the US. So again, even when I get my data from the storage, I don't have to go through the application server, because this application server is not a database. So I mean that I can now manage thousands of requests per second with one instance. Perhaps I will need more than 10 megabytes. Perhaps I will run two or three instances to have some HA. But I could definitely run 1,000 or more requests per second with just like, I don't know, 100, 200 megabytes of memory on Cloud Foundry. That's it. But now I'm not protected yet. If I just decide to delete that picture, we are gone. We lost that picture. If I go back and try to upload that picture again, but now I apply retention, I say, this is an important picture. I want to keep it for one day. Nobody can touch it, can delete it. And I upload my picture again. Then I can search for it. But if I try to delete that picture, then I get a response from my Object Storage Platform, not from my application, but from the platform, telling, sorry, you cannot delete that picture. It's under the retention. So you protect your data. Again, you could demonstrate the lifecycle policy, but we would have to wait altogether until tomorrow. So I don't see if we can do that today. So that's it. Any question? So how much code do we need for that? So all the things I developed, generally, I'm using go lang for the back end, which is very easy. Basically, what I do is that an API server. So I just have few code that is like, give me a signature. These kind of things. And then I use on go large for the front end. But what's very interesting is that you don't have to reinvent the wheel. So what's difficult with the S3 API is to sign a request. It's a very complex process. It's like you can spend days just to build the code to sign a request. So what you do is that you take an SDK, for example, the go SDK for the S3 API. And you just take the signature feature or function of it. And when you receive a call from the client, I want to get a signature. Then basically, you just go through that function, you get the signature, pass it back to the web browser. So it's very simple, very modular. If tomorrow you would like to build Android's clients, it would be like a matter of having a good designer. And you'll do it. Any other question? Good. So we are on time. Great. Thank you very much. Thank you very much. Thank you very much.