Scaling applications using Techcello Framework-

Part2
blog.techcello.com/2013/07/scaling-applications-using-techcello-framework-part2/
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
Optimization:
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 thats 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.
Presentation Layer
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
Application Layer
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.
Database 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:
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 tenants requests to the respective server. For example
Tenant 1-n Tenant n+1 2n
PMS Server1 Server2
HR Server1
Techcello Scalability Architecture
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.
Reference
http://msdn.microsoft.com/en-us/library/aa291873(v=vs.71).aspx
For more information: info@techcello.com, www.techcello.com