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?


Views: 76

Reply to This

Replies to This Discussion



Quick question - your argument does not seem to take in the fact that running application A + B on the same set of nodes may potentially double the load per server ? Or were you considering increasing the server capacities concurrently ?

My point is if there is capacity on a node, shouldn't we have an ability to add more apps to it, rather than forcing us to have to create a new node just because it is a different app.


@Mahesh: now I get it ! 


I actually had a similar discussion with my co-founder Sandaruwan.


My argument was that aside from capacity, other issues also tend to come into play - such as security and even maintainability (especially if the applications use different technology stacks).


However, his point was that it would be a waste of capacity to have multiple nodes - and that the running costs would also be increased unnecessarily.


In the end we decided to go with multiple apps on a single node, since that seemed to make more sense for our situation.

Yes - and keep measuring it.  If you find there's a problem, move out to additional servers, or spawn new servers just for the app that is loaded.  More often than not, it will only be on specific days.  I would even simply just replicate the entire node.  




The RodinStar Post of the Week!

Like us on FB, Please?!

Follow us on Twitter!!!

9 Ideas to use the site!

1. Registration is a click away - via Facebook etc
2. View ongoing discussions and fire up one yourself
3. Wanna feature your startup? Showcase it!
4. Have a question? Just ASK! here
5. Wanna read the BEST OF 2014?
6. Wanna get funding but don't know how to pitch? Here's a template!
7. Wanna know more about Trhs Events - read all the Open House stories.

8. Need help in Digital media? There's a goldmine of insights HERE...
9. Lazy? Just hang out, Chat, add Friends...

Still messed up? Read the FAQ's

What does 'Rodinhood' mean?

Rodinhood is inspired from Rodin - who sculpted 'The Thinker' and Robin Hood who 'got things done'. Hence Thinking+Doing = Rodinhood.

The best place for enterprising folks to hang out, share,make like-minded friends, get feedback and soak in a pool of vast experience.

© 2016   Created by Alok Rodinhood Kejriwal.   Powered by

Badges  |  Report an Issue  |  Terms of Service