Throughout the last few months, the most typical request of vshosting~ clients has unanimously been horizontal scaling. Let’s take a look at what this requirement truly represents and where it comes from.
It’s important to mention right from the start that nowadays, horizontal scaling is often required mostly for business reasons. The technical side typically lags behind. In addition, in more than one instance, horizontal scaling is a requirement that shouldn't be a priority for the application operator.
Horizontal vs. Vertical Scaling
Scaling can be either vertical or horizontal. Vertical scaling has been here with us for many years and, simply put, concerns increasing the output of a given server (be it physical or virtual) or container. It is the easiest way to provide more computing resources for that given app.
A disadvantage of this method is primarily its limitation (the server output cannot be increased infinitely). The answer to this drawback, at least theoretically, is horizontal scaling. That allows for parallel additions of independent computing capacities and distribution of load among these capacities - infinitely in an ideal case. From the point of view of scaling a business, this sounds amazing. However...
When it comes to extensive applications with the vision of rapid growth, horizontal scaling truly is the only option to ensure maximum scalability. Nonetheless, it is still more advantageous for many services to scale vertically rather than horizontally (e.g. load balancers, etc.). Unfortunately, many platforms (such as AWS) to this day force the user to choose from pre-defined packages of processor and storage capacity. At vshosting~, we consider this to be an anachronism.
Cloud platforms and hosting should be able to dynamically adjust to the real needs of concrete computing resources of each and every client. In other words, every time a client needs to increase their application output, they should have the option of simply adding x amount of storage and y number of processors without having to go through an elaborate investigation into which of the offered “packages” is most appropriate for them at that moment.
Horizontal Scaling Stumbling Blocks: Practical Experience
As we have already mentioned, in some cases, not even the option of dynamic vertical scaling remains sufficient and horizontal scaling thus becomes necessary. However, it pays off to thoroughly consider whether this really is the case. No matter how attractive horizontal scaling may seem in theory, it clashes with multiple conceptual disadvantages in reality.
First of all, horizontal scaling puts pressure on developers to create applications that are prepared for parallel operation and task fulfillment. We know from experience, that writing such applications is much more demanding on developer knowledge, time, and testing (and, as a result, on finances).
Furthermore, the limitations of external services need to be taken into account. Typically, the biggest complication arises in the event that the application meant to operate in a parallel mode uses a shared filesystem. Scalability is then reduced for the entire application simply due to the way this decades-old technology operates (object storage would be a suitable replacement). Even cloud platforms or infrastructure built on a distributed solution (e.g. GlusterFS) sooner or later run into the limitations of the technology used, that tend to be very difficult to overcome during operation.
Another problematic aspect is usually relational databases that also due to their conceptual design don’t account for being clustered. Technology in this area has advanced significantly, for instance, we have a great experience with MariaDB Galera Cluster - we have been successfully operating the Shoptet platform for tens of thousands of e-shops on it. From this point of view, it is a more advanced solution than what Amazon offers with AWS Aurora.
AWS Aurora only allows for horizontal scaling using so-called “replicas”, which are read-only replicas of one database instance. It is, therefore, a very limited form of horizontal scaling that loses its meaning this day and age because by limiting the operation from a relational database (to make the application more horizontally scalable), especially read operations are limited - for the offloading of which, tools such as ElasticSearch are used. These tools, on the other hand, are very easily horizontally scaled but aren’t in principle suitable for storing data of key importance.
Read-only replicas are once again a decades-old mechanism that we don’t consider to be a suitable technology for horizontal scaling. That is the case primarily because this method cannot ensure 1:1 scaling for all operation types. AWS offers no alternatives for horizontal scaling of SQL databases.
Hassle-free Horizontal Scaling Thanks to vshosting~
We see the biggest issue with modern applications built for horizontal scaling in their complexity. This makes it difficult to predict which part of the application or its component will reach its limit.
At vshosting~, we assist our clients' developers in order to make their applications more easily and quickly scalable. We advise them which elements in their applications are or will become limiting for further growth and prepare individual, robust, and fully scalable infrastructure without compromises.
There is no point in reinventing the wheel: thanks to our unique know-how at vshosting~, we will let you know what to focus on when designing an application. We will prepare your project for global expansion, also thanks to our own CDN, which we’ll soon be launching on a third continent (Asia).
Damir Špoljarič
CEO & Co-Founder