-1

I'm curious as to the infrastructure of an web app... is it a network of cloned servers with the same exact app/source code, a network of cloned database servers and a network of media/asset servers sitting behind a network of load balancing servers? If so, does the web app require some type of function to help facilitate this?

2 Answers 2

9

Wow, that's an enormously broad question :) It's quite off-topic for serverfault, so it'll probably be closed in a bit. But as it's saturday afternoon, I'm in a storytelling mood, so here's an answer, roughly based on a simplified version of how we grew the company I currently work at.

The abbreviated answer is my favourite: It depends. There is no "this is how you build a webapp" recipe, though there are some common patterns.

Your question makes the assumption that a webapp runs on multiple servers, though this is not necessarily true. Every website could be considered a webapp. Something as simple as a blog is a webapp with a database, code and static assets all on the same box, with no high availability whatsoever. This is how most startup webapps start. Now what happens if they grow?

At some point they outgrow the single server, so they scale out: split the database and the appserver (which also does all static assets). And any non-live code, like cronjobs can move to another server. Business saved.... for now.

Because a healthy business will outgrow this too. Application servers tend to be easy to scale, so you'll often see people use a set of application servers behind an HA pair of loadbalancers. Properly set up environments use something like puppet or func to keep them in sync and use a deployment method for their code that will do rollouts/rollbacks with no user-visible downtime by playing with the loadbalancer. A setup like this allows you to scale your appservers horizontally to quite a large scale.

But then of course the database becomes to busy, so the database will grow a set of slaves to offload read actions onto. And maybe a caching layer gets built to avoid reading from databases altogether. Then, when the master gets too busy to handle all the writes, the data is sharded onto multiple replication chains. As long as your data is easy to shard and replicate, this gives you a lot of headroom for scaling as well.

In the mean time your business has grown so much that bandwidth and amount of static content becomes an issue too, so static assets are no longer served by the appservers, but by a dedicated set of servers. Maybe with a CDN in front to help with handling the incoming bandwidth.

With all the simple things done, now it starts getting interesting. By the time you hit this scale, you probably want to avoid any and all downtime. So you look at more high availibility options for your remaining single points of failure (like database masters). You look at disaster recovery in case your main datacenter goes down. And you'll also become a target for various malicious people on the internet. DDOS attacks and attempts at breaching your security perimeter are a constant threat that you need to deal with.

And does the app server need some function to deal with all this? No. But your environment does. It's best to keep customer-facing servers dumb and fast and have smart control mechanisms to deal with rollouts, consistency checking, monitoring and handling attacks. This allows the appservers to focus on serving the customer, which is what brings in the money.

2
  • 1
    that was a good read, glad you are in a storytelling mood Apr 6, 2013 at 11:23
  • out-friggin-standing!!! that was very helpful - its going in my notebook. thanks! Apr 10, 2013 at 7:20
0

The app can sit on one or more servers. Typically multiple servers will be nearly identical, and using the same code base. The number of web and database servers will depend on your required resources, and should be able to scale up and down as needed.

The load balancing should be invisible to both the end user and the application itself. While certain applications may need to take load balancing into consideration, most web applications from my experience will work fine in the dark.

Not the answer you're looking for? Browse other questions tagged .