High Availability#

You'll be implementing everything in a highly available manner. When you get to creating a larger project later on in this course, you'll work with a "load balancer", your first major piece of networking hardware designed to help you achieve high availability.

This entire concept is very easily explained with a simple example.

Imagine you have a website that sells widgets. You have a web server with your web application on it and a database that contains information about all the widgets you sell. Now imagine you have one server with everything on it. That looks like this:

Our HTTP client is making a request to our HTTP web application. This is simple enough to understand, but what happens if the server itself fails due to a hardware failure or the application is misconfigured and it fails? That's what this looks like:

Our client cannot reach anything as the entire solution is inaccessible. How do we prevent this in the future?

Look at this:

Now we've introduced a whole new piece of technology and a second web server. Why?

A load balancer lets us keep operating our website even if a single server fails. The idea behind a load balancer is simple: when it receives traffic it only forwards it to web servers that are healthy. It also balances the traffic between all the available web servers so that no one server is doing all of the work.

This is why we have two web servers in our architecture - there's no point in using a load balancer with only one web server in operation.

Also note that the MySQL database is only running on the right-hand web server not both. Both HTTP servers share the same database, so it can only run on one server.

That same failure as before might now look like this:

The same server failed again, but the client still gets to talk to an HTTP web server, BUT the database server went down as well. Not good.

So the client will get an HTTP response from the second server but because the application went down it's very likely the web server will return an HTTP error code in the 5XX range.

Instead our architecture design should probably look like this:

Now our MySQL database is installed on its own server. In the event of another HTTP server failure whatever servers remain can handle the HTTP client requests and still talk to the database.

The observant reader might notice that there's also only one MySQL database server. Good catch! We won't cover this here, but yes, that too will need to be made highly available, but not with a load balancer. Databases require a lot more complex work and attention to make them highly available but it's very possible.

The idea with availability is simple: keep the system up and running even if components within the network fail. You do this primarily by duplicating instances of an application and having load balancers, and other solutions, send traffic only to working components.

Obviously, the whole idea of high availability gets more complicated than that - it's never that simple - but with some of the projects we'll go over in the book, and with time in the industry, this all become clearer.

Key Points#

High Availability

When you're building solutions for businesses, you need to build high availability into them from the ground up. Your key take away here is simple: you build infrastructure to withstand hardware and software failure, and fail it will.

We use load balancers and proxy servers, among other things, to direct traffic to systems that are operational and can serve the client's requests. they ignore failed systems that aren't operating correctly.

You'll be using load balancers a lot in your career.

Check your understanding#

There is no self-assessment for this section at this time. Please review and ensure you understand the key point(s), above.