Load Balancers. What are they?
LBs are the middle-men between computers and servers.
I think that is a simple explanation for them. They receive requests from computers and will direct that request to the proper server based on conditions or rules placed on them.
This is important for many reasons. We normally don’t think about these things when we open up our laptop or turn on our PC — at least I didn’t — not until recently when my friend Patrick suggested we look into it for a presentation.
Service
Think of Instagram or Facebook — they have numerous users around the world using their site or app simultaneously. This wouldn’t be possible without a load balancer! Instagram, Facebook, Netflix — they all have countless amounts of servers located around the world in convenient locations for processing requests and sending information over the internet.
If a server is receiving too many requests at once, or if the server isn’t working at its best capacity due to a technical issue, or if the power goes out, this could lead to users being unable to access their profiles, share funny pet videos, or watch a livestream of their favorite people. This would be a catastrophe for users and that directly influences their perspective on the company. This is even more important nowadays with so many alternative services and applications out there — just have a look at the Google Play Store.
Purpose
Rules, algorithms, and conditions placed on load balancers are necessary for determining where to send the requests to. Servers are not all the same — some are built for a specific purpose. A server could be built for managing images, another server could be for videos, and another could be for web pages. Potentially an image request being sent to a server made for web pages could impact the server in terms of speed and processing.
By prescheduling these rules on a load balancer, you are preemptively avoiding overloading servers and servers’ overall condition. This ultimately saves you overhead costs, supervision, and losing customers.
Access
Security — it’s a thing, you’ve probably heard about it. Privacy — it’s also a thing. These two are connected in many ways and load balancers is a layer of protection of your data and information. Since LBs direct traffic, DOS (denial-of-service) attacks are well mitigated. A DOS attack is used to overflow servers and with a load balancer you are directing the traffic amongst many servers which would avoid servers crashing and access to the servers.
I remember when Google’s servers went down for a short period and I couldn’t access my Gmail — it made me realize how much I depended upon their service, their servers, and how screwed I would be if the servers didn’t come back online much sooner.
You can’t speak about load balancers without mentioning scaling and fault tolerance.
Scaling
Netflix, you know the video streaming service everyone’s lives depend on — otherwise you’ve heard it from Netflix and Chill.
Traditionally when you gained more users and traffic on your website or application, you would do a number of things which include getting another server. This is costly in terms of the price of a server, maintenance and overhead and simply opportunity cost in a sense. What if your application was a one-hit-wonder and loses traffic and users in a short period of time? You’re still stuck with the server. And then what if you somehow manage to keep things going??
Cloud environments such as provided by AWS, Amazon Web Services, is perfect for such a case. They will charge you for the services actually being used. If traffic spurs up, in a matter of clicks you can add another server and load balancer to manage it all. And more importantly, you can decommission it when things slow down and avoid having to pay more than you need.
Just think about when most people use Netflix to watch their shows and movies and drown out their misery of their 9–5 lives.
Fault Tolerance
In August of 2008, Netflix’s in-house server was down and they were unable to ship out DVDs to their customers.
Yep, Netflix used to deliver DVDs via the post to their clients before moving onto the internet! One issue lead to the complete shutdown of their business until it could be resolved.
They came to the realization that they were terrible at managing servers on their own, and frankly they didn’t want to bother with it — they were costly, time-consuming, inefficient and a disaster waiting to happen. They took a gamble and went with AWS — they were relatively still new to the cloud game then.
With AWS’ servers and load balancing services, Netflix can manage numerous servers across the globe and redirect traffic and streaming service to their customers from one location to another in a matter of minutes without them realizing any issues — for example, moving US East to Europe would take approximately 6 minutes, again, without interruptions or noticeable changes in service.
But when do I need one?
This was a common question for us when we gave our presentation — it really depends on the application. It’s safe to say that if you have multiple servers, you should have a load balancer.
When you sign up for AWS, you actually have a load balancer option and can get one right away. And then when should you get more load balancers and/or servers? This depends on the traffic you are getting and the demand your servers are receiving — if you notice that some of your servers are working near capacity then it may be wise to add another server.
And how should I know when to add another load balancer? I can’t say for sure but load balancers have rules and schedules assigned to them to redirect traffic accordingly. If for some reason your application includes a new type of media, then perhaps you could simply add another rule to the load balancer and have it redirect traffic for such requests to specific servers.
Consider this — your sole load balancer fails, then what? The traffic requests sent from the client computer (your customers) cannot access any of your servers and thus they’re stuck with no access. This is why it is wise to have multiple load balancers in case of failure or unforeseen circumstances.
