Is it common to have multiple different servers for the same web application?

Asked

Viewed 1,682 times

11

Setting:

I’m starting to participate in the development of a web application. This application is not yet available "online", IE, we only have it here on the test server where we have, on the same machine, installed Redis, SQL Server, IIS, among other things.

Let’s start testing this application online, that is, we want to publish this application so that we can test at the end-user level.

We looked for some accommodations, etc. And I ended up facing the following problem: I did not find any accommodation that has everything I need. So I ended up 'distributing' the application in three different lodgings, I mean, using the hosting A to leave my SQL Server database on hosting B is Redis and in hosting C is the ASP.NET application that accesses these databases.

As I always worked with desktop applications and the web contact I had was internal applications where everything (Redis, SQL Server, ASP.NET Application) is on the same machine, it ends up looking kind of strange.

Doubt:

Is this a commonly used approach? Keeping each thing on a different server can bring me some kind of problem?

  • 1

    Some sites have multiple servers, so much so that each time period ip ping changes. example google.

  • 1

    Yes, but I meant specifically in this case. Where I will keep SQL Server in one, Redis in another and the application in another.

  • 3

    in this case I think would lose performasse, it is much faster the site collect the content from the server itself than from another, and as you want to use 3 servers, it would increase 2 requests for the user to be able to access the content of the page. In my opinion, this is not at all feasible in this case.

  • 2

    It’s no big deal. The problem you can have is the cost. If it used technologies that could be harnessed in a single environment, it could dramatically reduce costs and simplify everything on a single server. But this all also depends on the expected volume of traffic. If it is a high volume, it is better to keep the way you are doing, on separate servers and then increase with mirrors/load balance, etc. In short, the point you should worry more about is the volume of traffic. If you always have a low volume, it doesn’t make up for the whole structure. You’d be throwing money down the drain.

  • 1

    @Brumazzid.B. In this case there is no loss of performance, on the contrary. It is common to have servers with "load balancing" where they point to different servers, replications, etc. It would not increase the requests, they will be made the same way, what changes is the way.

  • 5

    One important thing to consider is that it is recommended for large applications or scalability is to have DB on different MACHINE. Only you can not confuse this with DB in different NET. In different network, the loss may not compensate for the supposed better performance of DB. Especially if the network is the internet itself. Besides, who accesses the DB is the application server, and not the client. So there’s no advantage to the parallelism that you hear about when you use a CDN for images and JS, for example.

Show 1 more comment

3 answers

9

This is a commonly used approach?

Not common. It’s a little extravagant, but it’s not wrong.

Keeping each thing on a different server can bring me some kind of problem?

The problems are more related to the complexity of your contingency. The choice of not leaving everything centralized may or may not be a performance bonus. There is also the question of the quality of each service, the complexity of their administration and something involving costs. In short, division can be both an advantage and a disadvantage.

For example, if your Redis server crashes, your application will not necessarily stop working, especially if Redis is used as a second-level cache for your application. Now, if your SQL Server crashes, even with Redis working, you will drop the application even with the other services working. Contingency is much easier to manage when centralized.

On the other hand, establishing this division creates an interesting form of parallelism. The workload is divided into three different places, which can be converted into performance gain.

8

I’m answering based on what you were asked. You’re talking about having servers in different hosts. The other answers say things that make sense in a hosting with different servers. They are correct for the scenarios they have resolved to answer, not for the scenario of the question.

To me the question makes clear that the separation is only taking place because they did not find a place that would provide everything together.


It depends on what you consider normal. Most sites are very simple and need a very simple structure. For example, it is rare the site that needs Redis in fact.

It is very rare to find some hosting that offers SQL Server and not ASP.NET. Many offer both and Redis (which I doubt is necessary).

This structure even works, but will generate traffic between the hosts, generating costs, which is not ideal and will greatly increase the latency of the site response. The more volume of access you have, the harder you will have to deal with a fully decentralised structure.

There is no way to perform better by having services that are dependent on each other in different physical locations. This will only generate greater latency with no gain.

No doubt the fact of having the load distributed can perform better than having everything on a single server, but only if the server is overloaded, otherwise it will only add latency without any gain. Only measuring to be sure when to separate servers.

If the option is to have separate servers on the same network, then the gain may be more interesting, but only in cases of large access volume. If the load is small, adding servers with dependent services to each other, although on the same network, will certainly add latency, but small and acceptable because the volume requires this.

There is also a possibility to use datacenters different to increase the availability time, after all a datacenter can go down. But if you do this, you should have full copies of all components in both datacenters. That is, it will have one or more servers in each of them containing the 3 reported services: SQL Server, Redis, ASP.NET (probably an IIS).

Even if you’re thinking about load distribution, this has to be an engineering job, not a road accident.

It’s possible, but I wouldn’t recommend doing this, it’s more complex and more costly.

Look for a place that meets every need. Azure, just to quote an example, meets.

You can take an instance where you can put the 3 services together or you can hire the separate services (usually it is much more expensive).

This site, for example, which is an example of high volume site has its own servers and organize its structure according to your need, they only use a second datacenter As a mirror of the regular structure, they do not separate each service in a different lodging. They separate services on different servers because this is one of the most accessed websites in the world.

Is your need similar to Stackoverflow’s? If not, go for the simple. Go for what you’re used to. Only create complexity in the system when the need arises.

4


I will base my premise that there is no difference between the quality of service between the contracted accommodations. I refer to the difference in quality between stays that exist.
For this answer, I will idealize that they are all the same.

This case is not as different as you think. It may not be visible, but it is common. Not among the three you mentioned, but usually between the database server and the application.

Even if you hire a single host, it doesn’t guarantee that everything you put will be on a single server, and that’s what usually happens.

When configuring the database, application and redis you will point out the location, that a host gives you the access data, but is not sure that they will be on the same server. Different hosts are just different servers (this does not take into account the quality of each one).

There are some points regarding separating services into different hosts, which are:

Security

Your WEB server becomes available to anonymous users, taking into account that something is not as it should be, you leave your database and other information insecure, for some security failure.

And we take into account that if one of the hosts is "accessed externally", you will have time to prevent yourself before reaching others.

Performance

If it is configured correctly, you will not have performance loss, on the contrary. You are required to make requests, regardless of whether you are on a host or not. Large companies such as Google, Facebook and Stackoverflow use differentiated servers, precisely for performance issues, among others.

It is very common to see in large companies a host only for load balancing, which helps keep the service online (of course, this is usually implicit, but happens).

Scalability

One of the biggest difficulties today is scaling the hardware needed for the system to work. Separating into hosts, you can make a better differentiation of where the bottleneck is and whether or not you need to change hardware settings.

UPTIME

As @Ciganomorrisonmendez said in his reply, you can keep your application running even if one of these hosts falls (except for the application, logically).
Today you have tools to cache your system and ensure almost independent functionality, using some features to save the data in case the database host stops working. Of course, you need to prepare your application for this, but it is possible.

Costs

Separating your system into different stays, generates high costs in your services, which can generate problems for many.

Complexity

The difficulty of maintaining three accommodations is greater than one centralized one. This will generate greater complexity to keep the application running. A poor configuration of these features may lead to application malfunction and/or performance loss, as many say.

References:

Browser other questions tagged

You are not signed in. Login or sign up in order to post.