Let's create some boundaries for our discussion. The best practices for Designing & Deploying SaaS are relevant for an environment where users are consuming SaaS over World Wide Web and planning to meet the AAA expectations. Address them at the design time to minimize the deployment and operations challenges.

• Optimize Software Framework & Tiers: Understand that each tier increases the operations complexity and each software library brings performance or resource overhead at the run time. Hardware is cheap but running that host is not. So, keeping two logical tiers on a physical tier provide savings in multiple areas and specially reducing the operations complexity. As you see in 4 tier architecture by just combining two logical tiers over one physical tier it cuts the operations complexity into half and dropping an entire tier drives your operations towards simplicity.
• Security & Service Level Agreements: Start with locking down every thing from network or host perspective and open only what needs to be open. It’s very difficult to implement firewalls at later stage. Use SSL offload as much as possible as L4 switches providing these capability are highly optimized for it than application servers. If you are B2B and B2G consider allowing traffic by 2 way SSL to minimize the hacking/cracking risk. Implement Open Source Web Application Firewall that protects you from the known hacking/cracking activities and gives you an ability to quickly block new vulnerabilities by signatures. Understand the SLA of availability & load and make sure to set rate limiting or throttling as if you agreed to accept 100000 requests per day but didn’t understand what comes every min, may break your system. Set parameters for your developers like under 600ms for a web page to render and under 200ms to tcp/rmi calls. This is important to set early enough to make right decision for software design and provides an opportunity to scale economically in production. Service level expectations are something that your clients legally can’t take actions against you but will use them against you at the time of renewals. So, understand them and have room in your design & deployment to meet these expections to keep the customer happy.
• Load Sharing and DNS TTL Settings: The word load sharing is confusing as most tools either load balance by users or requests not by actual pay load created by them. As we are multi site at minimum we have implemented the DNS rotor kind of solution that round robins the traffic between your sites. GSLB is dynamically routes the traffic based on the availability health checks of your sites. If a site is down, it automatically keeps that site out of rotation. Implementing GSLB in-house vs. outsourced. Consider the fact that what business values it has for you. If your data centers are 20 miles apart and outsourced solution like Akamai gives you health checks and user mapping to site based on distance is not useful for your model. Understand the business value and make a decision. On L4 VIPs, I like to use Round Robin and Least Connection load sharing algorithm. These both will perform at the same level for http and https traffic but for tcp/rmi traffic least connection performs better than Round Robin. Most L4 VIPs default config is Round Robin. You are multi site, so you need to make sure that your DNS cache expires immediately or max time to live i.e. DNS TTL is set to 120 seconds. Otherwise, when you bring a site out of rotation, users will experience a bad behavior of non-availability.
• Forward vs. Backward Compatibility: Understand the business and the market you are in and make a choice between Forward and Backward Compatibility. If your business model can sustain than design your SaaS with forward compatibility compare to backward compatibility for higher profitability. As we operate businesses for profitability not for revenue.
• Coupled vs. Decoupled Interfaces: Let’s first understand, what I mean by coupled vs. decoupled interfaces. In a horizontal integration environment when a change in lower stack needs corresponding change in upper stack, then they are operating under coupled interfaces. If not, than they are operating under decoupled interfaces. Create coupled interfaces only if it’s creating a business value for you otherwise create decoupled interfaces so both parties can innovate independently. Coupled interfaces have high maintenance cost compare to de-coupled interfaces.
• Synchronous vs. Asynchronous: In a transaction in real life we create lot of logging events for various monitoring and reporting activities. It is a good practice to spin a new independent thread for logging events. That helps perform better compare to same thread needs to complete everything. Mostly batch jobs creates problems for real time end user activities, it’s a good practice to invest into a miniature environment for batch jobs to avoid performance issues. Only real time response activities should use Synchronous communication.
• Stateful vs. Stateless: World Wide Web is stateless and see if your design can support that for deployment & operations simplicity. For performance reason, if you need Stateful and if your user is routed from server A to server B and there is no end user impacts other than it takes little longer to serve the customer. You are still ok. But, if your application functionality breaks without Stateful setup than implement application server clustering solutions and don’t create more than three nodes in a cluster as bigger size cluster adds overhead than any added benefits to it.

Disclaimer

The thoughts expressed in the blog are those of the author and do not represent necessarily the official policy or position of any other agency, organization, employer, or company. Assumptions made in the study are not reflective of the point of view(s) of any entity other than the author. Since we are critically thinking human beings, the point of view(s) is always subject to change, revision and rethinking at any time. While reasonable efforts have been made to obtain accurate information, the author makes no warranty, expressed or implied as to its accuracy.