Ask HN: Are three servers better than one? | Hacker News Reader

Ask HN: Are three servers better than one?

2 pointsoblib12 comments

After running into some issues trying to setup a server on DigitalOcean with everything I needed to run my web apps I decided to set one up as a web file server, another as an email server, and a third one as a CouchDB server.

On the down side I now have 3 servers to manage, and I suppose 3 times the probability that one might go down. And users have to configure their web browser to "Allow 3rd Party Cookies" to run my apps.

But, it seems to me this approach may have some advantages too. It minimizes the chances for creating conflicts with dependencies when updating/upgrading. It delegates and spreads the loads for those chores. If one server goes down it doesn't take everything else down with it. And, each of these servers can be scaled to the size needed to handle the load it carries.

So far I've not convinced myself it's worth the effort to build a single box that does all of that. I suspect it can be done, but I'm also not sure it's a good idea to go that route. So far what I've got seems to be working pretty good and that old adage, "If it ain't broke don't fix it", comes to mind.

But there's a lot I don't know so if I'm missing some things (and I expect I am) I'd be grateful to have them pointed out to me.

Yes.

No.

Maybe.

Really need more context to your question: certainly separation of duties can be a good protocol to follow ... but having everything in one place can be adequate, too.

Tiering your web and database into different servers, clusters, groups, etc can be smart - especially since you can focus on the resources which best optimize the given tier, and not have to worry about contention (and on services like DO, utilizing private networking so only your web server(s) talk to your db server(s) cuts down on your attack vectors.

Having services on different systems also allows for one (or more) to be down without impacting others (unless it's the db tier, and both mail & web rely on it ... then db being down affects everything).

"on services like DO, utilizing private networking so only your web server(s) talk to your db server(s) cuts down on your attack vectors."

Thank you for mentioning this. I was not aware DO provides tools for this so I'll be looking into that. Right now I'm using CouchDB CORS configuration to restrict access to the DB to only the app file server.

Spend some time on their docs and API references: there's a lot in there that could benefit you :)

There's still surprising little on installing and configuring CouchDB 2.0. there, but there is a lot of great info there and I've poured through a lot of it.

I'll probably post my install instructions in the comments of their CouchDB 1.6 guide so others can help improve them soon.

I've not yet had a chance to play with the DO API yet but I do want to, and will sometime soon.

Why would users need to enable third party cookies in this scenario?

Right now the DB and App file servers use different IPs and domain names and both are set up with SSL and when I turn that off 3rd party cookies in my browser the authentication used on the DB server breaks.

Your users are hitting your DB server directly?

Yes. I use PouchDB.js on the client to store data and sync it with the CouchDB server. The CouchDB server also provides the authentication routines for the app.

Ok. I'm not very familiar with CouchDB, but with most databases I'vee used, that would be a major antipattern and security risk.

The CouchDB has CORS configured to only accept requests from the app server and it authenticates user requests so it's pretty solid.

Advanced Marketing +1

I didn't mention the app name or the domain names, only the service provider I use, and I pay them, so what do you think I'm marketing here?

Reply on news.ycombinator.com