1x Linode 2G, or 2x Linode 1G?

Multiple points of failures, never a good idea unless absolutely necessary.

As long as there isn't a single point of failure, it's a great idea.

@hoopycat:

As long as there isn't a single point of failure, it's a great idea.
That's not true.

With a single system - there's a x% chance of failure.

With a two systems - where both systems must be working in order for a success (i.e. a web server and a db server) - there's a 2 times x% chance of failure.

So unless you're talking about redundant systems (i.e. failover or clusters), having more then a single box increases your chance of downtime.

@vonskippy:

@hoopycat:

As long as there isn't a single point of failure, it's a great idea.
That's not true.

With a single system - there's a x% chance of failure.

With a two systems - where both systems must be working in order for a success (i.e. a web server and a db server)
Then you have 2 single points of failure (SPOF), and so hoopycat's comment doesn't apply.

> - there's a 2 times x% chance of failure.
Not quite:

P(A or B) = P(A) + P(B) - P(A and B) = P(A)+P(B)-P(A)P(B) if A and B are independent events, so (2x-x^2)%

Unless you feel that you may in reality want to scale to have many application servers or DB servers in the future, one linode would be the simplest. However if you can see yourself increasing traffic over time, it can be good to split out servers and load balance between them.

I'm quite lucky with my application: users don't interact, and have their own DNS records - so i can split up the application as much as i like with no servers depending on any other, and even minimal customer impact.

So with multiple servers, every customer would still experience the same chance of downtime - but if a server hiccups then it only affects a fraction of the customers.

RAM and disk IO are my limiting factors, so i might take the latest NextGen upgrade to double the ram of my linodes, then downgrade them to half size, then double the number of servers while staying in the same price envelope… ending up with basically the same specs, the same number of cpu core shares, and a more diversified chance of burst resource availability

But really, what would i have gained? The same hardware specs, and another server that might wake me up in the middle of the night. So i don't know if i should go with a few big linodes, or many small ones.

IMO one of the biggest appeals of virtualization is that you can split up your infra at cost; you no longer need to have one server that runs -everything-

It's definitely a lot easier to manage a bunch of servers that have specific jobs as opposed to a full stack on a single machine.

You can scale more efficiently with a multiple server setup. It's easier to monitor where your choke points are (say, DB, App or Cache server) and then target your hardware budget accordingly. For me it's a commercial decision as much as a technical decision.

If RAM is your limiting factor you should go with fewer and bigger Linodes to avoid the (small) multiple OS overhead.

If Disk IO is your limiting factor you should go with a large number of small Linodes as disk IO capacity on the low end and high end servers is essentially the same.

The answer depends on what this application does and how it does it.

@vonskippy:

So unless you're talking about redundant systems (i.e. failover or clusters), having more then a single box increases your chance of downtime.

Of course, failover or clusters bring there own complexities.

I think a key factor is what you believe the future will hold. If scaling up a single instance has a high likelihood of meeting your availability, performance and growth needs for the foreseeable future then I'd stick with that.

Yes, splitting your customers between two independent servers means that a failure will only hit half of your customer base, but you'll still have a problem that needs attending to. Moreover, you'll have ~2x as many problems so your cumulative downtime measured in customer-hours will be the same over time in exchange for more admin work.

If you think that bumping up the instance size is going to be insufficient in the foreseeable future then going with two smaller instances would be a good step towards gaining practical experience with running your application on a resilient and scalable multi-instance architecture.