For any enterprise level applications, scalability is of paramount importance. But scalability is associated with many challenges too, which needs to be addressed right in the design phase itself. It could be very difficult to add scalability feature later in the development phase, because it needs a change in the overall architecture only.Before understanding the challenges let dig down the scalability term itself.
Typically, in an enterprise level application world, scalability is of two types.
1. Vertical Scaling : Where you increase the system capability (normally in terms of CPU, RAM etc.) which is responsible for service responses.
Suppose you have a IIS web server, which is hosting an ASP.NET application or WCF Service application. Initially, when 100 clients are accessing these applications(or services) and after sometime you have 10000 clients. So, now you have upgraded the system itself where this IIS web server is residing.
For such kind of scaling you need not to modify your application as such. So, no development cost is associated with vertical scaling. But such vertical scaling will not give you major benefits. Because you are still restricted with a single server.
2. Horizontal Scaling : Where you add more servers to improve the overall performance of the systems. Addition of servers will give you major scalability boost. And you can use load balancers to distribute the requests to different servers. If configured properly, request can be diverted to different servers and response can be given back to clients more efficiently. Load balancers could be of different types such as
- Software Load balancers : such as NLB (network load balancers) which can distribute the load to different servers using programs
- Hardware Load balancers : where load balancing is done at hardware level using network equipments such as routers
With the help of horizontal scaling, you can reap the benefits of distributed system. Although you would like to add more and more severs to provide scalability with minimum configuration changes, but horizontal scaling comes with its own challenges. Lets discuss few of them here.
Challenges & Solution : The most important challenge is “Server affinity”. When a request is generated by a client then a session is created between the server and client to provide responses. So a particular client has a server affinity of a particular serving server. So, if you want to have more servers able to respond to client requests, you need to find a mechanism to avoid this server affinity. So that any other server in the web farm can respond to the client requests. So, you need to find a workaround for session state.
There are multiple ways to do it. One widely used solution is to use “Sticky IP”, where the request of a particular client can be diverted to a particular server only by a load balancer. In case of WCF services, such behavior can be incorporated in the bindings (for example by disabling HTTP keep alive feature in basicHttpBinding or WebHttpBinding).
Think of an ASP.NET enterprise level application. You could use out of the box features provided by Microsoft to store the session states (such as InProc, StateServer, SQL Server). Where session states can be stored either in memory ( InProc) or it could be persisted to some SQL server database. Another solution could be distributed cache mechanism. One excellent article on using distributed cache can be found here.
Whatever mechanism you adopt, but you have to have these things incorporated right from the design phase. Otherwise, it can substantially hamper your project life cycle in the long run.