The Personal Blog of Jon Thoms

TL;DR

Use horizontal scaling if you can, it’s usually preferable to vertical scaling. However, if you need run large monolithic apps, then vertical scaling is probably your best bet, although you should try to cut back on app size and resource utilization ASAP.

In slightly more detail, I would propose the following pros-and-cons list of horizontal vs. vertical scaling:

Dimension of Comparison	Horizontal Scaling	Vertical Scaling
Cost	less expensive (through commodity hardware components)	more expensive (specialized servers)
Availability of IT Resources	IT resources instantly available	IT resources normally instantly available
Replication and Backup	nodes that can often serve as backup for one another	other means will need to be found to replicate and backup data
Scaling Limitations	often automated and not limited by hardware capacity	often manual and limited by maximum hardware capacity
Failover	usually builtin with nodes that can easily substitute for other nodes	often a single point of failure
Ability to Run Large Applications	App size and utilization is usually limited by smaller size hosts	can often run large monolithic applications

My justification for the proposal of the above pros-and-cons list is the long explanation below, not the short abstract above.

So I’ve just started reading a book called “Cloud Computing: Concepts, Technology & Architecture” (CCCTA). So far the book is quite good. It got mixed reviews on Amazon, but from what I’m reading so far, it contains useful basic info on cloud theory. One of CCCTA’s sections describes pros and cons for horizontal scaling vs. vertical scaling. Frankly, I largely disagree with the author’s pros-and-cons list. The pros and cons of horizontal and vertical scaling can be found on page 38, in a table (Table 3.1). The table contains the following data:

Horizontal Scaling	Vertical Scaling
less expensive (through commodity hardware components)	more expensive (specialized servers)
IT resources instantly available	IT resources normally instantly available
resource replication and automated scaling	additional setup is normally needed
additional IT resources needed	no additional IT resources needed
not limited by hardware capacity	limited by maximum hardware capacity

 

Some points about this table:

1. I agree with the first row. Horizontal scaling scaling is generally cheaper than vertical scaling.
2. I also agree with the second row. Vertical scaling can sometimes require more specialized hosts and consequently more specialized IT resources that may not be immediately available.
3. Row three is where I start to disagree with the author. True, horizontal scaling does often come with resource replication and automated scaling. But the statement “additional setup is normally needed” for vertical scaling (while probably true) is largely moot. What really matters are the IT resources which may not be immediately available (see row 2). Furthermore, this row misses the point that while resource replication and automated scaling are often benefits of horizontal scaling, they aren’t benefits of vertical scaling. Replication and backups still need to be thought of separately, because you don’t have inbuilt backups in your cluster/group of nodes. Furthermore, scaling is manual, not automatic, since you always need to provision larger hosts.
4. The fourth row, is IMO, incorrect. We need additional IT resources for horizontal scaling but not for vertical scaling… Huh? Don’t we need additional IT resources to setup and provision and switchover to the new larger host? Seems like the amount of labor involved for vertical scaling is at least as much as horizontal scaling.
5. As for the fifth row of the table, I agree with it. The limits of scale for horizontal scaling is, in my experience, much larger than the scaling limits of vertical scaling.

If this table was correct and complete, I don’t think that anybody would ever choose vertical scaling, because based solely on the above table, vertical scaling has no advantages over horizontal scaling. But, people do choose vertical scaling, and for good reason. The reason vertical scaling is sometimes chosen is because for all the benefits that horizontal scaling offers (and IMO Table 3.1 of CCCTA is largely correct about those benefits), not all the apps we have to deal with scale out horizontally. For big, monolithic, resource hogging apps, sometimes vertical scaling is the best choice. The high business value of some of these applications can dramatically outweigh the cost of the specialized hardware. Sure, ideally, we wouldn’t want behemoth apps that are a pain to maintain, but sometimes it’s just the best course of action. For example, mission critical databases are often such apps that demand vertical scaling. Sure, you could switch those DBs over to a horizontally scalable NoSQL solution, but oftentimes you can’t. When your Oracle DB contains real-time critical data related to bookings, and a plethora of apps access that DB directly, and you need to scale up, vertically scaling that DB might just be the fastest and cheapest thing to do (when you factor in the cost of changing all applications that connect to that DB). That being said, IMO horizontal scaling is the best longterm strategy, whereas vertical scaling might be what you need in the short-term.

Outside of table, this section of CCCTA also contains another “con” of vertical scaling that I really disagree with. On page 37, it reads:

Vertical scaling is less common in cloud environments due to the downtime required while the replacement is taking place.

IMO, this statement is wrong for two reasons:

1. Vertical scaling doesn’t necessarily need to require any downtime. You put your old smaller host behind an LB, then setup the new larger host, then switch traffic over to the new host at the LB level. Poof… near-zero downtime. Of course, there are exceptions to this rule, but in my experience, they are few and far between.
2. Vertical scaling is less common in cloud environments not because of downtime, but because of cost and resiliency. Bigger hosts cost more money. Like, a lot more money. And, with vertical scaling, you still have a single point of failure. Moreover, you can only scale up vertically so far, before host costs become either prohibitive, or simply unavailable.

