Hi Friends,
Welcome to the 86th issue of the Polymathic Engineer newsletter.
This week, we discuss what does it mean to vertically scale a server and which are the possible ways of doing it.
This is the outline:
vertical vs horizontal scaling
how to scale vertically a system
limitations of vertical scaling
Vertical vs. Horizontal scaling
Scalability is the ability of a system to adjust its capacity to meet the demands of the current workload more efficiently.
For most people, scalability means that a system can handle more users, clients, data, deals, or requests without making the experience worse for those using it.
However, this is only part of the story. It's important to remember that true scalability also means meeting a decreasing workload when needed.
As the workload grows, you can use two primary approaches to scale your application: vertical and horizontal.
Vertical scalability, which is also called "scaling up," means making the server where your application runs more powerful by updating its hardware or making the network faster.
This method is often the most straightforward because it doesn't require changes to the application's design. All you need to do is replace hardware parts without changing the system's structure.
On the other hand, horizontal scalability, which is also called "scaling out", means adding more servers to your system to spread the work across them. This not only makes the system able to handle additional workload but also makes it more resilient to failures.
In the following section, we will see in more detail how to vertically scale a server and which are the limitations of the vertical calling approach.
How to scale vertically
A server can be scaled vertically by upgrading the hardware and/or the network throughput.
This can be done in multiple ways:
SSD: using Solid-State Drives can make random I/O access times from 10x to 100x faster. However, sequential I/O and sequential reads and writes aren't much faster with SSD. Since most databases are optimized for sequential I/O, switching to SSD may not make a big difference in terms of speed.
RAID: RAID is an acronym for Redundant Array of Independent Disks. The idea is to improve I/O capacity by adding more hard drives and spreading reads and writes across them. The cool thing is that from an application perspective, a RAID array looks like a single volume. There are different types of RAID configurations. Most people choose RAID 10 since it increase the throughput and provide redundancy.
RAM: Memory size is important for how well a server works, especially if it is a database server. Adding RAM cuts down on I/O operations, allows a bigger file system cache, and gives applications more working memory.
NETWORK: Upgrading network connections or adding more of them increases the speed of the network. This is very important for servers that stream a lot of video or other media files.
CPU: Adding more processors or virtual cores can speed up a machine. The more CPUs and virtual cores, the more processes that can be executed at the same time. More tasks can run at once, and the OS needs to switch between them less often.
Limitations of vertical scaling
Vertical scalability is an attractive option in the short term, especially for smaller apps or when it makes financial sense to upgrade the hardware.
Its main benefit is that it is very easy to use: you can improve your system's speed and capacity by just upgrading the hardware that's already there.
However, vertical scalability has some significant drawbacks, the biggest of which is the cost. When you get close to the limits of your hardware, vertical scaling stops being cost-effective and becomes too expensive.
For example, adding 256GB of RAM to a server that already has 128GB of RAM can be much more expensive than the first upgrade.
In general, after a certain point, the extra costs of adding more capacity become too high for the benefits to justify.
In addition, vertical scalability is also limited by technical and physical limits. There are hard limits on how much memory, CPU power, or storage can be added to a single machine, no matter how much something costs.
For example, you can only add a certain amount of CPU cores to a server, and hard drive speeds cannot be increased indefinitely. Systems eventually hit a point where hardware supporting further growth is not available.
As a last point, consider that there may also be limits on vertical growth that come from the way the operating system or application is built. Extra resources might not help some programs, especially older ones or ones that aren't designed to work well with new hardware.
For example, adding more CPUs to a MySQL server can cause more lock conflict because many processes are trying to use the same resources at the same time.
Interesting Reads
How to implement Server-Sent Events in Go by
Normalization vs Denormalization by
The Graph Database Revolution: What You Need to Know by
Web Scraping Fundamentals — use cases, tech, and ethics by
Food for thoughts
There is a big difference between working on a solo project and working at a mid to large company. In a company you need to have more discipline or the mess will become a barrier. A solo developer you need to be pragmatic and focus on what adds more value to the business. Link
Europe and the US seem to have entirely different systems. Companies in Europe have higher expenses per employee than in the US. Plus, life is, on average, cheaper in Europe.
Learning about containers opens many doors, and starting with Docker is the best way to do it. You don't need to know everything happening behind the scenes. If you can get your work done correctly, it is already enough. Link
Very nice explanation Fernando.
It's a good idea to try Vertical Scaling and see how far it can take you because horizontal scaling adds its own problems to the mix.
Also, thanks for the mention. Glad you liked the article!
This was a great overview, Fernando.
I remember at my first workplace when we purchased our first physical server, then we realized all the unnecessary power we had and invested our money into it. :)
For app development, especially for startups but even for mid-tier tech, I don't think it economically makes sense to buy a physical server and start upgrading it as demand grows.
Thank you for mentioning Bitsy, glad you loved the article!