6

I have been developing n-tier applications using .NET for many years. But I still have no idea how to distribute the tiers/layers (dll) to other servers.

Let say, I have an MVC web application with 4 projects, i.e. MVC (UI), Business, Service and Data. Everything works fine if all class library dlls are in one server.

If I want to scale out the application by distributing the Service layer (dll) and Data layer (dll) to other 2 servers, should I convert the class library to WCF Service Library project (with TCP or pipe as communication protocol for better performance) ? Or should I use other technology like .NET remoting or Web API?

Will that be a lot of work?

Is that one of the purpose of creating multi-tier application?

Thanks.

Update:

Do you have any links (from Microsoft) that explain in detail how to scale out an n-tier architecture application to multiple server by distributing the DLL?

EpoWilliam
  • 113
  • 1
  • 9
  • Why cannot you copy the DLLs on other servers? If you use WCF/Web API your calls will be slower. Having a common repository is not the best way for scalling and can have an impact on your SLA – glautrou May 05 '14 at 08:44
  • I can "scale up" my server by adding more RAMs and CPU power until reaching the limit of IIS server can handle. So I need to "scale out" by adding more servers. I want to distribute the Service layer and Data layer to other servers to off load my IIS main server. Calling WCF / Web API on other server will be definitely slower compared to direct invoke of the dll on the same server. But after reaching the bottleneck of one server, there is no choice but scale out by adding more servers. – EpoWilliam May 05 '14 at 09:37

3 Answers3

2

If I want to scale out the application by distributing the Service layer (dll) and Data layer (dll) to other 2 servers, should I convert the class library to WCF Service Library project (with TCP or pipe as communication protocol for better performance) ?

Yep, since they are on different machines, you need some kind of communication mechanism that goes beyond simply DLL invocation.

Or should I use other technology like .NET remoting or Web API?

Which approach you choose depends on many factors like complexity, performance...There are many options like

  • WCF webservices
  • Simple REST calls with WebApi
  • a message bus i.e. NServiceBus
  • ...

Obviously remote calls will also be slower having a potential impact on performance etc.

Will that be a lot of work?

It will be more work and in my opinion that "more work" should really be justified. Keep your architecture as simple as possible or better, only as complex as really needed.

An alternative approach could be to have some deployment pipeline that deploys your entire application on different server instances and have some intelligent load balancing strategy. The only thing you need to pay attention to in that case is to properly share the sessions between your instances (stateless would be better ;) ).

Juri
  • 32,424
  • 20
  • 102
  • 136
  • Please correct me if I am wrong. As far as I know, WCF Service Library using TCP protocol will be the fastest way for remote DLL invocation (compared to .net remoting, SOAP web service and REST Web API). The IIS server and the DLL server should be next to next connected using network cable (Cat 5). – EpoWilliam May 05 '14 at 09:46
  • @EpoWilliam sure, however I never tried that by myself (yet). – Juri May 05 '14 at 15:19
0

My 50 cents... As far as I know WCF replaced .NET Remoting (MSDN).

Anyway... Someone before me said. If you don't have to scale the application, do not do it. Communication cost alone between services of any kind will slow things down considerably. Probably to extent, where it would be slower than it is now (which I am assuming is the reason for scaling).

Prior to scaling, I would first see where the bottleneck really is. For instance, if the problem is your DB server, then moving services and data layer to another server is useless, as you will still be using the same database. So, you need to first find out what your bottelneck is.

The easiest and least painful way to scale (in my opinion) would be to just add another IIS server and a load balancer that would direct traffic to either one of them. You would need to store sessions in a database or use dedicated server, but that is about all the change you will need. Plus, if one of your server fails, one will still operate.

Vladimir Kocjancic
  • 1,814
  • 3
  • 22
  • 34
0

By default, avoid premature optimalization.

If you have a only web site, I would keep it as simple as possible and only create logical layering. There are a number of options: typical 3 tier, onion architecture etc. The key is that later, if really really needed, you could still refactor your code and make your data layer a separate physical layer. But unless you are creating a new Amazon or something, this will probably not be the case.

If you are in the situation, for example, that you have a web site, but also have to expose a web api; you could choose to have the web site consume the web api. In fact, your web site would then become a very thin layer (maybe not even using ASP.NET MVC) because most of the logic would be in the web api.

PS - .NET remoting is old technology, consider WCF or Web API instead.

Community
  • 1
  • 1
L-Four
  • 13,345
  • 9
  • 65
  • 109