WEBVTT NOTE Created by CaptionSync from Automatic Sync Technologies www.automaticsync.com 00:00:00.286 --> 00:00:03.696 align:middle Hi everybody. 00:00:04.686 --> 00:00:12.006 align:middle Today I'll be talking about file storage for modern PHP applications. 00:00:12.776 --> 00:00:13.536 align:middle My name is Frank. 00:00:14.466 --> 00:00:19.926 align:middle I've got a couple more people dropping in. 00:00:20.206 --> 00:00:22.776 align:middle So thank you all for joining this talk. 00:00:22.856 --> 00:00:29.636 align:middle The other two talk slots are one improving workflow and the other is a good number 00:00:29.636 --> 00:00:32.606 align:middle of best practices for awesome, testability. 00:00:32.606 --> 00:00:37.016 align:middle But somehow you've managed to find the room where we're talking about file systems. 00:00:37.626 --> 00:00:41.706 align:middle Uh, I'm a freelance and a free software developer. 00:00:41.706 --> 00:00:45.466 align:middle That means I work at companies now. 00:00:45.466 --> 00:00:48.576 align:middle I can't name the company that I worked for, 00:00:48.576 --> 00:00:52.526 align:middle but it's the biggest airport in the region of Amsterdam. 00:00:52.526 --> 00:00:58.056 align:middle So if that gives you any indication then uh, then you know where I work. 00:00:58.576 --> 00:01:03.416 align:middle Uh, so, uh, as in terms of free software development, I like to contribute 00:01:03.446 --> 00:01:08.356 align:middle to open source, for Symfony because this is the Symfony conference. 00:01:08.356 --> 00:01:11.396 align:middle I thought I'd highlight some of the things that I did. 00:01:11.396 --> 00:01:15.216 align:middle So you may be familiar with who I am. 00:01:15.736 --> 00:01:18.686 align:middle Who remembers their routing speed up in 3.2. 00:01:19.546 --> 00:01:22.006 align:middle I did, I had a lot of fun coding it up. 00:01:22.066 --> 00:01:27.106 align:middle And then Nicolas came along and basically ripped out all my code. 00:01:27.946 --> 00:01:29.826 align:middle Uh, so thank you Nicolas for that. 00:01:30.416 --> 00:01:35.486 align:middle Um, but then I thought, okay, I really liked this routing component. 00:01:35.486 --> 00:01:40.216 align:middle So for a 4.1 I added the internationalized routing. 00:01:40.476 --> 00:01:43.196 align:middle Who here uses that One? 00:01:45.236 --> 00:01:49.076 align:middle Okay. So the rest of you are just stuck with code that I wrote that nobody uses. 00:01:49.626 --> 00:01:53.376 align:middle For other stuff that I did. 00:01:53.456 --> 00:01:58.486 align:middle Are there any people who like to do event-sourcing here, right? 00:01:59.066 --> 00:02:05.316 align:middle So if you like event sourcing, I created EventSauce in over the course of last year 00:02:05.676 --> 00:02:11.676 align:middle as sort of alternative way to approach event sourcing that's a little bit smaller 00:02:12.026 --> 00:02:14.746 align:middle and possibly more easy to understand. 00:02:14.746 --> 00:02:18.816 align:middle So if you are into that, maybe check it out. 00:02:19.666 --> 00:02:22.796 align:middle But for the majority of my time I've been working on Flysystem, 00:02:23.136 --> 00:02:25.226 align:middle which is a package of the PHP league. 00:02:25.226 --> 00:02:27.136 align:middle Who here knows the PHP league? 00:02:28.516 --> 00:02:30.596 align:middle Okay. Decent number of people here. 00:02:30.596 --> 00:02:32.406 align:middle Who here used Flysystem itself? 00:02:33.256 --> 00:02:34.396 align:middle That's the same people. 00:02:34.396 --> 00:02:36.096 align:middle All right. 00:02:36.306 --> 00:02:41.336 align:middle So, um, I started five years ago and I started working 00:02:41.336 --> 00:02:43.486 align:middle on this presentation like a couple months ago. 00:02:43.816 --> 00:02:50.666 align:middle And at that time we just hit the 50 million installs mark, which was pretty great, 00:02:50.866 --> 00:02:57.776 align:middle and now we're already close to 55 so it's going quite fast as you can see, it's a, 00:02:57.776 --> 00:03:01.056 align:middle it keeps on growing, growing, growing, and for the most part, 00:03:01.056 --> 00:03:06.446 align:middle working on Flysystem has been a pretty good experience, uh, 00:03:06.496 --> 00:03:11.546 align:middle but also you get to basically see all the stuff that people do with your open source work 00:03:11.546 --> 00:03:13.096 align:middle and also what they do in real life. 00:03:13.096 --> 00:03:18.266 align:middle And sometimes it's a, it's a bit scary sometimes it's a little bit depressing 00:03:18.606 --> 00:03:24.556 align:middle and when it's depressing, it's mostly PHP because or FTP because FTP is not so nice. 00:03:25.246 --> 00:03:31.586 align:middle Um, but for today we'll be talking about file storage for modern PHP applications. 00:03:32.406 --> 00:03:38.566 align:middle A note of warning this talk may not be exactly what you expect it to be, 00:03:39.166 --> 00:03:44.526 align:middle but I hope you can keep an open mind in the things that I'm gonna propose 00:03:44.526 --> 00:03:50.526 align:middle because they're going to be a mix of different things, both code and not so much code things. 00:03:51.156 --> 00:03:59.506 align:middle Um, so, uh, if we're talking about file storage for modern PHP applications, what should we do? 00:03:59.686 --> 00:04:03.216 align:middle Well, it depends and that's the problem. 00:04:03.766 --> 00:04:08.446 align:middle Uh, so today I'll be talking about a few different subjects. 00:04:08.796 --> 00:04:16.546 align:middle One is just to get a generic gist of what file systems are, what types we have, so on, 00:04:16.546 --> 00:04:23.506 align:middle so forth, um, how they interact with modern applications, what is involved in the process 00:04:23.506 --> 00:04:28.336 align:middle of choosing a file system and how you consume filesystems in code. 00:04:29.016 --> 00:04:37.046 align:middle So this talk is not so much how to do it right it's more about how not to do it wrong 00:04:37.086 --> 00:04:41.116 align:middle or even if we're doing it wrong, how to do it wrong the right way. 00:04:42.506 --> 00:04:44.656 align:middle So, okay, you're with me. 00:04:45.296 --> 00:04:48.446 align:middle Uh, so what's a filesystem? 00:04:48.566 --> 00:04:52.186 align:middle And I can already hear you say "lol don't care". 00:04:52.506 --> 00:04:58.956 align:middle It's something that we have everywhere and when I see this, when I see this, 00:04:59.816 --> 00:05:04.246 align:middle everybody looks at Buzz but I tend to feel a little bit like Woody, 00:05:04.386 --> 00:05:10.726 align:middle because filesystems is one of the things that we sort of all have problems with 00:05:10.726 --> 00:05:16.216 align:middle or something is always full disks or I don't know what to choose, 00:05:16.626 --> 00:05:20.206 align:middle but it's also one of the things like nobody really takes it 00:05:20.246 --> 00:05:22.596 align:middle into account as a decision process. 00:05:22.596 --> 00:05:24.556 align:middle It's like, oh, we have this, we'll use it. 00:05:24.736 --> 00:05:29.556 align:middle We don't tend to think about it anymore, but we do have a lot of common problems, 00:05:29.596 --> 00:05:32.656 align:middle common problems like the unstructured filesystem directory. 00:05:33.116 --> 00:05:40.086 align:middle Who here has or has had one of those unstructured uploads directories. 00:05:40.496 --> 00:05:43.566 align:middle Alright. Uh, let's, let's keep the hands up. 00:05:43.566 --> 00:05:46.666 align:middle Let's see if we can get all the hands up at the end of the questions. 00:05:47.296 --> 00:05:53.386 align:middle Um, who's ever had the question like, are these files used? 00:05:53.936 --> 00:05:58.296 align:middle Okay, can I delete these files? 00:05:58.856 --> 00:05:59.136 align:middle All right. 00:05:59.636 --> 00:06:02.016 align:middle Where did these files come from? 00:06:02.176 --> 00:06:05.386 align:middle Like, okay, people already put their hands down. 00:06:05.386 --> 00:06:07.206 align:middle That's okay, let's go, let's keep them down from now. 00:06:07.706 --> 00:06:10.806 align:middle It's like if we ask ourselves all these questions, 00:06:10.806 --> 00:06:15.196 align:middle we're pretty sure we don't exactly know how to clean this stuff up anymore. 00:06:15.596 --> 00:06:19.066 align:middle And then you can get into a situation like this. 00:06:19.646 --> 00:06:23.236 align:middle It's like that's, that's basically what it boils down to. 00:06:23.236 --> 00:06:27.086 align:middle Right? So, and other questions like can we change filesystems? 00:06:27.406 --> 00:06:31.896 align:middle Like sometimes there's reasons to do that but it's not always possible. 00:06:32.606 --> 00:06:38.606 align:middle So for me it always looks like, okay, this is fine, but is it fine? 00:06:38.606 --> 00:06:39.336 align:middle Well, I don't think so. 00:06:39.336 --> 00:06:45.716 align:middle And I think mostly it has to do with the feedback loop when we're consuming this stuff, 00:06:45.716 --> 00:06:50.206 align:middle we've got a timeline, and in this timeline we start out, we're going to create a feature. 00:06:50.206 --> 00:06:55.216 align:middle We've, uh, we've got it laid out, but all the knowledge that we really have is assumptions, 00:06:55.686 --> 00:07:00.476 align:middle then we create the feature and now we have experience with some tools and we put it 00:07:00.476 --> 00:07:03.246 align:middle in production and we get some initial usage. 00:07:03.586 --> 00:07:08.996 align:middle Uh, we get feature adoptions from our user and this is where the actual usage start, 00:07:09.276 --> 00:07:16.446 align:middle but also maybe when the actual problems start and then after awhile we detect the problems 00:07:16.446 --> 00:07:20.176 align:middle and we're going to solve them, then we're going to get actual experience. 00:07:20.506 --> 00:07:26.826 align:middle I really believe this is really a sort of a sort of depressing thing because it means 00:07:26.826 --> 00:07:29.806 align:middle that the information that we needed to have in order 00:07:29.806 --> 00:07:33.586 align:middle to make the right decision at the start is at the end. 00:07:34.126 --> 00:07:36.276 align:middle So we're sort of doomed to fail. 00:07:36.366 --> 00:07:41.136 align:middle So, how can we make the wrong decision the right way? 00:07:41.716 --> 00:07:45.466 align:middle But before we go into that, let's first briefly go into filesystems. 00:07:45.806 --> 00:07:47.176 align:middle So what is the filesystem actually? 00:07:47.686 --> 00:07:51.616 align:middle Well, a filesystem is a system that controls how data is stored and retrieved. 00:07:52.896 --> 00:07:57.286 align:middle I've highlighted the word system there because it feels like there's something in there. 00:07:57.846 --> 00:07:59.056 align:middle So what is the system? 00:07:59.446 --> 00:08:01.626 align:middle Well, system is a collection of parts conventions 00:08:01.626 --> 00:08:03.466 align:middle and interactions forming a complex whole. 00:08:04.076 --> 00:08:09.766 align:middle Okay, so if we expand, that's what a system is into the definition of what a filesystem is. 00:08:10.426 --> 00:08:11.996 align:middle What did we get? 00:08:12.556 --> 00:08:13.276 align:middle Well we get this. 00:08:13.276 --> 00:08:16.486 align:middle A filesystem is a system that provides a collection of parts, conventions 00:08:16.486 --> 00:08:22.206 align:middle and interactions, forming a complex whole that controls how data is stored and retrieved. 00:08:24.126 --> 00:08:30.996 align:middle So in itself, although we take it for granted, a filesystem is already pretty complex. 00:08:31.256 --> 00:08:38.596 align:middle The definition itself already is pretty complex, so if we dumb it down a little, 00:08:38.946 --> 00:08:42.546 align:middle we have something you use to store and retrieve data. 00:08:42.666 --> 00:08:46.636 align:middle So it's something that we use, not something that we have. 00:08:46.636 --> 00:08:48.416 align:middle If we're talking about a filesystem, 00:08:48.416 --> 00:08:52.226 align:middle we're not talking about necessarily the storage units, for example. 00:08:54.196 --> 00:08:58.856 align:middle Then if look at the different types of filesystems that we have. 00:08:58.856 --> 00:09:03.436 align:middle There are many different types, but in a broad sense like how it affects us, 00:09:03.796 --> 00:09:07.186 align:middle there are two types, that we have to deal with. 00:09:07.186 --> 00:09:12.546 align:middle One is the Nested filesystem, that's what you have in your finder and if you're using 00:09:12.546 --> 00:09:15.466 align:middle or if you're one of the 12 people that use windows 00:09:15.466 --> 00:09:17.016 align:middle at this conference, you have something else. 00:09:17.776 --> 00:09:22.466 align:middle Um, but there's also a Linear filesystems. 00:09:22.606 --> 00:09:24.816 align:middle Who here has used the Linear filesystem? 00:09:25.096 --> 00:09:30.876 align:middle Okay. Who, who here has used anything in the cloud? 00:09:32.096 --> 00:09:37.006 align:middle Okay. This is same thing normally you see so more people then raising their hands. 00:09:37.006 --> 00:09:40.356 align:middle And most things in the cloud are actually Linear filesystems. 00:09:40.356 --> 00:09:49.026 align:middle So if you have something like S3 or Azure blob storage, that's basically a linear filesystem 00:09:49.286 --> 00:09:50.476 align:middle and what's, what's the difference? 00:09:50.476 --> 00:09:55.176 align:middle So Nested filesystems are very common. 00:09:55.336 --> 00:09:59.556 align:middle Your desktop has one, it has directories which have files and more directories. 00:09:59.976 --> 00:10:04.446 align:middle On the other hand, Linear filesystems are like key value stores. 00:10:04.446 --> 00:10:08.276 align:middle So instead of directories, you just have full paths, they might have separators 00:10:08.576 --> 00:10:12.586 align:middle that look the same as a directory separators. 00:10:12.626 --> 00:10:16.796 align:middle But it's really just a sort of key value system. 00:10:17.096 --> 00:10:22.756 align:middle They only have files and if you know that, then, if you say what's common 00:10:22.756 --> 00:10:25.996 align:middle between Linear filesystems and Nested filesystem? 00:10:25.996 --> 00:10:28.646 align:middle So it's basically only the files, right? 00:10:28.886 --> 00:10:32.486 align:middle So what you can say is that directories don't really exist 00:10:32.536 --> 00:10:34.516 align:middle if you look at the common denominators. 00:10:35.456 --> 00:10:39.286 align:middle So, uh, they require a different approach and they're very cloud. 00:10:40.366 --> 00:10:47.176 align:middle So if we're looking at filesystem offering we see, or at least I saw something interesting. 00:10:48.256 --> 00:10:53.096 align:middle There's a bunch in the group that is file system, then that's a network attached storage. 00:10:53.096 --> 00:10:55.706 align:middle So if you're on AWS, you have a volume. 00:10:55.706 --> 00:10:58.766 align:middle If you're on a Digital Ocean, you have like the blob storage stuff 00:10:58.816 --> 00:11:00.846 align:middle that you can also mount into your VPSs. 00:11:01.196 --> 00:11:05.746 align:middle There's stuff like Gluster FS and Ceph and I think, I don't know if there somebody 00:11:05.796 --> 00:11:11.426 align:middle from the SymfonyCloud in here, but I think they're using Ceph. 00:11:12.396 --> 00:11:14.396 align:middle I see nobody from the Symfony. 00:11:14.396 --> 00:11:15.596 align:middle Okay. That's okay. 00:11:15.596 --> 00:11:17.226 align:middle I think, uh, that's the case. 00:11:17.936 --> 00:11:21.326 align:middle There's another group and that's basically filesystem and CDN. 00:11:21.326 --> 00:11:28.276 align:middle Then you get things like AWS S3, Digital Ocean Spaces stuff, uh, Rackspace Cloud Files 00:11:28.276 --> 00:11:30.936 align:middle and Google Cloud Storage, all those kinds of things. 00:11:31.636 --> 00:11:35.576 align:middle That is the filesystem plus CDN, and then you've got more 00:11:35.576 --> 00:11:38.506 align:middle and that's more filesystem plus sharing. 00:11:38.506 --> 00:11:42.896 align:middle So Dropbox, Box, Google drive, Microsoft OneDrive, those kinds of things. 00:11:43.146 --> 00:11:46.966 align:middle And then you have things where you can put files in but they're not really supposed 00:11:46.966 --> 00:11:49.536 align:middle to be filesystems but they happen to support it. 00:11:49.926 --> 00:11:54.946 align:middle So like WebDAV, which is something different entirely. 00:11:54.946 --> 00:11:59.066 align:middle It's more the protocol of interacting with somebody er something 00:11:59.466 --> 00:12:03.076 align:middle over HTTP rather than being a filesystem. 00:12:03.076 --> 00:12:08.656 align:middle You have MongoDB GridFS, and I think I've got a MongoDB engineer in the room in the back... 00:12:09.246 --> 00:12:10.126 align:middle Oh, I've got two. 00:12:10.726 --> 00:12:14.666 align:middle And you can also use something like Postgres Large Object Storage. 00:12:15.206 --> 00:12:21.576 align:middle But if we flip this around, we see all those things and then we say, 00:12:21.576 --> 00:12:23.166 align:middle well, what's the inverse of this? 00:12:23.166 --> 00:12:24.886 align:middle What is not a filesystem? 00:12:25.386 --> 00:12:29.456 align:middle Well, a filesystem is not one of those CDN's. 00:12:29.566 --> 00:12:33.156 align:middle So a content distribution network is not a filesystem. 00:12:33.436 --> 00:12:38.106 align:middle It's something that uses a filesystem, but it is not a filesystem and the same goes 00:12:38.106 --> 00:12:41.166 align:middle for all these other things like a web server is not a filesystem, 00:12:41.166 --> 00:12:43.696 align:middle file managers like something that operates on. 00:12:43.986 --> 00:12:49.786 align:middle So there's a lot of things in this space that sort of overlaps with filesystems 00:12:49.786 --> 00:12:54.346 align:middle and they supply the same offering as filesystems, but they are not filesystems. 00:12:55.456 --> 00:12:59.476 align:middle So for me that is sort of a problem. 00:12:59.476 --> 00:13:04.086 align:middle If we look at one thing and that one thing has two concerns, 00:13:04.126 --> 00:13:12.676 align:middle we tend to obfuscate those concerns and view it as one and that might induce misuse of a, 00:13:12.986 --> 00:13:18.716 align:middle of a product or in the use case that we have. 00:13:18.716 --> 00:13:22.946 align:middle Ryan Singer in 2010 said this. 00:13:23.046 --> 00:13:27.076 align:middle So much complexity in software comes from trying to make one thing do two things. 00:13:27.076 --> 00:13:29.906 align:middle And I wholeheartedly agree with this. 00:13:30.456 --> 00:13:33.006 align:middle Uh, I don't know who knows the statement, 00:13:33.176 --> 00:13:37.036 align:middle but this is one that comes back at least once a month for me. 00:13:37.036 --> 00:13:39.926 align:middle It's like, okay, I should dumb this down. 00:13:40.106 --> 00:13:41.856 align:middle It'll be better. 00:13:42.246 --> 00:13:48.396 align:middle So my version of this is stop trying to make a filesystem do 100 things 00:13:48.396 --> 00:13:52.636 align:middle and that's also sometimes what I see when you, when people use Flysystem, 00:13:52.636 --> 00:13:56.856 align:middle they want to use it for access control. 00:13:56.856 --> 00:13:59.396 align:middle They want signed URLs for different things. 00:13:59.426 --> 00:14:01.076 align:middle They want to expose it over HTTP. 00:14:01.076 --> 00:14:02.226 align:middle And all those things. 00:14:02.556 --> 00:14:04.786 align:middle They don't really belong with filesystems. 00:14:05.246 --> 00:14:11.436 align:middle If you look at filesystems, they're basically CRUDish, but I've let some space open 00:14:11.436 --> 00:14:18.276 align:middle at the bottom because you've got writing files, reading files, updating the contents of files 00:14:18.276 --> 00:14:20.196 align:middle or deleting file that's pretty CRUD. 00:14:20.386 --> 00:14:24.946 align:middle But there's also these two other things like you've got inspect and list. 00:14:25.016 --> 00:14:28.346 align:middle So inspect is more like getting the mime type of a file, 00:14:28.986 --> 00:14:32.426 align:middle listing is like getting what is in a directory. 00:14:32.856 --> 00:14:37.126 align:middle So it's basically CRUDLI not yet a term, but I've coined here now... 00:14:37.206 --> 00:14:41.516 align:middle So, if you use it now, you will have to pay me money. 00:14:41.796 --> 00:14:47.306 align:middle Um, so if we use, if you look at filesystems and PHP, I'm just gonna take a little sip water. 00:14:47.876 --> 00:14:57.566 align:middle Then if we look at the usage, it's, it started out it starts off pretty easy 00:14:58.436 --> 00:15:02.376 align:middle so we can very easily write to a file. 00:15:02.516 --> 00:15:07.776 align:middle We can read from a file, we can delete it, although now it's called unlink rather 00:15:07.776 --> 00:15:12.876 align:middle than delete and we can get the modified time of a file using mtime 00:15:12.876 --> 00:15:15.216 align:middle and that's an abbreviation of half the words. 00:15:15.686 --> 00:15:18.226 align:middle Maybe a bit confusing of them. 00:15:18.226 --> 00:15:23.796 align:middle We have things that are related to file info and that already gets really confusing 00:15:24.376 --> 00:15:30.276 align:middle because you now have to instantiate an object with the type of thing that you want to retrieve 00:15:30.516 --> 00:15:35.286 align:middle from it and pass it a location to the file methods in order to get the mime type. 00:15:35.286 --> 00:15:41.446 align:middle So pretty confusing already, but it gets more confusing because if you want 00:15:41.446 --> 00:15:47.286 align:middle to get the directory listing for a particular directory, what do you use well you've got glob, 00:15:47.286 --> 00:15:52.576 align:middle scandir and readdir, which takes a resource which it needs to retrieve from opendir. 00:15:53.186 --> 00:15:57.206 align:middle Or, you can use the spl directory iterators which are awesome, 00:15:57.206 --> 00:15:59.646 align:middle but you get all these other types of objects back 00:15:59.956 --> 00:16:02.786 align:middle that you can't really serialize or anything. 00:16:02.786 --> 00:16:05.036 align:middle So you need to do some normalization. 00:16:05.036 --> 00:16:09.356 align:middle And like which one of these is better? 00:16:09.456 --> 00:16:14.316 align:middle As it turns out the last one is the most performant 00:16:14.316 --> 00:16:17.256 align:middle for the most cases in the most general thing. 00:16:17.256 --> 00:16:20.476 align:middle But who will remember typing that out every time? 00:16:20.476 --> 00:16:21.346 align:middle So like WAT. 00:16:21.346 --> 00:16:27.686 align:middle Oh, okay. So then, uh, if you're, uh, handling big files, you have to uh, 00:16:27.786 --> 00:16:31.106 align:middle use functions like fopen and fread and fwrite. 00:16:31.196 --> 00:16:34.006 align:middle Who here is comfortable using those functions? 00:16:34.726 --> 00:16:39.456 align:middle Okay. So definitely less than a quarter of you just raised their hands. 00:16:39.456 --> 00:16:43.026 align:middle Well these are pretty essential for, for the most part. 00:16:43.506 --> 00:16:50.956 align:middle And this is a relatively simple example where you basically, this is a copy, 00:16:51.046 --> 00:16:58.296 align:middle but then in php rather than just saying copy, but this does not handle all the error cases. 00:16:58.296 --> 00:17:01.806 align:middle If you look at this and handling all the error cases, it actually looks like this. 00:17:02.626 --> 00:17:10.216 align:middle So it becomes very complex and very verbose and it's a lot different from a file_put_contents. 00:17:10.216 --> 00:17:15.156 align:middle Right? So, so WAT, why can't you just use copy? 00:17:15.156 --> 00:17:19.006 align:middle Well, copy, if we're looking at filesystem a copy just works locally. 00:17:19.006 --> 00:17:23.506 align:middle Those stream things, they might work for other things as well. 00:17:24.406 --> 00:17:28.956 align:middle So as I mentioned for the last couple of years, I've been working on Flysystem. 00:17:29.446 --> 00:17:34.246 align:middle So what does Flysystem give you in order to help you with this? 00:17:34.656 --> 00:17:39.326 align:middle Well, it gives you a uniform API, which means this is how you interact 00:17:39.436 --> 00:17:41.206 align:middle with the filesystem using Flysystem. 00:17:41.206 --> 00:17:45.126 align:middle You create an adapter, you used that in a filesystem 00:17:45.126 --> 00:17:47.046 align:middle and then you use the filesystem to write. 00:17:47.046 --> 00:17:48.866 align:middle You never use the adapter directly. 00:17:48.866 --> 00:17:52.556 align:middle That's a, yeah, it's part of the pattern, adaptive pattern. 00:17:53.076 --> 00:17:59.136 align:middle Uh, it's really applicable here and you basically have basic operations for writing, 00:17:59.136 --> 00:18:01.746 align:middle reading, updating and many more things. 00:18:02.596 --> 00:18:08.486 align:middle Uh, but it also means that if you want to change, for example, to the AWS S3, 00:18:08.486 --> 00:18:14.046 align:middle all you have to do is change the configuration and all the usage stays the same. 00:18:14.676 --> 00:18:16.196 align:middle So that's pretty powerful. 00:18:16.416 --> 00:18:23.216 align:middle And if you are one of the people that have to use FTP, you don't need to deal with it anymore. 00:18:23.216 --> 00:18:25.536 align:middle As I said, I've taken the pain for you. 00:18:25.936 --> 00:18:32.516 align:middle You can just use this and get done with the job. 00:18:34.016 --> 00:18:40.656 align:middle The stream part in Flysystem allows you to remove a whole bunch of that conditional code. 00:18:40.966 --> 00:18:51.576 align:middle Basically you can, get a stream from a remote filesystem, uh, and pass that to a local one 00:18:52.086 --> 00:18:56.586 align:middle and if you'd need to, for example, change something that's on a remote filesystem, 00:18:56.996 --> 00:19:01.696 align:middle you can first download it like this, do some stuff, and then re upload. 00:19:01.756 --> 00:19:06.656 align:middle This is a common pattern that you'll see when you're moving to remote file systems 00:19:07.116 --> 00:19:12.446 align:middle because a lot of the functionality that we need in order to operate 00:19:12.446 --> 00:19:15.146 align:middle on files require your files to be local first. 00:19:15.546 --> 00:19:19.366 align:middle For example, if you want to manipulate images, they need to be in your local dist. 00:19:19.396 --> 00:19:22.556 align:middle They can't use a stream from an external service. 00:19:22.556 --> 00:19:24.396 align:middle So this is something that you need to keep in mind. 00:19:25.256 --> 00:19:31.656 align:middle But that's, this is not so much code in order for you to get this working. 00:19:31.656 --> 00:19:32.696 align:middle So it's okay. 00:19:33.646 --> 00:19:38.886 align:middle Um, this also means that you can use two remote services 00:19:38.926 --> 00:19:42.116 align:middle to basically pipe so many information through. 00:19:42.346 --> 00:19:47.446 align:middle So here we're reading from Azure and we're writing to AWS and your thing to notice is 00:19:47.496 --> 00:19:52.736 align:middle because we're using string, we're only using a small portion of our memory at a given time, 00:19:52.736 --> 00:20:01.836 align:middle so this could be a re uploading from Azure to AWS, like a multi gigabyte file, uh, 00:20:01.836 --> 00:20:09.086 align:middle but even if your local php installation is limited to like the default amount 00:20:09.276 --> 00:20:12.406 align:middle of memory this won't run out of memory. 00:20:12.766 --> 00:20:14.036 align:middle So that's pretty powerful. 00:20:14.706 --> 00:20:18.106 align:middle The other part that Flysystem gives is relative paths. 00:20:18.666 --> 00:20:22.016 align:middle Everything in Flysystem has relative paths. 00:20:22.316 --> 00:20:25.186 align:middle And what I mean with relative paths is the following. 00:20:26.386 --> 00:20:34.306 align:middle You have a configuration root, so if you have a filesystem and it's confined to stay in a root 00:20:34.756 --> 00:20:39.676 align:middle and every location that you provided is a relative path from that root. 00:20:39.676 --> 00:20:41.646 align:middle And it always needs to reside there. 00:20:42.106 --> 00:20:49.206 align:middle This means that if you change the root, the configuration changes, 00:20:49.256 --> 00:20:51.606 align:middle but you're how you're using it won't change. 00:20:52.376 --> 00:20:56.836 align:middle So this is a pretty powerful concept because it's a very strong encapsulation principle. 00:20:57.986 --> 00:21:01.436 align:middle So if you're using the local file system and you have that first path, 00:21:01.486 --> 00:21:05.336 align:middle so it's in /configuration/, that's where you store all your files 00:21:05.566 --> 00:21:08.386 align:middle and that's just basically how you set up your services. 00:21:09.756 --> 00:21:15.136 align:middle The configuration is there, and then when you use it in your other services 00:21:15.356 --> 00:21:19.806 align:middle or inside your services or maybe directly in your control or whatever you like, 00:21:19.806 --> 00:21:25.986 align:middle you can basically use the relative path and Flysystem will make sure that they're combined 00:21:25.986 --> 00:21:29.356 align:middle and actually written to the appropriate path. 00:21:29.656 --> 00:21:33.716 align:middle This means if you for some reason need to change the location of your files. 00:21:33.716 --> 00:21:38.356 align:middle For example, if you're running out of disk space and they attach a new network attached storage 00:21:38.616 --> 00:21:41.016 align:middle that is bigger or automatically responding 00:21:41.016 --> 00:21:44.816 align:middle or whatever fancy thing they've got configured for you. 00:21:45.186 --> 00:21:48.366 align:middle All you do is change the configuration. 00:21:49.416 --> 00:21:54.796 align:middle This means all your consuming code will forever remain the same and that's pretty powerful, 00:21:54.796 --> 00:21:56.616 align:middle but you can take this even further 00:21:56.616 --> 00:22:00.976 align:middle because it even applies the same concept over multiple filesystems. 00:22:01.296 --> 00:22:05.466 align:middle So if you're moving from local to something that is in AWS, 00:22:05.966 --> 00:22:08.426 align:middle all you're consuming code will never have to change. 00:22:09.386 --> 00:22:14.686 align:middle And this, this is pretty powerful because it prevents vendor locking. 00:22:15.056 --> 00:22:19.826 align:middle Basically, if all your code knows is that all the files are going to AWS and you want 00:22:19.826 --> 00:22:25.876 align:middle to switch to something else, but now you have to basically refactor half of your codebase. 00:22:26.476 --> 00:22:30.286 align:middle Uh, I don't know any manager who is like, yeah, yeah, sure, 00:22:30.286 --> 00:22:32.536 align:middle spend the hours on that, that's amazing. 00:22:32.976 --> 00:22:38.926 align:middle They're going to prioritize something else, but what if that expense is lower, close to zero, 00:22:39.166 --> 00:22:43.156 align:middle then you've got a better opportunity to actually push for that change 00:22:43.406 --> 00:22:45.646 align:middle and reap more benefits from that move. 00:22:46.126 --> 00:22:50.926 align:middle So it is better for isolation, better for encapsulation 00:22:50.926 --> 00:22:55.016 align:middle because all the responses are exactly the same from every adapter. 00:22:55.746 --> 00:22:59.476 align:middle It helps with predictability and that helps to stabilize software. 00:23:00.156 --> 00:23:04.456 align:middle Uh, and in the end that makes sure that everything is super portable. 00:23:05.426 --> 00:23:08.406 align:middle But don't use Flysystem for anything. 00:23:08.846 --> 00:23:14.926 align:middle If you're using local only, for example, for templating engine looking up files or a, 00:23:15.256 --> 00:23:22.566 align:middle if you want funky things with symlinks, then you will only ever do that on your local filesystem. 00:23:22.566 --> 00:23:24.296 align:middle So don't use Flysystem for that. 00:23:24.666 --> 00:23:27.556 align:middle Then it's more of an overhead, you'll be limited. 00:23:27.606 --> 00:23:30.526 align:middle Because the limitations are functional for file storage, 00:23:31.006 --> 00:23:37.466 align:middle but for at least local specific filesystem only things, you'll just be limited. 00:23:37.596 --> 00:23:41.916 align:middle So keep that in mind. 00:23:42.096 --> 00:23:46.516 align:middle So if we're then going into the process of choosing another filesystem, 00:23:46.916 --> 00:23:51.406 align:middle we often use the FEYNMAN problem solving algorithm 00:23:52.086 --> 00:23:54.846 align:middle and actually this is more than people do already. 00:23:55.046 --> 00:23:58.086 align:middle There the algorithms says write down the problem. 00:23:58.086 --> 00:24:02.326 align:middle Well mostly people just think of the problem and then they think very hard 00:24:02.736 --> 00:24:04.366 align:middle and then they come up with a solution. 00:24:05.086 --> 00:24:08.276 align:middle But I don't, I don't think that works very well. 00:24:09.836 --> 00:24:17.556 align:middle If we have somebody who uses our application and they want to upload a file, um, 00:24:18.216 --> 00:24:23.356 align:middle we the browser has to file uploads through us and then the file is there. 00:24:23.586 --> 00:24:28.336 align:middle If you want to use the local file system for that, that's fine. 00:24:28.656 --> 00:24:31.446 align:middle Still many people who are developing 00:24:31.446 --> 00:24:36.196 align:middle or deploying applications, deploy to one machine only. 00:24:36.626 --> 00:24:43.186 align:middle So if you put a well configured nginx configuration for that one web server, 00:24:43.366 --> 00:24:47.756 align:middle you basically have a CDN and there's a lot less hassle 00:24:47.756 --> 00:24:49.476 align:middle and moving around, that you have to do so. 00:24:49.836 --> 00:24:53.876 align:middle It's always good to know if you're not restricted by this, you can use this option, 00:24:53.876 --> 00:24:57.656 align:middle so like the local file system stuff is the majority of the stuff 00:24:57.656 --> 00:25:00.196 align:middle and then we are in the cloud space. 00:25:00.196 --> 00:25:02.386 align:middle And when do you want to go to the cloud space? 00:25:02.386 --> 00:25:06.186 align:middle Well that's mostly when you have that image that you want to upload, 00:25:06.186 --> 00:25:08.346 align:middle but instead of one web server you now have three. 00:25:08.906 --> 00:25:13.966 align:middle And if you upload the picture to one and somebody else wants to retrieve the picture, 00:25:13.966 --> 00:25:17.306 align:middle well how do they know they're going to get it from that one server? 00:25:17.306 --> 00:25:23.126 align:middle Probably there's a load balancer in between, but that should be not sticky and not knowing 00:25:23.126 --> 00:25:25.806 align:middle of the implementation of the web servers below. 00:25:26.556 --> 00:25:30.426 align:middle So the generic solution for this is pretty simple actually. 00:25:30.426 --> 00:25:32.886 align:middle You just make sure they share storage. 00:25:32.886 --> 00:25:35.796 align:middle So you can do this in various ways. 00:25:37.256 --> 00:25:41.286 align:middle Um, obviously the file goes there. 00:25:42.086 --> 00:25:46.326 align:middle Um, so you can do this either by using a service or using something 00:25:46.326 --> 00:25:49.066 align:middle that shares the filesystem across many things. 00:25:49.066 --> 00:25:52.466 align:middle So you can use a clustered type of file system, like Lustre fs 00:25:52.466 --> 00:25:56.416 align:middle or something else in order to orchestrate this. 00:25:56.706 --> 00:26:03.536 align:middle So you need to know that the storage now becomes a separate entity that multiple, 00:26:03.716 --> 00:26:08.666 align:middle instances of your application are using this singular entity and whether, 00:26:08.666 --> 00:26:13.916 align:middle if it's a mounted filesystem or it's a service actually doesn't matter. 00:26:14.396 --> 00:26:20.476 align:middle So why do you want to do it as well if you want to scale horizontally, just as a quick poll. 00:26:20.666 --> 00:26:25.636 align:middle Who here scales horizontally their applications? 00:26:26.076 --> 00:26:28.586 align:middle Okay. The other way around. 00:26:28.656 --> 00:26:30.936 align:middle Who deploys their application to one server? 00:26:31.496 --> 00:26:37.806 align:middle Okay. So there's, I didn't see all the hands going up or down, but it's ok. 00:26:38.086 --> 00:26:41.846 align:middle Still a good number of people have that. 00:26:42.566 --> 00:26:46.236 align:middle If you don't need to do that, you may also not need to bother 00:26:46.316 --> 00:26:50.806 align:middle with the extra filesystem expenses because they do come in expense. 00:26:51.476 --> 00:26:54.246 align:middle But if you do need to do that, we want stateless apps 00:26:54.326 --> 00:26:58.666 align:middle or in some cases we don't want to serve the files ourselves. 00:26:58.666 --> 00:27:05.576 align:middle So we want something like a CDN maybe for geographical reasons or other, uh, 00:27:05.576 --> 00:27:09.286 align:middle or we maybe want to share the files across multiple applications. 00:27:09.726 --> 00:27:17.976 align:middle And I think when we then, going through the process of choosing a filesystem, 00:27:17.976 --> 00:27:20.186 align:middle we're not asking direct questions. 00:27:21.256 --> 00:27:27.106 align:middle Mostly, if we're asking the questions were asked like, do they need to be on premise 00:27:27.106 --> 00:27:30.596 align:middle or can they be in the cloud aka still somebody's computer. 00:27:31.326 --> 00:27:35.456 align:middle But I think more important things to take into account is, for example, 00:27:35.456 --> 00:27:37.446 align:middle the question of who will do the maintenance? 00:27:38.046 --> 00:27:43.296 align:middle If you've got a file system locally, you also need somebody who manages that. 00:27:43.686 --> 00:27:52.926 align:middle If you're using a service that's can basically scale infinitely like S3 or Azure blob storage, 00:27:53.326 --> 00:27:57.876 align:middle you don't have to think about it anymore, but that might also come at a cost at a later time 00:27:57.876 --> 00:28:00.546 align:middle when you just keep growing in your expenses go up. 00:28:00.766 --> 00:28:01.866 align:middle But that's a different problem. 00:28:02.096 --> 00:28:06.096 align:middle Hiring An, uh, an operations person to manage a cluster 00:28:06.096 --> 00:28:10.636 align:middle of filesystems, uh, it's not an easy task. 00:28:10.636 --> 00:28:14.706 align:middle So you need to think about that as an organization and as a developer, 00:28:15.076 --> 00:28:17.286 align:middle do you want to spend your time doing that? 00:28:17.286 --> 00:28:20.516 align:middle Or do you want to spend your time writing code and just consuming. 00:28:21.386 --> 00:28:28.376 align:middle But also you need to think about how we will use the files. 00:28:28.496 --> 00:28:32.986 align:middle Do we have particular needs that the file needs to have? 00:28:33.446 --> 00:28:41.386 align:middle You can serve, um, for example, videos from your local web server, 00:28:41.716 --> 00:28:47.926 align:middle but there are also specialized services where you can upload your files and they are 00:28:47.926 --> 00:28:54.686 align:middle like a media service that will do all the bit rates stuff for you. 00:28:54.926 --> 00:29:00.806 align:middle So you've got a specialized more capable file storage solution that you can just use. 00:29:01.606 --> 00:29:05.706 align:middle You can also ask why are we storing things in the first place? 00:29:06.136 --> 00:29:10.026 align:middle Uh, there are a lot of cases still where people upload CSV or excel files 00:29:10.026 --> 00:29:13.836 align:middle and they extract data from it and then they use that. 00:29:13.976 --> 00:29:17.966 align:middle They store it in the database, but they will also keep the file separately. 00:29:18.436 --> 00:29:22.326 align:middle And do you have rules about how long we keep that? 00:29:22.746 --> 00:29:25.266 align:middle How long are we going to keep those files? 00:29:26.586 --> 00:29:28.176 align:middle How big will the files be? 00:29:28.706 --> 00:29:35.246 align:middle All these sort of things, questions need to trigger you into finding 00:29:35.246 --> 00:29:38.516 align:middle out what the needs of your use cases. 00:29:38.806 --> 00:29:43.186 align:middle So it's really good to distinguish needs and capabilities. 00:29:43.186 --> 00:29:50.626 align:middle Needs is what you require from a solution and a capability is something that something can do. 00:29:50.986 --> 00:29:54.526 align:middle So for example, S3 can be used as a CDN, 00:29:54.526 --> 00:30:00.456 align:middle but if you don't have those needs, maybe you don't need to use S3. 00:30:01.236 --> 00:30:06.806 align:middle But now if we've asked all these questions, we need to somehow document this. 00:30:06.806 --> 00:30:09.286 align:middle So I think we need to write stuff down. 00:30:09.936 --> 00:30:15.006 align:middle But if you're then looking at the agile manifesto, we often see this, well, 00:30:15.126 --> 00:30:18.106 align:middle working software over comprehensive documentation. 00:30:18.106 --> 00:30:21.586 align:middle And what developer then thinks is, haha I don't need to write documentation. 00:30:22.726 --> 00:30:24.886 align:middle I would argue the difference. 00:30:24.886 --> 00:30:28.616 align:middle Um, and I had a conversation with Rafael Dohms about this 00:30:28.616 --> 00:30:31.496 align:middle and Rafael Dohms, is basically he's a Brazilian. 00:30:31.496 --> 00:30:35.216 align:middle That means he talks in Portuguese but then talks about barbecues a lot. 00:30:36.206 --> 00:30:38.046 align:middle Um, I think that's correct. 00:30:38.096 --> 00:30:42.016 align:middle Correct me if I'm wrong, and he reminded me of a technique called ADR. 00:30:42.016 --> 00:30:44.266 align:middle ADR is Architecture Decision Records. 00:30:44.346 --> 00:30:49.066 align:middle And in this format you can store all this collective knowledge. 00:30:49.516 --> 00:30:52.406 align:middle And this consists of a couple parts. 00:30:52.676 --> 00:30:53.946 align:middle One is context. 00:30:54.316 --> 00:30:58.646 align:middle The context is something that influences the decision, um, 00:30:58.896 --> 00:31:01.876 align:middle that is something that is there, that's a given. 00:31:02.126 --> 00:31:03.976 align:middle For example, the team uses AWS. 00:31:03.976 --> 00:31:10.916 align:middle If the team uses AWS, it's more likely they will choose for S3 and if the team uses Azure, 00:31:11.076 --> 00:31:15.016 align:middle it's more likely that they will use something like Azure blob storage. 00:31:15.316 --> 00:31:18.316 align:middle And this is a logical decision, but it's good to keep that in mind. 00:31:18.806 --> 00:31:21.306 align:middle Um, for accountability purposes. 00:31:21.846 --> 00:31:25.376 align:middle Um, another context might be we expect massive storage growth. 00:31:25.456 --> 00:31:31.966 align:middle This might be something to think about, like, do I want a infinitely scalable file system? 00:31:32.076 --> 00:31:35.866 align:middle If you are expecting a large number of files, it might be a smart thing 00:31:35.866 --> 00:31:37.326 align:middle to think about that from the get go. 00:31:38.016 --> 00:31:42.546 align:middle Another requirement would be that we need to store things on premise 00:31:42.546 --> 00:31:45.026 align:middle or data must be stored in the EU. 00:31:45.706 --> 00:31:48.826 align:middle Uh, do, do you know this for the files? 00:31:48.826 --> 00:31:50.536 align:middle Do you ask these questions? 00:31:50.536 --> 00:31:56.696 align:middle Like you, we should be asking these questions and then we'll also document the decision. 00:31:56.926 --> 00:32:02.686 align:middle So what is the decision that we made according to the context and the needs that we had? 00:32:03.046 --> 00:32:09.436 align:middle Well we'll use AWS S3 or Blob Storage or whatever, but then there's another part 00:32:09.436 --> 00:32:11.846 align:middle and the other part is the consequences. 00:32:11.846 --> 00:32:16.586 align:middle So if we're moving from local to something remote, we have consequences in our code. 00:32:16.586 --> 00:32:18.496 align:middle So we need to change our code accordingly. 00:32:18.496 --> 00:32:24.396 align:middle This is a consequence of the choice that we made and by having such a document, 00:32:24.396 --> 00:32:29.086 align:middle you also have something that you can communicate with your team leads, but also to management 00:32:29.356 --> 00:32:34.816 align:middle in order to say, well, we see these conditions and we made this recommendation. 00:32:35.116 --> 00:32:38.756 align:middle Now we as a company can make this decision. 00:32:38.756 --> 00:32:43.526 align:middle So you make people accountable with you for the decisions that you've made. 00:32:43.526 --> 00:32:49.976 align:middle So if later in time your needs have changed and now you're not the developer 00:32:49.976 --> 00:32:55.016 align:middle who made the bad decision, no, you and your manager both made an agreement 00:32:55.016 --> 00:32:56.806 align:middle that this was the right choice at the time. 00:32:57.156 --> 00:33:05.136 align:middle So you actually have, something to motivate your manager in order to make the new right decision 00:33:05.136 --> 00:33:07.576 align:middle with you without it coming at your expense. 00:33:07.576 --> 00:33:11.466 align:middle So I think that's a really, it's more political than anything, 00:33:11.466 --> 00:33:14.136 align:middle but it's really a good thing to think about. 00:33:16.336 --> 00:33:23.556 align:middle So now we've chosen something and now we can actually create an implementation. 00:33:23.656 --> 00:33:27.686 align:middle So I would argue that the best thing that you can do for any application is 00:33:27.686 --> 00:33:29.976 align:middle to create Use-Case Driven Storage Models. 00:33:29.976 --> 00:33:31.046 align:middle And what do they look like? 00:33:31.046 --> 00:33:35.966 align:middle Well, they can look like an interface, so the interface could be ProfilePictureStorage 00:33:36.586 --> 00:33:42.586 align:middle and we'll just have a store function that will accept the user and their contents 00:33:42.926 --> 00:33:45.356 align:middle or in this case a resource containing the content. 00:33:45.356 --> 00:33:49.446 align:middle So profile picture or for example, a financial report. 00:33:50.186 --> 00:33:52.586 align:middle Same thing and how does this look internally? 00:33:52.586 --> 00:33:54.196 align:middle Well internally, it looks something like this. 00:33:54.196 --> 00:33:57.356 align:middle We've got an Filesystem Financial Report Storage 00:33:57.676 --> 00:34:01.136 align:middle which implements the Financial Report Storage interface 00:34:01.656 --> 00:34:06.666 align:middle and it uses the file system internally to dispatch. 00:34:07.006 --> 00:34:13.816 align:middle And this is a really powerful thing because this makes sure that the path created, 00:34:13.816 --> 00:34:19.986 align:middle which is a relative path, so easy to move around, will always be created here. 00:34:19.986 --> 00:34:25.826 align:middle We don't have multiple areas where we're operating on the same part of the filesystem. 00:34:26.066 --> 00:34:30.556 align:middle So we've got an encapsulation of our Use-Case in this thing. 00:34:30.716 --> 00:34:33.916 align:middle Just to reiterate, it's really good to isolate your use case. 00:34:34.666 --> 00:34:46.996 align:middle Um, so we now have consumed this and now what happens when stuff goes bad? 00:34:47.476 --> 00:34:52.646 align:middle So who here knows of the concept of, or the thing called (Blameless) Post-Mortem? 00:34:53.196 --> 00:35:01.626 align:middle Okay. Who has a meeting after something like a production incident went down? 00:35:01.626 --> 00:35:04.986 align:middle Okay. That's way too few hands. 00:35:05.556 --> 00:35:14.616 align:middle So like if we look at this, if we know that we need the information from the end in order 00:35:14.616 --> 00:35:18.786 align:middle to make the decision, uh, back, uh, or at the front. 00:35:19.456 --> 00:35:21.666 align:middle We need some sort of feedback mechanism. 00:35:21.666 --> 00:35:25.546 align:middle So what I propose is to document that as well. 00:35:25.786 --> 00:35:29.076 align:middle At least there's a sort of reference for the, for the future. 00:35:29.076 --> 00:35:34.386 align:middle So the next time you'll see, well we have these problems and instead of relying on gut feeling, 00:35:34.386 --> 00:35:36.406 align:middle you actually have a record of what happened. 00:35:36.896 --> 00:35:42.296 align:middle And what this needs to contain is what actually happened. 00:35:42.386 --> 00:35:45.146 align:middle For example, the storage was unavailable or what caused it. 00:35:45.346 --> 00:35:48.346 align:middle For example, a full disk, what did we do to fix it? 00:35:48.346 --> 00:35:53.846 align:middle Well, sometimes this can be the dirty thing you needed to do in order to go like ssh 00:35:53.846 --> 00:35:57.776 align:middle on the production machine and manually deleting files that you no longer need. 00:35:58.046 --> 00:36:03.636 align:middle Or even deleting files from a different part of the application in order to free up more time 00:36:03.706 --> 00:36:07.656 align:middle for more space for the, for, for the problematic area. 00:36:07.656 --> 00:36:08.926 align:middle This is something that can happen. 00:36:09.966 --> 00:36:14.666 align:middle And, but more importantly, you can also document how you could have prevented it. 00:36:14.716 --> 00:36:20.826 align:middle If you're looking at your way of working, some of you might be working agile. 00:36:21.866 --> 00:36:27.766 align:middle If you're bothered by this a lot and you can give priority to these kinds of solutions, 00:36:27.766 --> 00:36:35.276 align:middle you automatically have a very good justification to tackle technical debt in your, 00:36:35.276 --> 00:36:40.466 align:middle workflow as part of your workflow and with probably with consent of management 00:36:40.466 --> 00:36:45.046 align:middle because they saw what kind of pain they and the business endured 00:36:45.226 --> 00:36:46.986 align:middle and what kind of solution you can provide. 00:36:48.246 --> 00:36:51.716 align:middle So to round things up, use Flysystem. 00:36:52.666 --> 00:36:54.356 align:middle Keep things simple. 00:36:54.356 --> 00:36:59.816 align:middle Use a filesystem for what it's for and use the other capabilities if you want but always keep 00:36:59.816 --> 00:37:02.676 align:middle that file storage concern, isolated. 00:37:03.606 --> 00:37:08.196 align:middle Document your requirements, document your decisions using ADR. 00:37:09.016 --> 00:37:15.356 align:middle Create specific storage classes per use case and create use generic solutions 00:37:15.356 --> 00:37:19.856 align:middle for generic problems and use special solutions for special problems. 00:37:20.276 --> 00:37:27.486 align:middle And just to finish up and see how weird things can be, um, for example, you can use ceph 00:37:27.486 --> 00:37:36.216 align:middle and ceph also has a way to talk over HTTP and it actually implements the S3 protocol 00:37:36.216 --> 00:37:44.366 align:middle so you can use your AWS adapter to use to talk to ceph and ceph can be installed locally 00:37:44.686 --> 00:37:49.206 align:middle so you can be your own S3 if you need to have stuff on premise. 00:37:49.536 --> 00:37:54.486 align:middle This might be an interesting solution for you if you're heavily invested in S3, 00:37:54.486 --> 00:37:57.556 align:middle but need to move stuff back on prem. 00:37:58.646 --> 00:38:04.686 align:middle You can also use mongoDB as a file storage, but for very, very specific use case. 00:38:05.126 --> 00:38:13.036 align:middle For example, you can have a, geo distributed cluster of mongoDB nodes 00:38:13.036 --> 00:38:16.396 align:middle and then you can use the file storage component of that. 00:38:16.396 --> 00:38:19.106 align:middle So the files will be near where they are used. 00:38:19.506 --> 00:38:27.266 align:middle So for sort of file sharing, file transferring, geo where use cases, 00:38:27.586 --> 00:38:28.966 align:middle you could use something like that. 00:38:29.806 --> 00:38:35.826 align:middle For more cluster stuff, you can use Gluster FS and you can use 00:38:36.096 --> 00:38:41.386 align:middle or have a Gluster FS cluster running on Kubernetes 00:38:42.046 --> 00:38:49.336 align:middle and if you have Gluster FS running there, you can also create a persistent volume on top 00:38:49.336 --> 00:38:52.456 align:middle of that Gluster FS cluster and Kubernetes. 00:38:52.846 --> 00:38:55.396 align:middle And then you can have a service on Kubernetes 00:38:55.456 --> 00:38:59.876 align:middle that consumes a persistent volume on Gluster FS on Kubernetes. 00:39:00.716 --> 00:39:06.726 align:middle So that becomes really complex and as you can see, a, it's now a arrow up, 00:39:06.756 --> 00:39:10.296 align:middle which coincidentally also is the direction 00:39:10.296 --> 00:39:14.316 align:middle of where the complexity is heading or maybe not do that. 00:39:15.776 --> 00:39:19.426 align:middle So last question, what do I do? 00:39:20.696 --> 00:39:26.386 align:middle Well, it still depends, but I think with all these questions and all these things 00:39:26.386 --> 00:39:33.156 align:middle that you now can think about, I think we are able to make the wrong decision the right way. 00:39:33.786 --> 00:39:36.916 align:middle I hope I have convinced you and if not, I hope you enjoyed this talk. 00:39:37.776 --> 00:39:48.676 align:middle Thank you for listening.