TheRodinhoods

Approach to high-availability in the cloud

I’m having a debate with our infrastructure provider partner.

 

It’s their opinion that to achieve high-availability (HA), one needs to isolate infrastructure at a per-domain level.  So, if one application needs 2 load-balanced web servers, a master database and a slave database, you set 4 nodes up.  For another application, running similar requirements, you set-up another 4 nodes.  So, a total of 8 nodes to manage, and 2 load-balancers.

 

I feel that’s a textbook approach to HA and the smarter way to plan for high-availability is to perform it at a “per-functionality” level.  

 

Using the same example above, you would have 2 nodes to run both PHP we servers, a central master DB and a slave DB.  Therefore, 4 nodes with 1 load-balancer, and scale-out after monitoring performance. 

 

The principle is that hardware (and therefore it’s failure), is agnostic to the software that runs it.  Will a piece of hardware fail if it’s running application A or application B, or will it fail because it has to ?  

 

This is further exemplified in the cloud, where infrastructure is shared across seemingly independent applications. (key word is seemingly, as the same hardware is virtually running multiple types of software).

 

One can argue that chance  of failures is a function of number of nodes, but again, I feel that’s more a academic response, because management and likely running costs becomes a challenge with more nodes, even in the cloud.

 

What do others technically-inclined think?