High Availability Scaling with Share Nothing Architecture
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Kraal, John
John Kraal - High Availability Scaling with Share Nothing Architecture Scaling a project to a worldwide scale with the same performance and availability in every region using Python isn’t easy, but with the right mindset and tools it’s a very viable target. - We will discuss methods of delivering software, with automated scaling systems, building units out of your project to manage separately and how to reliably and securely distribute data to separate clusters, and how we have achieved this with the use of Celery, Redis, Databases, Protobuf and other modern tools, whilst making sure to highlight our pitfalls and successes
 make me itself. 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, shared nothing means nothing more than sharing no resources. So, all you do is make sure that everything that you run runs 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 it 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, 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 service at where they are. Also, it's very resilient against outages. A good example for this is, for example, Netflix, who made their own Chaos Monkey thing. Who else ever use 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, will be in the state of the 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. Any time 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 can build an application that just does what it does. Welcome. But the best thing about smaller applications, as you're probably 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 get to a certain point where it's useful to use. It does have some considerations. You're going to be simplifying your code base. You're going to make smaller, simpler applications. But if you oversimplify, you're going to make a problem larger instead of smaller. If you do crazy things like have an entire Python application, you make every function a salary task. Everything is going to be slow as balls because it's only communicating over the network with your back end 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 going to 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 going to need a whole bunch of servers. You need something to manage your traffic. You're going to need something to relay messages. You're going to 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 going to 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 still require a source of truth. I know that databases are one of the origins of shared nothing, but it's also, it's a key as you will 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. This goes for your databases, but also for your caching layers, for example. So, where would you be using shared nothing? I know two very good examples of a shared 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 cooperation with each other and, as I said, it's very scalable. Obviously, data warehousing is also an option by virtue of sharding your data. I'm going to skip that one, but I wanted to list it because this is where it all came from. So, what are you going to need to build it? It's an empty slide because I'm sharing nothing. Anyway, first you're going to ingest the traffic. You're going to get traffic from your clients, your users. They need to get to your application. So, it's basically your low balancer 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 frontend application. This does nothing more than get your request, hacks it into pieces, and determines 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 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. We run it on Redis, for example, but you could also be deploying it on RabbitMQ or any other things. I heard somebody talk about OpenRQ recently. Maybe that's one, too. I've injected out yet. And then in the end, you end up with a whole bunch of servers on the rear of your application stack and it's the backend 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 read. So, this is a bit abstract, so I want to give you some examples on 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 log 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, you go to the front end application, that decides, okay, I'm going to render this template and give it back. Nothing else is needed. Obviously, there is some backend stuff going on like storing your session key in the database or in the Redis 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 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 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're 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 backend processing. So, there we use the entire stack. So, in this case, the front end application would tell the backend 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 asks the server to generate a thumbnail. Then, it generates a web version. It generates any other type of image that we requested that it should do. And, of course, our application is fantastic. So, you can configure all those things. But, it is asynchronous. It goes back from backend processing to the message queue, then goes back to backend 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. Yep. 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 can 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 balancer of 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 in the back are all our processing things. We've only drawn six boxes, but there's a lot more. And, obviously, because we're pretty cool guys, we do this all with automated deployment for our DevOps people. That's actually a thing I forgot to mention. One other pro of doing this kind of system is that your DevOps people get a lot more Jenkins jobs to do, which they apparently like. I'm going faster than I thought. That's okay. So, in the future, because scaling is still a thing that you need to do. Shared nothing remains extremely effective, especially with all the tools that you have from Amazon, for example, or Google, or OpenStack 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, 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. That also works. I'm not a fan, though, because I like getting my fingers dirty with system operation things. So, I stick with shared nothing. However, serverless architecture, if you can get into it, is a fun thing to check out. Now, this guy just pointed the five-ten minute plate at me, but I'm actually at the last slide right now. Thanks. Short to the point and very efficient. I love it. First question here. You mentioned that you use Celery to distribute the tasks that have to be done. How do you integrate to have a synchronous execution with serving requests, which need to maintain connections, it's easier. You mean that when you do a Celery request, you got to wait for the results to come back to you? Yep. We try to avoid that kind of system, purely because when you are doing that, 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 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 room, a room in push to communicate back with your client or something, as an idea. And I have a question about the broker you are using for Celery. Can you give me a little bit of details? About the different brokers or what have you found about it? So, you're asking what kind of different brokers there are, right? What are you using or why are you using the broker you are using? Because I have very similar architecture in my project, and I'm 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 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, a thing like Rebit 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 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 prize for that. So you have mentioned that you use Amazon as a backend. Have you actually tried any other cloud provider? Like Google Cloud or Azure? Yes, we tried. Internally, we're looking at getting into Opus Tech just for our 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 look around. We see what's going on and we use some other providers that I'm not liberty to say to use certain things from. For example, your backups, you wouldn't keep those at the same location as your production clusters. So that's where we go elsewhere. Just out of academic interest, though, we try to play around and see if we can deploy on other things whenever we go. Any more questions? Fine. All right. Well, then that lacks us. And nice and early. So you've got to wait. Wait, wait. There is. Ah, brilliant. Here we go. Thank you, sir. Just again about salary. What kind of guarantees does it provide? I mean, is it exactly what every message is delivered and so executed exactly once or at least once? I don't know the gritty details. But I, as far as I understand, when you get a message out of there, at some point you have to sign it off as well. That the market is complete. I think that's a thing that salary manages for you. But I would assume that works. We can go to your drop messages at least. Any more questions? So I have one, I guess. Surprise. So, you know, you could go for an option 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 going to farm off that job to a salary queue. And then I can update the user when the bits are ready. You know, like, why bother? So, you know, that means you can scale your application server and your salary server 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, rather than having three application servers and 20 salary servers, why don't I just have 23 application servers, I can still do all the client-side kind of things. And I can do that by using individual view. 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 to 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 what it is to do. If you say, I'm going to put everything in the application server, you'd 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 just pull them apart. And when you ask a thing, say, can you say A? And it says A. And it will never say B. Okay. Does this help? Actually, on more, you can, it was to continue his answer, you can optimize services. So for example, if you have a Cping service, if you have everything in the same application, you would have to, for example, if you are using Python for everything, you either have to go with C binaries. But if you could actually change the backend and say, this is the other service, it's 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's spent loads of time preparing his slides. In that case, thank you.
 make me itself. 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, shared nothing means nothing more than sharing no  resources. So, all you do is make sure that everything that you run runs 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 it 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,  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  service at where they are. Also, it's very resilient against outages. A good example  for this is, for example, Netflix, who made their own Chaos Monkey thing. Who else ever  use 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, will be in the state of the 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. Any time 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 can build an application that just does what it  does. Welcome. But the best thing about smaller applications, as you're probably 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 get to a certain point where it's useful to use. It does have  some considerations. You're going to be simplifying your code base. You're going to make smaller,  simpler applications. But if you oversimplify, you're going to make a problem larger instead  of smaller. If you do crazy things like have an entire Python application, you make every  function a salary task. Everything is going to be slow as balls because it's only communicating  over the network with your back end 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 going to 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 going to need a whole bunch of servers. You need something  to manage your traffic. You're going to need something to relay messages. You're going  to 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 going to 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 still require a source of truth. I know that databases are one of the origins  of shared nothing, but it's also, it's a key as you will 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. This  goes for your databases, but also for your caching layers, for example. So, where would  you be using shared nothing? I know two very good examples of a shared 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 cooperation with each other and, as I said, it's very scalable. Obviously, data warehousing  is also an option by virtue of sharding your data. I'm going to skip that one, but I wanted  to list it because this is where it all came from. So, what are you going to need to build  it? It's an empty slide because I'm sharing nothing. Anyway, first you're going to ingest  the traffic. You're going to get traffic from your clients, your users. They need to get  to your application. So, it's basically your low balancer 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  frontend application. This does nothing more than get your request, hacks it into pieces,  and determines 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 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. We run it  on Redis, for example, but you could also be deploying it on RabbitMQ or any other things.  I heard somebody talk about OpenRQ recently. Maybe that's one, too. I've injected out yet.  And then in the end, you end up with a whole bunch of servers on the rear of your application  stack and it's the backend 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 read. So, this is a bit abstract, so I want to give you some examples on 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 log 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,  you go to the front end application, that decides, okay, I'm going to render this template  and give it back. Nothing else is needed. Obviously, there is some backend stuff going  on like storing your session key in the database or in the Redis 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 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 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're 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 backend processing. So, there we use the entire stack. So, in this case, the  front end application would tell the backend 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 asks the server to generate a thumbnail. Then, it generates a web version.  It generates any other type of image that we requested that it should do. And, of course,  our application is fantastic. So, you can configure all those things. But, it is asynchronous.  It goes back from backend processing to the message queue, then goes back to backend 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.  Yep. 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 can 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 balancer of 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 in the back are all our processing  things. We've only drawn six boxes, but there's a lot more. And, obviously, because we're  pretty cool guys, we do this all with automated deployment for our DevOps people. That's actually  a thing I forgot to mention. One other pro of doing this kind of system is that your  DevOps people get a lot more Jenkins jobs to do, which they apparently like.  I'm going faster than I thought. That's okay. So, in the future, because scaling is still  a thing that you need to do. Shared nothing remains extremely effective, especially with  all the tools that you have from Amazon, for example, or Google, or OpenStack 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, 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. That also works. I'm not a fan, though, because I like getting my fingers dirty with  system operation things. So, I stick with shared nothing. However, serverless architecture,  if you can get into it, is a fun thing to check out. Now, this guy just pointed the  five-ten minute plate at me, but I'm actually at the last slide right now. Thanks.  Short to the point and very efficient. I love it. First question here.  You mentioned that you use Celery to distribute the tasks that have to be done. How do you  integrate to have a synchronous execution with serving requests, which need to maintain  connections, it's easier. You mean that when you do a Celery request, you got to wait for  the results to come back to you? Yep.  We try to avoid that kind of system, purely because when you are doing that, 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 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 room, a room  in push to communicate back with your client or something, as an idea. And I have a question  about the broker you are using for Celery. Can you give me a little bit of details?  About the different brokers or what have you found about it?  So, you're asking what kind of different brokers there are, right?  What are you using or why are you using the broker you are using? Because I have very  similar architecture in my project, and I'm 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 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, a thing like Rebit  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 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 prize for that.  So you have mentioned that you use Amazon as a backend. Have you actually tried any other  cloud provider? Like Google Cloud or Azure?  Yes, we tried. Internally, we're looking at getting into Opus Tech just for our 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  look around. We see what's going on and we use some other providers that I'm not liberty  to say to use certain things from. For example, your backups, you wouldn't keep those at the  same location as your production clusters. So that's where we go elsewhere. Just out of  academic interest, though, we try to play around and see if we can deploy on other things  whenever we go. Any more questions?  Fine. All right. Well, then that lacks us. And nice and early. So you've got to wait.  Wait, wait. There is.  Ah, brilliant. Here we go. Thank you, sir.  Just again about salary. What kind of guarantees does it provide? I mean, is it exactly what  every message is delivered and so executed exactly once or at least once?  I don't know the gritty details. But I, as far as I understand, when you get a message  out of there, at some point you have to sign it off as well. That the market is complete.  I think that's a thing that salary manages for you. But I would assume that works. We  can go to your drop messages at least. Any more questions? So I have one, I guess.  Surprise. So, you know, you could go for an option 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 going to farm off that job to a salary queue. And then  I can update the user when the bits are ready. You know, like, why bother? So, you know,  that means you can scale your application server and your salary server 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, rather than having three application servers and 20 salary servers,  why don't I just have 23 application servers, I can still do all the client-side kind of  things. And I can do that by using individual view. 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 to 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 what it is to do. If you say, I'm going to put everything  in the application server, you'd 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 just pull them apart. And when you ask a thing, say, can you say A? And it says  A. And it will never say B. Okay. Does this help?  Actually, on more, you can, it was to continue his answer, you can optimize services. So for  example, if you have a Cping service, if you have everything in the same application, you  would have to, for example, if you are using Python for everything, you either have to go  with C binaries. But if you could actually change the backend and say, this is the other  service, it's 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's spent loads of time preparing his slides. In that case,  thank you.
John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_0_179.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_180_455.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_456_1355.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_1356_6695.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_6696_7319.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_7320_7535.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_7536_8831.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_8832_9599.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_9600_10091.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_10092_10331.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_10332_10403.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_10404_10475.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_10476_10775.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_10776_11003.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_11004_11831.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_11832_12263.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_12264_12635.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_12636_13763.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_13764_15383.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_15384_15935.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_15936_16403.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_16404_16967.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_16968_17183.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_17184_17807.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_17808_18275.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_18276_18755.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_18756_20039.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_20040_20171.png John_Kraal_-_High_Availability_Scaling_with_Share_Nothing_Architecture_20172_31226.png