Would you choose multiple Droplets or would you scale a single Droplet

January 3, 2015 1.8k views

Suppose I have customers using my web app, and there's no overlap in customer data, so no shared database is required. This means I could spin up a Droplet for each customer.

Seems like there could be a number of advantages:
1) No single point of failure that would bring down all customers ( assuming all the Droplets don't reside on the same server ).
2) Better security since each customer is on their own Droplet. One getting hacked into doesn't put the other customers at risk.
3) Easy to add resources if the needs of one customer grows

I'd think the tradeoff of this approach versus a single high capacity server might be administration overhead ( and possible additional cost ) of multiple Droplets.

Has anyone looked at this tradeoff and decided why one approach might be better?

1 Answer

If you plan on a good number of users using your web app, I'd recommend scaling out from the start. Why? Because of the way DO handles disk upgrades.

To upgrade CPU & RAM, all you're troubled with is a reboot; quick and easy. For disk, it's shutdown, snapshot, deploy snapshot to a new Droplet, potentially lose the current IP and in the process, hope you don't have to reconfigure the network each time as it'll become a PITA.

I would normally recommend learning to manage LXC/LXD containers (Linux Containers), though with the disk upgrade "issue", this would be a bit of a nightmare and would spell downtime for many.

  • Thank-you for the heads up! I hadn't realized disk upgrades were problematic. I will also read up on LXC/LXD.

    Suppose the disk upgrade issue wasn't present. Are there other reasons why the one Droplet per organization that uses this app is a bad idea? I did like the idea that ( assuming the VPS aren't all on the same hardware ) there would be some additional fault tolerance that wouldn't be possible with a single server approach and we could locate Droplets as physically close to the end user as possible.

    Since I'm not aware of people taking this approach in practice, I assumed there must be some substantial negatives to it. In my case, the "customer" is actually an organization that could have dozens of users, so it's not like there's a single user per Droplet, more like several dozen users per Droplet, all within the same organization.

  • @mikel965814

    My apologize for not getting back to you sooner, in the process of switching over account info and I've yet to do that for DO :-). All my notifications were going to an e-mail I rarely check unless there's a payment or debit from my business card.

    That said, you know your application best. If you're on the fence, that tells me you could realistically go either way, though one way allows you to scale much easier than the other. Scalability should be something you think of upfront, not down the road when it may just be too late and result in DT and cost you money, or a client (worst-case scenario).

    DT being downtime.

    Ultimately, you have to look at what your application does and how active it will be. I prefer to scale out if I know my project will be used just as I prefer NGINX over Apache for it's simplicity and above all, it's speed; Redis over MemCache due to development, speed and options; and RAM over the physical disk when there's plenty available, as even though SSD's are fast, RAM is still much faster but far more limited.

    Choosing your options prior, and then knowing what you can do with those options later on is what keeps you on a well-balanced path. Being able to tell a client we've built this with scalability in mind, so as you grow, we'll grow with you is satisfying as well as comforting/soothing music to their ears. If you have the option to avoid potential issues in the future by maybe increasing costs just a few $$ now (and DO is pretty cheap), you'll thank yourself.

    At the end of the day, develop & plan ahead.

Have another answer? Share your knowledge.