 So, anyone came to our boot? Maybe? Don't think so. Okay, it's fine. Anyone uses any cloud service provider, Amazon, RecSpace? Just one, two, maybe? Why are you so unsure? So, anyone uses Docker? Do you like containers? Why? Sorry? Containers are not new, by the way. I know about personal space in Linux kernel starting from 20 and 00. Okay, so Docker is a new way? Yeah. Just a new package? Yeah. For 15 years old technology or something like that? Yeah. Docker is about content, not about containers. Exactly, but why are they selling it as a container technology? So even if the Google lady was like, the containers are the great new thing and he was confused about what the container technology is and what the packaging technology is. So it's kind of interesting. So, okay, let me come to that later. Because I have a slide which looks pretty much what the... There was pretty much like the Kubernetes, and I spelled it correctly. So it was pretty much like that, so you will notice it. And we can discuss it if you have any questions when we get there. So any system administrators here or are all of you developers? Just one? I see you, man. Okay. So I can rant anything I want about system administration and not worry. Okay, that's good. I can start whenever you want. Okay, I started. Yes, Roy. So our speaker, Roy, will be talking about preparing apps for dynamic scaling. Let's welcome Roy. Okay, thank you for coming. And my name is Roy, and I'm like the head of business development for... Okay, it's coming back for Sky Atlas. And I'll be talking about preparing your applications for dynamic scaling. So first of all, the outline, so why I'm making this talk, why this idea of dynamic scaling or scaling your systems automatically is important. And then, what is dynamic scaling? And after that, we will check if your app is already ready for that, and then I will take questions. If you have any questions about the slide, just interrupt me and ask, and then we will discuss. So how do you scale your applications now? Any idea? Anyone has tried to scale an application? What do you do? Yeah, you just put more servers, right? You scale horizontally, and you add more and more servers in order to meet the demand. So does this really work? I mean, when you're scaling horizontally, you have a server which is using like 90% of the CPU, and when you add a new one, what you do is that you are decreasing the user trait of that one server to 50%, and then you add another one which is again used like 50%. So there's a waste of 50% of CPU power where we are not using. And when you increase the amount of servers you put there, you just create more wasteful resources. So why are we not trying to optimize it? We always see that, okay, adding more resources. It's kind of like brute force solution, right? There is no finesse in there. It's like, yes, we have a problem. We cannot meet the demand. What do we do? Put more servers on it. So does this really work? So anyone using Amazon? So if you know that you put more and more servers and your bill will get crazy, right? And this all these paying is for some resources you are not really using for, because you are wasting it. And there's, of course, a load balancer which is standing before your servers, which you have to pay for it as well. So what we want to do is, in this talk, is to create an awareness that you are troving away your money, troving away your resources, instead when you add more servers. Instead of adding more servers, creating more computing power, we believe that you have to utilize those better. Remember the Kubernetes slides. What they were doing that was kind of renting CPU powers for your applications, right? So it kind of makes sense, right? I mean, when someone is not using some kind, so we can give those to some others. But what the Kubernetes does is that it's a platform as a service. So you try to add an internal module to the cloud platform. You can't because it's container-based. So what we believe that you have to utilize your servers better to make the world a better place. Anyone watching Silicon Valley? Damn, okay. So now I look funnier than the slide, right? So I have the YouTube link, so maybe you can watch it, and then it will make sense for you what I have just put there. Okay, sorry. And, okay. So what is dynamic scaling? Basically, it's an automated and optimized way for scaling servers vertically. Anyone know about vertical scaling? Good. So it's very similar to, let's say that you have a general application and you are running it on a one CPU and one gigabyte of RAM. So more users are coming. So what do you do? What is the basic instinct of doing when you want to get more power? Sorry? Bigger server. Yes, bigger server. That's what you do. You scale vertically. But you shut down the server and other kinds of things. So it's not very feasible and requires manual things and other kinds of things. So when you build your, and it's very similar for all kinds of websites. So, and when you build your infrastructure, you plan for two things. Either for the maximum capacity where your users are coming and other kinds of things, or you plan for optimum capacity. So sometimes some users will not be able to get responses, but then I will say costs, which I'm not able to use. So you see that there are some lots of spaces where it's underutilized. So if there was a third way of planning your infrastructure, it wouldn't have been nice. I mean, what if you were able to plan your infrastructure dynamically based on your load? So remember the Kubernetes presentation. This was very similar to what they have shown, right? The idea of better utilizing your server infrastructure. What they were doing is that as they are past platform, they were just doing this for processes. And we are doing this for servers. So not just a single application that gets this performance boot, but also your OS. So dynamic scaling is actually the way of scaling up instead of scaling out. Just like the way we have talked earlier, the horizontal scaling way. You add more servers when you scale out, but when dynamic scaling comes in, you just scale up or down if, let's say, no more resources are required or your customers are leaving the website to go to sleep or when they come back, you get more. So any questions so far? Does that make sense? Because this, like the fifth to six minutes of this talk, which is the really important one, which I should get you going. So you have to better, I say again, you have to better utilize your servers. Okay. So are you ready? Is your app ready for such a change? So first of all, is this a change? Do you believe that this is something you are not doing already? So the answer is probably you already are ready because you already do put your current application to a more powerful server, and you can just keep going with it. So the best thing about scaling vertically is that you don't have to change your software infrastructure for that. I mean, let's consider a way, when you want to put another server, when you want to scale horizontally, what do you do first? Anyone tried that in Amazon, let's say. They are providing something called autoscaling. Has anyone tried that? The first thing you do is to put a load balancer before your servers. So there is no thing of going one server to two. You have to go from one server to at least three in order to be able to scale because there should be a load balancer before your servers so that these load be distributed. So when you get these, so you probably handle these things related to the load balancer in your application, right? Because he is directing you the traffic. If you are using HTTPS, then probably the load balancer will come from HTTP. So you get to remove the address from the real user. You will have to use HTTPX forwarded for something like that, or maybe you will be just hacked the load balancer or something like that. And let's consider what will happen if one user will come to one server and then be redirected to the another one. So you have to find a way to share your sessions, right? So has anyone done that? Okay, so it's kind of a tricky. So you can use sticky sessions or other kinds of that. That looks fine, but when someone attacks to that, then it will just take down the server and the other one will go up. So it takes a lot of effort for your application to be scalable in a horizontal way. It really takes a lot of time, a lot of effort, and a lot of trials. And in vertical scaling, you're already ready because it's not very different than deploying to a machine which has just more resources or something. So, well, if you're using Apache HTTP, G Unicorn, you can probably use dynamic scaling because, as I mentioned, well, what dynamic scaling does is that it just live resize your servers. One moment you have one CPU and one gigabyte of RAM, and the other moment you have three CPUs and four gigabytes of RAM, which is the requirement for your application. And when those requirements get slow, you go back to the one CPU and one gigabyte of RAM, and then you pay accordingly. So Python, PHP, it works pretty well. MySQL, PostgreSQL, they work well enough. And apart from that, the important part, apart from the technologies, the other applications where you are building your applications are also working well enough. We have made a test by using WordPress, which, okay, so, we have compared our dynamic scaling to Amazon's auto-scaling feature, and we get three times more TPS than the Amazon. Why is that? Because, as I mentioned, we are scaling your servers vertically, and in the auto-scaling part, you have to start another web server and then deploy your application. So what this does? Until the other web server goes up, you get lots of time for your, how to say, you lose your customers because you are not able to answer them. But in dynamic scaling, as vertical scaling is much easier, you already can. So, what you should be looking out for? So, are you like, when you're starting your application, are you checking the number of CPUs? Because it's something dynamic now. If you're just forcing yourself to be, to include yourself to a single processor, then you cannot use it. So, are you doing it? And another thing is the memory. So, is it a constant for you? Like, anyone remember, anyone knows Java's heap size? Okay, did you know that you can set a heap size that is bigger than your physical machine's memory? I mean, if you have a laptop which is like four gigabytes of RAM, and for the heap size, you can set 16 gigabytes. So, yes, if you don't increase the memory, your Java application will crash. But if you can, it won't. And, well, of course, there are some applications which doesn't work with that. Anyone heard of Cassandra? It crashes. So, because it just preallocates the memory, and then when this memory is not, like, there, and if it's most of the time it's there, but it cannot use it, because it thinks that sometimes, yeah, when it says 16 gigabytes, it just tries to take the whole 16 gigabytes before needing it, and it crashes. So, you have to make sure that, not using Cassandra, maybe. So, and as I mentioned, if you want to really take advantage of the dynamic scaling idea, you have to make sure that using are also compatible. As I mentioned, Apache HTTP works, MySQL works, but does the tool you're using is ready for that? I really do believe that even if they are not ready now, they will be ready in the future. Because, as with the cloud, computing evolves the way that compute resources will become more and more easy to allocate and to deallocate. Everyone is trying to work on these right now. So, yeah, they will come. So, you should be, think about those things as well, because when you're, let's say, that you're using Docker, and do you know that you can increase, you can make a library size of your Docker, let's not say Docker containers, but Lexi containers, you can library size them. You can add more CPUs, more RAM, and more disk to them without shutting that down. So, even if you're ready, even if you don't want to use Sky Atlas, you can use it on your current machine by setting up a Lexi container or a Docker container, and you can check that if your application is ready for it or not. And you can also try the possibilities. I mean, in your application, just like, well, we are doing it automatically, but you can do it manually. I mean, start a geometry application so that more users are coming to your container and at some point, just increase the resources. See how your application will react to that. So, this was all my talk, and just so that you might have in your mind, I have prepared some questions for myself so that I can answer them easily. And, okay, first question. Do I really need it? Yes. I mean, you don't need to do anything, probably, to use it. So, why are we not using it? I mean, in horizontal scaling, you have to put a lot of efforts in order to be scaled horizontally. But to scale vertically, well, you don't really have to do it. So, why not use it? So, another one. Okay, thank you, LibRoffice. Okay, now we have to go back to there. So, it's just to recap. I just programmed LibRoffice so that it crashes, and I give you a... And the much better way is that it crashed completely. Isn't that perfect? And it's... Yes, but it can recover. Okay, so how is this? Yeah. So, maybe LibRoffice is not ready for dynamic scaling, right? Okay. So, okay. How is this different than AWS automatic scaling? Does anyone know automatic scaling? Okay. So, it's different because we are not scaling horizontally. We are scaling vertically. So, you don't need a load balancer in front of your servers, and you don't need to change your application in order to support a distributed system. How about Kubernetes? The Google lady who taught this today. They are providing a Pa system. They are just giving you a platform where there are lots of limitations. And if you are not doing your application their way, you cannot really use their application. You cannot really use their system. So, what we are doing is that we are providing an IES system. So, you get a virtual machine that can scale vertically, automatically. Not a Pa system where you just get a process. And I guess that's one of the most important parts. So, the question is, dynamic scaling is not an alternative to horizontal scaling. It's complementary. I mean, there will come a time when 30 CPUs will not be able to handle your requests. Or they will come a time where you will require high availability, business continuity. So, you will need to handle distributed systems at some point. But you can use it with dynamic scaling. Remember my first example. When you just spawn a new server, what the 90% of the CPU was degraded to 50%. So, if you ran dynamic scaling on both of them, the moment that will be automatically scaled will be the point where everyone gets to 80%. So, you better utilize your resources. And, yeah. And this is my talk. Thank you for listening. And if you have any questions, please ask. Thank you, Matt. Horizontal scaling is more about stress resistance than about... Sorry. I don't understand. Sorry. Horizontal scaling is more about stress resistance than about scaling. Stroke resistance? Stress resistance. Stress resistance. Yeah, yeah. If you have a broken slave, you just switch to another slave, right? In this case, it's better to create some small slaves. Small amount of slaves. That's two big slaves. Because if you just grow only one or two slaves, and one of them will crash it, you have more problems that crash of small slaves. Yeah, but I'm not saying that dynamic scaling is an alternative to high availability. As I mentioned, I mean, at some point of your application, you will require high availability. And it's not about automatic scaling as well. Putting two servers there, there can be a tourism. High availability might be one. And in those high available servers, you might be using 10% of the CPU. And you still get less than you pay for. But if you run dynamic scaling on them, then you will get what you pay for. Does that make sense? In my experience, dynamic scaling, it's more useful for databases, maybe, than the apps. Yes, it depends. I mean, it makes sense for applications, for me at least, because most of the applications require more CPU and RAM from time to time. And when your users are coming more, consider an e-commerce website. So your application server will require, will get lots of requests, and you will have to handle it some way. So that you buy more and more server power. But with dynamic scaling, yeah, I think there are some use cases, and there are some use cases where it doesn't work. Consider that you have a server farm where you are running a big data computational thing where all the time it's like 100% of the CPUs. So yes, it doesn't make sense then, because you are already utilizing all the CPU power you can get. And that's what dynamic scaling is about. Better utilizing the resources you have. Okay, thanks. Yeah, thank you. We can talk later if you wish. Is there any way with dynamic scaling or any kind of scaling to enhance IO access? Right now, no. We are mostly focused on CPU and memory, and IO is dependent on two things. One of them is the ephemeral storage, which is most of the time it's an SSD, and some for other parts of things, it's the network attached. We can say that block storage, EBS or something similar. We are not increasing it, not right now. Okay, thanks. More questions? Comments? I talked pretty well and convinced you, I guess, as you have no more questions. If no, it's lunchtime. Please come visit me if you have any questions which you are shy to ask here. So then we can talk. Okay, thank you. Thank you, Roy.