Cello saas scalability architecture


Published on

Cello saas scalability architecture

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Cello saas scalability architecture

  1. 1. CelloSaaSScalability Architecture
  2. 2. 2CelloSaaS : Scalability ArchitectureScalability in CelloSaaSCelloSaaS can be scaled out either by scaling up or scaling out. Scale up is straightforward. Let us seehow the different layers of the celloSaaS application can be individually scaled out.Production Deployment ArchitectureUserLoad BalancerUser UserLoad BalancerActive – ActiveClusterPrimarySecondaryCachingCachingCache ServerFarmWeb Server FarmApplicationServer FarmBatch ProcessingServer cluster-VMSingle Database Server OR Partitioned Databases by modules and ClientsSingle Hardware Single HardwareCache Layer: CelloSaaS supports Distributed cache such as AppFabric, Amazon elastic EC2. This ensures thatthe 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 byTenants.
  3. 3. 3CelloSaaS : Scalability ArchitectureModule Based Vertical PartitioningDifferent modules can be modeled to reside on different servers based on the load. Data belonging tomodules is grouped to data groups. For examples in a HR system, the Core HR module and LeaveManagement Modules can be grouped under “HR” Data group and Performance Management Data can begrouped under “PMS” Data group. Each data group can reside in its own server. Example, “HR” Data groupcan reside on Server 1 and “PMS” Data group can reside on server 2. During development the applicationmodels the data as per data groups and passes the data group name while dealing with database operationsvia cello DB APIs. Cello maps the data group to the location of the servers and connects respectively to theright servers and fulfills the request.Tenant Based ShardingEven though an application data is vertically partitioned there might be a need to further scale out the datawithin a single data group to multiple servers based on load. Cello supports this by providing the ability tohave data in multiple servers based on the tenant. In the above example let us assume the load on the PMSdata group is high and we want to further scale out the data of PMS to multiple servers. Cello supports thisby allowing each data group data to be sharded further by tenant identifier. As per cello each data group anda tenant combination can reside in a server. While using Cello DB APIs cello automatically routes the tenant’srequests to the respective server. For exampleTenant 1-n Tenant n+1 – 2nPMS Server1 Server2HR Server1Web Layer - This is responsible for rendering the user interface. CelloSaaS advocates the following principleto scale out this layer.Session Usage - CelloSaaS does not use session for storing any data. If the application needs to store sessioncelloSaaS mandated out-of proc session storage. This ensure that the application is stateless and hence canbe easily scaled outCache Usage- CelloSaaS uses AppFabric distributed cache as the caching layer. This ensures that the memorystate 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 thefollowing principle to scale out this layerPer Call Services- All services are per call instances and hence can be scaled infinitelyCache Usage- Application Layer also uses centralized caching mechanism of AppFabric which ensures thatthe application layer is stateless and hence can be scaled out.For more information: info@techcello.com, www.techcello.com