Read the first part of the article from here
Scale out or Scale Up
The Type of business or domain that the application deals with can sometime persuade the scalability architecture of the application, in the case of Gaming or financial solutions where latency cannot be conventional and provide maximum throughput, so it is wise to avoid separating the business logic or processors kept in two different logical units, and it is advised to have both the operations within a single processing unit, where the complete workflow or process can be completed without connecting to the external unit or resources.
For other software applications such as CRM, ERP or other kind of system, it is ok to have acceptable latency within the architecture in order to be more scalable. There are various strategies can be adopted to build a scalable applications, they are
There is no point in developing a scalable application without optimized for performance of the application itself, for example, if a particular operation takes 5 seconds to complete with the given code, well optimization can help you to complete the task within 3secs that’s almost 50% of time reduction in processing and hence improve the system to handle 50% more tasks with the single unit. Application Optimizing has direct relationship with performance which also leads to cost saving which also helps in scaling the application. Optimization helps in making the piece of software work better by utilizing less resources and hardware but yet provide the maximum performance and hence the less number of instance can handle more request and response. Application optimization has to be done at all the layers of the application, i.e.
- Presentation Layer
- Application Layer
- DB Layer
For each of the layers, there are variety of different techniques and approaches can be taken to better optimize the application.
Optimizing the presentation layer involves speeding up the page loading time, enabling caching for the static data, introducing CDN, Compressing the output pages and images etc. Designing the web layer to process asynchronously and employing DLINQ and Parallel Processing can use the hardware effectively
Deployment of Intelligent distributed Caching mechanism, optimizing the code and building the components and modules in SOA based module can help in scaling the solution in the application layer.
Indexing the tables based on the usage. Optimizing the long running queries, caching the queries, partitioning the tables based on various factors can help in Scaling the application at the Database Level.
Specialization is the process of isolating the mostly used modules separately from the rest of the features and functionalities. When said, the module should be self sufficient and should be able to take care of the whole process/workflow by itself without depending too much from the rest of the modules, the primary benefit of this approach is to make the features independently scale, For example in a typical CRM application, out of all the features and modules, Sales module is one which is mostly used one, in this scenario instead of collocating or coupling such features with other modules it is wise to build as standalone and self sufficient module.
To embrace Specialization, it is important to build functionalities independent and modularized and use consistent messaging pattern to interoperate with other components.
Scalability in CelloSaaS
CelloSaaS can be scaled out either by scaling up or scaling out. Scale up is straightforward. Let us see how the different layers of the celloSaaS application can be individually scaled out.
Cache Layer: CelloSaaS supports Distributed cache such as AppFabric, Amazon elastic EC2. This ensures that the cache layer can be scaled out by adding more nodes if there is a higher memory requirement for cache. This also ensures that the cache is centralized and hence supports the web servers on scaled out scenario.
Database Layer: CelloSaaS supports vertical partitioning by modules as well as database Sharding by Tenants.
Module Based Vertical Partitioning
Different modules can be modeled to reside on different servers based on the load. Data belonging to modules is grouped to data groups. For examples in a HR system, the Core HR module and Leave Management Modules can be grouped under “HR” Data group and Performance Management Data can be grouped under “PMS” Data group. Each data group can reside in its own server. Example, “HR” Data group can reside on Server 1 and “PMS” Data group can reside on server 2. During development the application models the data as per data groups and passes the data group name while dealing with database operations via cello DB APIs. Cello maps the data group to the location of the servers and connects respectively to the right servers and fulfills the request.
Tenant Based Sharding
Even though an application data is vertically partitioned there might be a need to further scale out the data within a single data group to multiple servers based on load. Cello supports this by providing the ability to have data in multiple servers based on the tenant. In the above example let us assume the load on the PMS data group is high and we want to further scale out the data of PMS to multiple servers. Cello supports this by allowing each data group data to be sharded further by tenant identifier. As per cello each data group and a tenant combination can reside in a server. While using Cello DB APIs cello automatically routes the tenant’s requests to the respective server. For example
|Tenant 1-n||Tenant n+1 – 2n|
Web Layer – This is responsible for rendering the user interface. CelloSaaS advocates the following principle to scale out this layer.
Session Usage – CelloSaaS does not use session for storing any data. If the application needs to store session celloSaaS mandated out-of proc session storage. This ensure that the application is stateless and hence can be easily scaled out
Cache Usage- CelloSaaS uses AppFabric distributed cache as the caching layer. This ensures that the memory state of cache is centralized and hence the application becomes stateless which is necessary to be scaled out.
Application Layer- This is responsible for the web service driven business layer. CelloSaaS advocates the following principle to scale out this layer
Per Call Services- All services are per call instances and hence can be scaled infinitely
Cache Usage- Application Layer also uses centralized caching mechanism of AppFabric which ensures that the application layer is stateless and hence can be scaled out.
For more information: firstname.lastname@example.org, www.techcello.com