Building a SaaS Style Application


Published on

Published in: Technology
  • CelloSaaS, a .Net based Multi Tenant SaaS Application development Framework adheres to the above aspects mentioned in this article, as well as offers many Engineering and Business Capabilities to speed up the Development time, Cost and there by increases the Time to Market, Click here to visit us
    Are you sure you want to  Yes  No
    Your message goes here
  • good written!
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Building a SaaS Style Application

  1. 1. Building a SaaS Style Application SaaS Patterns – A Problem-Solution Approach Abstract Software as a Service (SaaS) adoption is on the rise in the enterprise world, driven largely by its promise to deliver „capital expenditure avoidance‟, „quicker time-to-market‟ and „reduced risk‟. To capitalize on the SaaS wave, Independent Software Vendors (ISVs), Service Providers (SPs) and Service Centered Businesses (SCBs) are quickly moving to deliver service from the Enterprise Cloud [1]. Usually, such vendors are focused on product/service features and not on serviceability. This makes the challenges in transition to a „SaaS Provider‟ easier said than done. This article discusses 7 Key Challenges in architecting software to be delivered as a service. Introduction If you are in the software industry, chances are that you have heard the term SaaS by now. Companies like have been extremely successful in bringing this concept to reality and opening up untapped markets for business. Chances are very unlikely that you will be constructing a full blown SaaS application to be marketed worldwide; but you can take key concepts from „SaaS Construction‟ and build your next in-house application in SaaS style, still reaping most of the SaaS architectural benefits. You will be amazed that any Google search on SaaS throws up hundreds of results on the business side of SaaS and very little on the technical side. While one can get low level technical details on the data modeling side of SaaS from the Microsoft website, as a technologist you will need more patterns to jumpstart your SaaS journey. The following article is a compilation of my thoughts to fill the void I found.
  2. 2. ‘SaaS Patterns – A Problem-Solution Approach’ 1. Problem (Database) Business problem: How can business lower the „cost of service‟ without compromising on QoS? Technical cause: Can a single database instance be used to capture many client‟s (tenant) data, thereby promoting economies of scale? How will architectural attributes like Performance, Extensibility, Security, Customization, etc… handled in multi tenancy? Solution A simple, yet elegant solution, to this problem is to insert Client Id (Tenant Id) as an additional column in each table storing multi-tenant data. Now, how do you make this solution cope with extensibility, performance and security requirements? Extensibility: For extensibility, the data in the database can be held in an XML CLOB without defining a hard schema. As extensible as XML is, it brings its own downsides in CRUD operations – XML queries are relatively slow and cumbersome. If XML is not a preferred option, you can design tables with generic columns or extension tables (tree structure) for handling extensibility. Performance: Generic design and performance generally don‟t go very well together. In most instances, to scale one you have to sacrifice the other. One workaround to this problem is to accommodate key search fields within the data model. This will assist in faster SQL-based querying. Security will be handled in the next section. Fig 1. Tenants having a separate database each versus a shared multi-tenant database in SaaS
  3. 3. 2. Problem (Database - Security) Business problem: How will the customer‟s „IP Protection‟ & „Data Security‟ be guaranteed? Technical cause: How will data security be enforced at the Architecture level? Every resource should be locked down with the tenant details, so that even if hacked by application developers one tenant‟s data should not be made available to others. Solution You cannot protect something if you do not know where it is. So, the first step in ensuring client data security is to add a Tenant ID column to all the tables in the database. However, this alone is not going to provide the required level of security - we cannot rely on developers who write the queries to be mindful of security concerns. The next level of securing client data involves preventing unauthorized access at the database level. This requires some kind of support at the database level. To achieve this in a SQL Server environment: 1. Restrict direct access to tables for tenants; administrators can be given direct access 2. Create a unique database ID for each tenant 3. Map tenant ID to database ID in a particular table 4. Create table valued functions which take the tenant ID and return the data as a table 5. Create a view that calls the table valued function 6. Give access to the view for tenants If you are using an Oracle database, then Oracle‟s Virtual Private Database (VPD) / Oracle Label Security (OLS) can be used to come up with a solution. Similar implementations are feasible in MySQL. The advantages of this approach are that security is handled at the architecture level and is fool proof from hackers. Additionally, there is no overhead for developers and it provides for transparent handling of tenant details. Fig 2. Security relying on Tenant‟s good intent versus security enforced at database level in SaaS
  4. 4. 3. Problem (Meta Data Services) Business problem: How can SaaS service providers be agile to their customer‟s needs? Technical cause: How can configuration data kept minimum thereby enabling simplicity? Every component in the system can have its own configuration structure ending up in a separate file or table. The meta-data will increase exponentially as the number of components & number of tenants rise. Solution Most components have their default meta-data values and tenants do not always override the default setting. In many situations, a hierarchy of default values exists. For example, a company can set some default settings, and at the next level a department can have its own settings, etc. Now, we end up with two main themes 1. Meta-data hierarchy (e.g. user-department-branch-country-company) 2. Overriding Priority (In a meta-data hierarchy, some features have top-down priorities while others have bottom-up priorities) Meta-data services should handle highly configured component meta-data and less configured meta data in slightly different ways. The following solution is applicable for meta-data with low levels of tenant overriding. (While the solution discusses configuration files only, the same applies to database configurations as well.) 1. The default component meta-data should be stored in the application level folder structure. 2. A similar folder structure should be maintained for every client who overrides the default data - note that only the files that are overridden should be saved for that tenant. 3. At the time of client login or application startup, the meta-data service should load all the tenant hierarchy and tenant specific configuration and super impose them in the right order to obtain the tenant-specific data. Meta-data services can also exhibit an event notification mechanism using the “publish-subscribe pattern”, where any changes to the meta-data can be communicated to the layers above. Note: Depending on the complexity of the solution the meta data services component can be build from ground up or a FOSS framework like Obix, JFig, etc… which can be used/extended.
  5. 5. Fig 3. Hard coded logic in component for handling multi-level configurations versus a generic & structured approach to multi-level user/tenant level meta-data handling in SaaS
  6. 6. 4. Problem (Tenant aware Controller) Business Problem: What technical assets will speed up a SaaS service provider‟s time to market? Technical cause: How can the application controller navigate the tenant to the next tenant specific step? Navigation can range from a high level of navigating from the business logic to the view or business logic to data access or any macro level step. Solution Navigating or Tenant Flow Orchestration is an extension of the Controller component from the MVC design pattern. The Controller has the base flow or orchestration configured. Within a SaaS framework, we need to slightly change the way the Controller handles event orchestration. When the Controller receives a service request, instead of directly handing over to the next step, the Controller should call the meta-data services to get the reference for the next step. When there is customization or overriding performed at the tenant level, the meta-data services will return this information which will be used by the Controller for orchestration. For example, a business service A may have AI.jsp as the input screen and AO.jsp as the output screen. If this action requires customization for 5 clients with different input & output pages, one way to handle this is to hard code the input & output jsp in the controller XML under 5 customized actions. A much better way of doing this is to have one service A defined with logical input & output pages and let the controller get the absolute pages from the meta-data services. Fig 4. Controller in MVC referring to absolute resources versus a Logical controller doing absolute resource mapping with the help of a meta-data services layer in SaaS
  7. 7. 5. Problem (Infrastructure Services / Setup) Business problem: How to guarantee „High Scalability & High Availability‟ of my SaaS service? Technical cause: Even though SaaS promotes economies of scale through multi tenancy at times we could be forced to take tenant specific actions to achieve scalability and availability. Solution Having a group of application clusters and letting all tenant users hit servers through a load balancer is a simple solution which will work for most SaaS implementations. However, the service provider might also have a tiered Tenant model and/or different SLAs for different tenants. In the latter case, you will encounter the following specific requirements from the infrastructure deployment: 1. Performance & Scalability throttling based on Tenant Priority 2. Reduced static deployment downtime based on Tenant Priority The solution is to form tenant clusters, so that there is segregation of tenants by priority and SLA requirements. To achieve this routing you need a “Tenant Aware Load Balancer” to route requests appropriately. The login authentication could be done on a common server but further requests should be routed to the tenant farm at the load balancer level rather than at the application level. While deploying this solution, you should also take care to achieve the following: 1. Prevent tenants from requesting resources when a tenant specific deployment is underway. 2. Retain tenants with high priority/ low latency SLAs in dedicated clusters so that they do not face downtime while services for other clients are being deployed. 3. Segregate clients with lower priorities/ lower level SLAs into shared clusters where you can utilize the scheduled downtime to run updates/ service deployments without facing SLA penalties or customer dissatisfaction 4. Every tenant should have at least one backup server in the cluster to ensure availability.
  8. 8. Fig 5. A Load Balancer routing requests to a common server cluster versus an intelligent load balancer routing to common, tenant specific clusters & Security service in SaaS
  9. 9. 6. Problem (Performance Throttling) Business problem: How to design a „SaaS service‟ to provide client priority based servicing? Technical cause: Caching at multiple levels is one of the best ways to improve application performance, how to take advantage of application level caching with tenant priority? This problem not only applies to caching but also to places where tenant priority based processing needs to be done. Solution Caching solutions range from a single JVM cache to a distributed cache to caches at other layers like database etc. Best practices like setting the maximum cache size, expiry policy, etc… improve cache and overall system performance. In a SaaS application, it is always better to have flexibility to serve important tenants quickly. This means that a caching solution or a service queue pattern has to include tenant priority in its processing logic. For example, a cache solution should indicate the maximum cache size permitted for each tenant and should be able to keep track of it, instead of just tracking the overall cache size at the application level alone. It should have the ability to remove objects based on tenant priority algorithms. A similar solution can be extended to service queues or other places where tenant priority based processing is required. Fig 6. Multi-level caching at the application level versus multi-level caching with tenant awareness to control the tenant cache size and expiry logic in SaaS
  10. 10. 7. Problem (Error Handling) Business Problem: How can client delight be improved by addressing client specific issues faster? Technical cause: Error handling is very important to debug production problems; needless to highlight its importance in a multitenant environment. Logging style of Distributed components & different layers could differ. „Log time‟ is crucial in co-relating the logs to understand the big picture; multiple time reference (machines/zones) adds another layer of complexity to this problem. Solution There is no single silver bullet that gives a readymade solution to all of the above stated challenges. But careful selection of a few can address most problems: 1. Considering log as a “Separation of Concern” and using AOP for logging 2. Consolidating error handling in a single area using the “Fault Barrier” pattern 3. Using Asynchronous log mechanisms 4. Logging to a centralized place using a queuing mechanism Distributed high performance low latency applications can log using a queuing mechanism. Depending on the criticality of the logs, a memory buffering technique can be used to minimize IO operations, if the downside of losing a few messages (rarely) is acceptable. Fig 7. Application level logging to a common file versus tenant specific synchronous / asynchronous logging using the Fault Barrier logging pattern in SaaS
  11. 11. Conclusion To the technical community, SaaS is an IT service deployment methodology that is becoming increasingly popular and which they need to understand and use to stay current. To ISVs, BSPs and EHSPs, SaaS has the potential to open up an untapped market with significant revenue possibilities. The SaaS business model, with its inherent cost advantages, may only be a few years old, but the core concept of application resource sharing at various architectural levels has been with us for a long time. It is just that recent technological advances have opened up new and economically viable ways of addressing the problem of sharing resources. Having said that, enterprises exploring the SaaS platform as a new/ alternative business channel should also realize that the technical implementation framework is as important as the business model supporting the venture. Ignoring the technical aspects of SaaS implementation is a sure way to facing downstream business disruption issues. This article is not intended to cover everything under SaaS Patterns, but intends to be one of the first compilations of SaaS design patterns which, hopefully, will get critics, enthusiasts & supporters to begin contributing to this discussion and help grow the knowledge base. Few other notable SaaS areas which need problem-solution patterns are Identity Management, Security, Integration, Monetization, Workflow and User Access Management. References [1] “ The State of Enterprise Software: 2009” Source: Forrester;jsessionid=ZIPBUCLLD1JGSQSNDLRSKH0CJUNN2JVN?pgno=1