What is cloud?
The jargon of the moment is the cloud. People have different definitions of cloud, where it begins or ends are some of the questions that arise. Whatever “cloud” solution we talk about, a definition that everyone seems to understand is the concept of scalability. It is a very simple concept to understand, but difficult to apply. The more scalability, more chances you have to grow and bear a greater burden. No scalability, you can be caught flat-footed and not account for everyone who wants to access the content, or consume your product or service.
Why use the cloud?
We all use software wanting to make business successful. But that success involves a multitude of people accessing your site. And this crowd of access can be predetermined (you appear in some TV show or the home of a large portal) or suddenly you viralize. Regardless of form, have a scalable site is the difference between settle once or break. Other factors such as access log can help you adjust resources so that you do not pay more for periods of poor access.
Differences between horizontal and vertical scalability
There are two main types of scalability: Horizontal and Vertical
We will not talk much about vertical scalability because there is much to talk about … You just buy the more powerful hardware. There are famous programmers, who recommend this technique and it makes sense. Lose days or weeks of one or more developers to write scalable code is much more expensive than buying a high-end server.
The problem is that, at some point, the most expensive servers will no longer handle the load. Then it’s time to think of horizontal scalability. This is a solution that is already applied for databases, which can be configured in cluster with master / slave server, for example. The concept is also simple: you have multiple servers sharing the load.
Today there are several robust solutions for you to put your site up and enjoy horizontal scalability. Products such as Google Cloud Platform manage your site, add more servers will free you from the drudgery of having to manage infrastructure, in addition to having to manage your product. However, it is very important that your site is prepared to scale horizontally before leaving hiring a cloud service. Otherwise, you run the risk of seeing investment yielding less than it could.
How to leave my scalable site
OK, enough blah blah blah. I will try to be as generic as possible and spend on concepts that can be checked and applied to websites made in all languages.
- Localhost Is Your Enemy
Imagine that on your site, you get an image or process some information and guard the disk. Then you return to the user at some other time. This works as long as you have a server only, but when the number of servers increases, you cannot guarantee that when you deliver the content to the user, the responsible answer machine is the same as that received the file where the data was written. You can avoid this in a few ways: using a shared file system, recording information in a database or using an external service such as Cloud.
Because of your site to be dynamic, have a lot of people accessing the same page will cause it to generate the same data over and over again. Caching server side is an alternative to it. If your servers share a Memcached cluster, its cargo as well as being distributed, shall be reduced, for the first page to generate the records and the other only pass on the information already generated. Caching is an interesting topic, I will leave to address better in a future article.
PaaS solutions usually take care of scalability from the database for you. All we have to do is point to the database and the cache server is indicated by the service and is ready.
- Asynchronous Processing
Imagine that you need to generate a PDF, processing a spreadsheet; make a payment of credit card. And these variables are beyond its control and may take several seconds or minutes. Holding an open connection during this time can be catastrophic for your product when you have a lot of people in line wanting to do other things.
A solution to this is to have one or more private servers for asynchronous jobs. Instead you receive the parameters, process it all and return right away, you can receive the parameters and queue for this to be running in the background.
The user gets a code or protocol and uses to check the status of the process. When the work is done, releases a link or update a status on any record. The advantage of this technique is that you can have a big load, that instead of getting out of breath, you will take longer to process all items in the queue. Each language and environment has specific tools for this. Ruby has Sidekiq and Java has HornetQ, for example. Another great advantage of this technique is that you can have your site in one language and its workers in another. As long as they talk to the same database and / or the same web-services you are free to optimize / refactor / rewrite the parts separately.
Scalability is a very broad topic and very sensitive too. We can prepare ourselves in every way that we imagine and still be taken by surprise in a part of our system that seemed harmless.