 before we kick off though I want to thank my employer binder for making it able for me to be here and talk about this to you guys Yeah, so shared nothing Those are two words. What is it in essence? She had nothing means nothing more than sharing no resources So all you do is make sure that everything that you run once on its own CPU memory or disks You know any program that you have does that and that alone It became a very large thing back in the day. I think the first written thing about is 1983, which is older than I am But the good thing about it is that you can make separate units of programs so You can separate your concerns in a way that anything you write does its own thing on its own hardware and doesn't do anything else which is super useful Also, it makes you able to Scale things independently. So for example, if you run a website, you can deploy your own code in some way If you get a lot of requests on for example, just your HTML pages You can scale those servers up and leave the rest as it is Or if you do a lot of processing on the back end You can scale that up and leave the front-end surface at where they are Also, it's very resilient against outages Good example for this is for example Netflix who made their own Chaos monkey thing who has ever used chaos monkey? Okay, so if you've seen it you are probably well aware of how it can kill your entire network and your entire application But not if you set it up correctly And last but not least is loosely coupled So every little thing can die on its own and then it can be restarted and something will take the features over as it is More interesting though shared nothing doesn't mean you share nothing Lots of things still especially in the web sphere If you have a web application, you will be sharing state people will be locked in will be authenticated You'll be in the student state of a process workflows in your application will be Shared all over the entire thing and people don't generally do that in one request. So Every step you take you got to go on further and further And additionally to that because you have all these separate units of things everything depends on each other in some way So why would you do? shared nothing Easiest reason is as I said full tolerance anytime your application Has a problem it can deal with it itself your entire architecture is built to make sure that that thing can Get back to where it was or get back to a state where it will actually work It's scalable as I said you can scale independently and it leads to much more smaller and simpler applications Very good example for this is that you You can build an application that just does what it does welcome But the best thing about smaller applications as you're probably well aware well aware of is You can test them better. You can manage them better. You can review the code better You can do anything you want with the code that you have and you can explain it better to other people So also if you transfer the project or hire new people to work on it It's just much easier to to get to a certain point where it's useful to use It does have some considerations for You're going to be simplifying your code base. You're gonna make smaller simpler applications But if you oversimplify you're gonna make a problem larger instead of smaller If you do Crazy things like have an entire Python application you make every function the salary task everything is going to be slow as balls because It's only communicating over the network with your back ends and Hoping to get an answer at some point and then all your servers are doing nothing else but communicating to each other So that's not a good thing. Also, you need to know when you need to start if you're just making a web log like Any WordPress website or anything like that If you're gonna separate those things you're wasting a lot of time and you're not making Anything more useful than it really is Other than that you also require a lot of infrastructure Instead of just having one server that does what it is that you do you're gonna need a whole bunch of servers You need something to manage your traffic. You're gonna need something to relay messages You're gonna need something to do all the functions that you have and as I said before Because there are simple units simple smaller units you're gonna have Yeah, just a whole bunch of things that do their own thing you cannot share the server of any other feature that you are building So your login page server for example cannot certainly also do the Authentication if you do it in the wrong way And apart from that you're still sharing states, so you know still require a source of truth It's I know that databases are one of the origins of shared nothing, but it's also it's a kills you you'll be Storing stuff in there, and you'll not be able to scale that in the same way as you can do with your application That this goes for your database as well as for your caching layers for example, so where would you be using share nothing? I know two very good examples of a share nothing website one is Google I'm pretty sure you all know what Google is if you don't please raise your hand Or binder which is very work obviously Yeah, it means that skill it just means that we do a lot of things. It's everywhere. It's all over the world It's all working in Incorporation with each other and as I said, it's very scalable Obviously data warehousing is also an option by virtue of share sharding your data I'm gonna skip that one, but I wanted to list it because this is where it all came from So what are you gonna need to build it? It's an empty slide because I'm sharing nothing Anyway first you're gonna ingest the traffic you're gonna get traffic from your clients your users they need to get to your application So it's basically your low banter or any web server that you have I Want to make it more tangible so we got an example for this we use engine x When this gets the message it just passes it on to the application server Which we call the front-end application This does nothing more than get sure request Hacks it into pieces and the terms for itself what it wants to do and how it needs to do that so Because I'm branding things anyway, we use pyramid for this Pyramid is pretty awesome, but you could also use PHP or Node.js if you're so inclined or anything in go if you're Into those kind of talks today What it does though it it makes new tasks and those tasks need to be executed And the only way to get that done is to insert a message queue into the stack so There's a message queue it does nothing more than get the message and give it to somebody else. So For example, we use salary for this It's not necessarily just salary rerun it on Redis for example, but you could also be Deploying it on rabbit MQ or any other things I heard somebody talk about open RQ recently Maybe that's one to have injected out yet And then in the end you you end up with a whole bunch of serves on the in the rear of your application stack And it's the back-end processing this can be literally anything that can read messages from your message queue We use Python things we use go we use Java Anything that you cannot So this is a bit abstract, so I want to give you some examples and how we do things Here is a login page. This is our application. It's fantastically beautiful And you can log in so You don't need a lot to generate this so this is a very simple thing and the stack will basically look a bit like this You only go to ingest traffic we go to the front-end application that decides Okay, I'm gonna render this template to give it back done nothing else is needed Obviously, there is some back-end stuff going on like storing your session key in the database or in the readest thing and Making sure all those things are right, but You know, I'm just trying to keep it simple. I Also have a less simple example literally, I Uploaded a picture of my daughter and in binder And this is a slightly more complex operation I mean we've all probably made some web application where you upload a picture, but In our case we we store it directly on Amazon S3. So what we do is We have the web server for a token so that we can upload it to S3 then when we done we tell the web server that we're done and That moment it decides that it needs to check if the file is actually correct Or if the file is actually an image and not a video or I would like to know all the information That's in the accept data. That's in the picture That's all back-end processing So there we use the entire stack So in this case the front-end application would tell the back-end stuff Please give me everything back from this image identify it make sure it's really an image not a vulnerability or whatever When that's done it asked the server to generate a thumbnail then it generates a web version It generates any other type of image that we've requested that it should do and Of course our application is fantastic so you can figure all those things But it is it is asynchronous it goes back from back-end processing to the message queue then go back to back-end processing And it goes back to the front-end application In the end though you get a fantastic picture of my daughter in the application, which is what everybody wants So what you end up with in the end and this is the official picture that we share with people is this crazy architecture You could tell we're kind of deep into Amazon And I don't mind really But you can see that the entire stack is divided into a lot of things there's a lot of things going on and everything is separated For example, we use just the normal load balancers Amazon to relay the traffic that's our ingestion then we do some web application firewalling which is Also one unit doing the circuit things That relates traffic to the web instances that does some things and then there's a little error going up to a message broker and All the way the back are all our processing things We've only drawn six boxes with us a lot more And obviously because we're Pretty cool guys. We do this all with automated deployment for our DevOps to the people That's actually a thing I forgot to mention One other pro of doing this kind of system is that your devils people get a lot more Jenkins jobs to do which they apparently like So in the future Because scaling is still a thing that you need to do Shit nothing remains extremely effective, especially with all the tools that you have from Amazon for example or Google or Open stack delivers. It's super easy to deploy an entire shared nothing architecture anywhere in the world However, there's a new thing coming up called serverless architecture where you can essentially do a lot of things about Anything really just instead of deploying your servers and you're managing your own hardware or You're worried about CPU and memory. You can just deploy some code and that also works I'm not a fan though because I like getting my fingers dirty with system operation things So I stick with share nothing However, a serverless architecture if you can get into it is a fun thing to check out Now this guy just pointed the five term in a plate at me, but I'm actually at the last slide right now, so Thanks Short to the point and very efficient. I love it first question here You mentioned that you use a salary to distribute the tasks that have to be done How do you integrate and to have a synchronous execution with Serving requests which need to maintain connections, it's easier You mean that When you do a salary request you got to wait for the results to come back to you. Yeah We try to avoid that kind of system Purely because when you are doing that you You got to make something block in your entire stack and that's not the most efficient way to get there So what we try to do is we tell the user okay It's coming and then the front end application starts pulling or it gets a notification from okay. This is done Please pick it up. So you use no web circuits. Sorry. Do you use no web circuits or stuff like that? We could to give the message back at some point But I don't I don't really like having an open connection to a server that can die at any second so I'd rather go for long pulling or Server push More questions. Yes Thanks for the talk Maybe an answer for the previous question will be a push a room A room in pusher to communicate back with the with your clients or something as an idea And I have a question about the broker you are using for Saturday Can you give me a little bit of details about about the different brokers or what have you found about it? So you're asking if What kind of different brokers there are right? What are you using or why are you using the broker you are using and? Because if I have very similar architecture in my in my project now in dealing with that right now Okay Not really sure we use Redis because we like Redis a lot And we already have it available anyway But there are other brokers that then make a lot of sense when you're starting to scale up I Try to remove layers as much as I can but for example the thing like rabbit MQ is Very good to use if you want something With more control or if you want to say more things to the applications using it more questions How about up at the back? Exciting zone for questions usually you've got a little bit more of a contemplative stance standing a bit further back It gives you more of an opportunity to formulate an insightful or possibly a stupid question. There's prizes either way What about up the front? Okay question number two there's definitely a price for that And So you have mentioned that you use Amazon as a backend. Have you actually tried any other? Cloud provider like go cloud or Azure? Yes, we tried and internally we're looking at getting into open stack just for internal environments But for our production stuff AWS is very Useful to us. We are in a deep strategic relationship with them. So we're not going away from there But obviously we we look around we we see what's going on and we use some other providers that I'm no liberty to say To use certain certain things from for example your backups you wouldn't keep those at the same location production clusters So that's where we go elsewhere Just out of academic interest though We we try to play around to see if we can deploy and other things whenever we can all right any more questions Fine, all right. Well, then that likes us and nice and early so you've got to wait wait wait. There is brilliant. Here we go. Thank you, sir Just again about salary does What kind of guarantees does does it provide? I mean is it Exactly what every message is delivered and so executed exactly once or at least once what I? Don't know the gritty details but I As far as I understand when you just like get a message out of there at some point you have to sign it off as well That could mark us complete I think that's a thing that salary manages for you, but I Would assume that that works. We don't see drop messages at least Any more questions So I have one I guess Surprise so, you know You could go for an option like like you've done you can have a three layer architecture where you go Oh, I don't want to spend too much time doing loads of work in my application server I'm just gonna farm off that job to a to a celery queue and then I can update the user when the bits are ready You know like And one why why bother like why not so you know that means that you can scale your application server and your Celery servers separately, but at the end of the day you've still got to do that computation So what are the real advantages of saying okay? You know rather than having you know free application servers and 20 celery servers Why don't I just have through it 23 application servers? I can still do all the client side kind of polling by using individual due I mean I can upload my image in one view I can resize it in a different Ajax request I can request a thumbnail in a third Ajax request. I can request the metadata in a fourth one and so on The main answer that one lies in the simpler applications kind of thing So when you build a smaller simpler application, there's a lot less to check It's easier to verify. It's easier to test. It's easier to deploy and The function that you did just has one exact Responsibility and that is doing that what it is to do If you say I'm gonna put everything in the application server you suddenly have a whole large code base with Separate tracks to getting there making sure that the code operates well with each other You cannot build changes in one system that will have no effect on the other I Think it makes life simpler if you if you just pull them apart and When you when you ask a thing say can you say a and it says a it will never say be Okay, does it help? Actually on more you can it was to continue his answer you can optimize services So for example, if you have a shipping service if you had everything in the same application You would have to for example, if you are using Python for everything You either have to go with see binaries But if you you could actually change the back end and say this the other service is a specialised Written in assembly, and I don't have to maintain it, but it's super effective Any questions rather than answer to questions from the floor Anything else rack your brains everyone. Here's our speaker. He spent loads of time preparing his slides