With all that said, CCCTA is still IMO a decent book so far. I just take issue with this individual section. For the reasons described above in my “long explanation”, I would revise Table 3.1 in CCCTA to be my own table of reasons given at the start of this post.

The past year has been a difficult time for me, personally. In fact, it’s been so difficult that I feel like I’ve got a case of good ole fashioned Mom Brain that just won’t go away. I won’t go into too many details, but grief is something that I haven’t yet been able to control. It manifests itself in one form or another from time to time. Predictably, my performance at work has taken a beating. However, as a result of some tactical fixes, I’ve been able to reduce the negative effects these issues that arise when I get distracted.

If you feel like your brain is betraying your desire to succeed, here are some tools have helped (and continue to help) me remedy my focus:

	Tool #1 – A good paper planner: A good paper planner helps me set weekly and monthly objectives. It doesn’t have to be much, but it helps keep you on track to achieving your objectives and making things you are doing what you need to do. Btw, if you’re having a really tough time personally like me, your objectives and goals don’t have to be career aspirations and other ways to grow. My goals were merely there to help me try to maintain the status quo of my life. Examples of things I have put on there including various daily milestones for projects I am working on, doing one Pomodoro of house work, some administrative task or two that I hate doing, etc. Note that the planner isn’t very useful for calendar items – that’s what your calendar app on your phone is for. The planner also not for micro-level todo lists; that’s one of the uses of the log (described below). The planner is also useful for going over just before your morning scrum to state what you completed yesterday and what you intend to complete today. The one that I use is the Volt Planner.
	Tool #2 – A good paper logbook: A good logbook helps me serialize my thoughts enough to complete complex tasks and investigations on how to solve a problem. I can write down things I’m trying, things that worked, things that didn’t work. I can go back through my notes as I try to remember what some highly complicated piece of legacy code does. They are also useful for large and intricate todo lists that can involve several different tasks happening concurrently. Another useful aspect of logbooks is to act as a reference for things that you need to know but will forget unless you write it down. My logbook of preference is the Leuchtterm1917 Master Slim Ruled. It’s big enough to write and draw what I need, slim enough to be relatively light, and has a hard cover to write on it without support.
	Tool #3 – A good notebook for meetings: If you’re like me, you dislike meetings. Sitting still for an extended period while listening to other people talk feels tedious. Boredom sets in and your attention wanes. Nonetheless, you need to pay attention. Important decisions have to be made and at the very least, you need to follow along. A relatively small book to take notes (and perhaps doodle a little) is useful to retain knowledge of important facts. It’s also useful to write down a question you want to ask (or make a general comment) when somebody else is talking and you don’t want to interrupt them. For me personally, I like the Ink and Volt Meeting Notes. It’s relatively small, certainly less obtrusive than a full sized logbook, and is well suited to bring to a meeting and write down what information you need to retain, and what action items you need to take later.

Of course, these low tech items beg the question: Why not use electronic means? You can search what you write, it can be backed up trivially. The question is valid, and there is merit to using OneNote or Evernote. But for me, personally, the act of writing on paper helps me retain the information better than typing. Moreover, information on paper can be recorded faster. Diagrams are faster to draw. Lines are easier to connect text. Some basically note taking organization can get you largely to a searchable logbook.

Anyways, for me these tools help to stay on track even when I don’t feel up to it. I hope they can help you as well.

Dr. Seuss’ Green Eggs and Ham has exactly 50 unique words.

I became interested in this fact after reading an article stating Dr. Seuss took on a bet to write Green Eggs and Ham in 50 words or less. I wanted to confirm this for myself so I thought that I would write a quick Python script to do it.

So, I found a text file version of Green Eggs and Ham and downloaded it, then dumped it into a Python script that determines how many unique words there are. After correcting the script text file to match exactly what the book says (i.e. removing the word “spam” which doesn’t actually occur in the book) and removing hyphens, other punctuation, and ignoring case, I managed to confirm for myself that Green Eggs and Ham does in fact have exactly fifty words.

Mystery solved!

The script’s output is:

set(['and', 'sam', 'be', 'house', 'am', 'box', 'see', 'are', 'in', 'mouse', 'boat', 'if', 'try', 'ham', 'would', 'there', 'fox', 'so', 'you', 'goat', 'do', 'them', 'good', 'that', 'may', 'eggs', 'here', 'dark', 'me', 'train', 'let', 'rain', 'they', 'not', 'with', 'eat', 'thank', 'a', 'on', 'like', 'i', 'car', 'could', 'tree', 'say', 'will', 'anywhere', 'green', 'the', 'or'])
50