
Ask HN: Are three servers better than one? - oblib
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.<p>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 &quot;Allow 3rd Party Cookies&quot; to run my apps.<p>But, it seems to me this approach may have some advantages too. It minimizes the chances for creating conflicts with dependencies when updating&#x2F;upgrading. It delegates and spreads the loads for those chores. If one server goes down it doesn&#x27;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.<p>So far I&#x27;ve not convinced myself it&#x27;s worth the effort to build a single box that does all of that. I suspect it can be done, but I&#x27;m  also not sure it&#x27;s a good idea to go that route. So far what I&#x27;ve got seems to be working pretty good and that old adage, &quot;If it ain&#x27;t broke don&#x27;t fix it&quot;, comes to mind.<p>But there&#x27;s a lot I don&#x27;t know so if I&#x27;m missing some things (and I expect I am) I&#x27;d be grateful to have them pointed out to me.
======
warrenm
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).

~~~
oblib
"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.

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

~~~
oblib
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.

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

~~~
oblib
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.

~~~
twobyfour
Your users are hitting your DB server directly?

~~~
oblib
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.

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

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

------
kazishariar
Advanced Marketing +1

~~~
oblib
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?

