In the article «What does having a database in the cloud mean?» we looked at the biggest technical differences between running a website on an ordinary computer and running it in the cloud.
One of the most important points was that in the cloud you have access to different services and systems that can free up technical managers from manual work. Instead of installing database software on a computer, doing a lot of configuring (think security, stability, performance), and then ensuring that it remains live, you could use a database service in the cloud and thereby avoid these common and time-consuming tasks associated with setting up a database. We also looked at what it would mean to use cloud solutions for storage and serving of media files.
Once you take the step into a cloud-based website, it’s not just the database and media files that get handled better – the website itself gains advantages. In this article we will look at how and why cloud solutions handle both higher and lower traffic better, which is a big selling point for cloud solutions. As in the previous article, I want to try to make it intelligible to people who want to take a peek into our world, while at the same time weaving in a few technical details for those who like stuff like that.
Better utilization of resources
For a website to be able to exist there has to be a computer for it to run on. You need a CPU and RAM, to perform the actual calculations that are required for a website to appear in your browser, and to have a notebook while these calculations are happening, respectively. Central Processing Unit (CPU) and Random Access Memory (RAM) could also be called processing power and memory. So, with that out of the way: what changes in the cloud?
This section could also have been called «better use of my money», because it’s about that as much as anything.
Memory and processing power cost money. Can we not just use exactly as much as we need?
Absolutely. But we have two challenges:
- How much do we need?
- What do we do when we need more or less?
If you look round a bit online for hosting solutions you will quickly find out that the price models are often based on how much juice (read: processing power and memory) your website needs. A website such as YouTube demands much more of a computer than a blog does, so it makes sense that you can’t go to a supplier and buy a computer that can handle a thousand users a minute for a fixed monthly price. So to answer the first question: we have to know how much power the website requires for it to be viewed in a web browser, in addition to knowing how many users will be using the website at any one time. Since the users obviously don’t agree between themselves when they are going to visit the website, but just pile in sporadically in groups at the same time, this is difficult to estimate.
But let us say that we hold up a qualified finger into the air to see which way the wind is blowing, and start with one CPU and a partition with memory – despite all this is fairly easy for new websites when you don’t know all that much about resource requirements. Once we are up and running with the website, we can see where we are with regard to resources. Initially we use barely any resources, because we don’t really have much traffic. After a week we use nearly all, and the website has begun to be a bit slower to load. It looks like we need more resources, so what now?
If you don’t have enough power (CPU and RAM) you have add a bit if you don’t want the website to be sluggish. If there is no more that can be added, previously you had to run the website from a new computer. Either the new computer has a lot more resources, so you can turn the old one off; or you can run them both simultaneously. If you had not planned for it to be possible for the website to be run from two places simultaneously, it could happen that you suddenly have a logistical challenge. In any case, this process is time-consuming and not completely idiot-proof, so it involves some coordination and perhaps a late night for a successful choice so that the website will not be unavailable in the middle of the day.
But let us say that «scaling up», as we call it when we increase resources, went well. If the increased need was short-lived and now you are only using half the resources, you are paying more than you need to. You have to scale down again. You might switch off the extra version you added a little while back, or you might move the website to a new computer with less resources. It’s just as much work this time. And if the technical aspect wasn’t demanding enough, you perhaps might have had to commit to one month or more when you purchased more resources from your supplier.
To make a long story a bit longer, there is always more work involved in trying to make sure that a website has enough resources and yet not too much. If you are thinking that got complicated then I recommend you read on, because now we will look at how we solve this problem in the cloud!
Automatic scaling in the cloud
In the cloud there are three elements that change the picture for the website:
- You can ask for more or less resources without «moving» the website,
- you pay for precisely what you use,
- and there are systems for helping with scaling
Let’s have a look at what these three things mean for us.
If you need more power, it is generally easy to adjust it. Services such as Google App Engine and Google Kubernetes Engine have control panels where you can press a few buttons to say that you want to have more or less CPU and RAM. There are exceptions, but basically scaling up or down should be possible without any downtime.
When you ask for a bit more, you pay a bit more, and when you ask for a bit less, you pay a bit less. There is no commitment, and you can adjust up and down as you wish. If you used 1 CPU for 100 seconds, and then 2 CPUs for 200 seconds, you pay for 300 seconds. This means that if you are good at scaling down as soon as your resource needs lessen, you can save a fair bit of money.
Instead of tracking what resources the website is using, we have tools that can tell when the website should be scaled down. These tools can, for example, inform an administrator of that by sending an email or a message in a chat application. But even better: they can ask the system to scale the website automatically. Google App Engine, which I mentioned above, is a system that can make sure the right amount of resources are available, completely automatically. Not too much, and not too little.
The same applies to Google Kubernetes Engine and Google Compute Engine. For those who don’t have to administer them, it’s not that important what these services are called, but it’s really good to know they exist, and that they can help you, both by saving money and by dealing with increased traffic without you needing to commit to a month with excessive resources.
Now we can have another go at answering these questions:
- How much resources do we need?
- What do we do when we need more or less?
We’ll start with question number two. The answer is of course that we scale. Preferably automatically. And if we can do that, we don’t actually need to answer the first question.
It’s a bit of an anticlimax to talk about resource use in the cloud, but in fact it was also a large part of the premise for cloud solutions from the very beginning: there shouldn’t be any anxiety associated with resource adjustments in the cloud; it’s the most natural thing you can do.
Finally I would just like to mention the financial aspect of the price model you get with all major cloud services providers. It is easy to keep an eye on how much money you have spent with Google Cloud Platform. It can be more difficult to estimate how much you will spend. It is possible an article on this will appear at some point, but if you order an assignment through Symfoni Next we have experienced consultants to help with that.