Software development is different for SaaS companies. Product cycles are shorter, sustaining costs are dramatically reduced, and the technology used must be more current. Existing software companies with development staff more comfortable with client/server than modern web technology may need to assist their development personnel in improving their ability to do multi-tenant, web-centric software. Companies need to move away from legacy technologies such as Flash, Silverlight, and Windows Presentation Foundation (WPF) in favor of newer (if less mature) technologies such as HTML5, CSS3, JavaScript, and jQuery.
The Architecture is REALLY Important
Optimal SaaS Architectural Traits
Bad software architecture is so much more apparent in SaaS products. On-premise products that run on dedicated servers or VMs that support a hundred or so users may not scale well when run with dozens orF hundreds of other tenants simultaneously. Even if horizontal scaling is possible, inefficient use of resources can raise the cost of providing SaaS services above the target of 10% of the Monthly Reoccurring Revenue (MRR). Developers must also be aware of the latency issues that can cause poor performance on public clouds if proper optimization is not done. Security must be fundamental to the architecture given the nature of shared resources of many clients all behind the same firewall.
There are so darn many Choices to make
- There are new(er) languages and tools that may not be well supported by current IDEs (Integrated Development Environments) — Microsoft’s Visual Studio 2012 finally provides decent support for HTML5 now that Microsoft has moved away from its proprietary platforms such as WPF; Eclipse still can be cumbersome…
- The decision about which IaaS to use meaningfully impacts SaaS development. The developers must code to specific IaaS APIs related to deployment, load balancing, and scaling. Given a lack of standards on these APIs, there are many incompatible alternatives. Amazon AWS has the leadership position, but OpenStack (led by Rackspace with technology from NASA) and now CloudStack (with technology from Citrix with their purchase of Cloud.com) provide open source alternatives to the AWS proprietary IaaS APIs.
- PaaS can mitigate many of the complexities of SaaS implementations by providing the middleware, such as databases and support for specific languages like Ruby or Python, “taking care of” many of the details associated with managing the deployment and scaling of SaaS applications. Unfortunately, there is even less standardization of PaaS than IaaS. There is a legitimate concern among SaaS vendors of the lock-in to a specific PaaS API even more so than with IaaS APIs. There has also been much less open source standards activity in PaaS. Software development organizations must decide if they will adopt a PaaS platform or “roll their own” implementation on a lower level IaaS stack.
- There are many decisions related to selecting and integrating with third party tools to provide essential capabilities to the IaaS product in areas such as testing, billing, auditing, multi-tenant enabling, and system monitoring. These may be provided by a third party package such as Zuora or Metanga for billing. Products such as RightScale provide both SaaS management tools and a layer to provide vendor independent IaaS APIs.
Some code and schemas can move to the Cloud
For existing systems, there is a wide range of the legacy code that may be transferable to SaaS. There may be a transitional period where the code is initially repurposed for the SaaS implementation, but is refactored over time. For the server code, this may entail more efficient and scalable code and more effective multi-tenant architecture with greater resource sharing between tenants. Corent Technologies provides middleware for Java together with SaaS management tools that can assist in the conversion of on-premise code to SaaS. Apprenda provides a PaaS implementation for .Net implementation which can assist in the conversion of existing code or the building of new SaaS software.
Some companies share a common schema between their on-premise and their SaaS offerings. If the databases are shared with multiple tenants, there is likely a tenant-id in the SaaS implementation. Companies like Sage allow a mixing of on-premise and SaaS software sharing the same data. Other companies such as Cherwell Software allow their customer to move freely between a SaaS hosted and on-premise model with the same data.
SaaS Drives Death of Rich Internet Applications
World Class SaaS software will eliminate the requirement for rapidly obsolete Rich Internet Application (RIA) frameworks including Flash, Adobe (Apache) Flex, JavaFX, and Windows Presentation Framework (WPF)/Silverlight. Particularly, please get rid of the requirement for any SaaS application to require the a Java Browser Plugin with its frequent update requirements, significant security vulnerability risk, and the horrific Ask Toolbar Crapware that many users will inadvertently get infected with frequent Desktop Java updates.
These heavy weight plug-in add proprietary bulk, increase security vulnerabilities and bog down the browsers. Updates to these RIA plugins often requires user intervention and complicates enterprise IT. HTML 5 is rapidly addressing the requirements provided by these RIA proprietary frameworks in areas such as HTML5 Video Elements and Video Content Protection via the W3C Encrypted Media Extensions.
SaaS Means HTML5 for the Desktop
New products will dominantly employ HTML5 technology on the desktop as the basis of their client software which is well suited for SaaS enablement. HTML5 provides the ability to provide the capabilities of Rich Internet Applications (RIA) without legacy plugins. Microsoft (Silverlight) and Adobe (Flash) are moving away from their RIA support in favor of HTML5.
Many software companies have been reluctant to adopt HTML5 for their enterprise applications because of the high (40%) penetration of XP in the marketplace which does not support a version of Microsoft’s Internet Explorer (IE9 or greater) required for HTML5. With the discontinuation of support of Windows XP by Microsoft on April 8, 2014, those customers on Microsoft platforms not supporting HTML5 will diminish very quickly. Most modern browsers (Chrome, Firefox, and Internet Explorer) have moved to a model of automatically updating their browser, solving the age old problem of supporting old browsers and ensuring that compliance with the HTML5 emerging standards happens quickly.
Mobile Might Require Native Apps
Developer Economics, July 2013
The majority of SaaS applications required both a desktop and mobile version. While HTML5 is rapidly become de rigor on desktop, its use on mobile platforms is situational based on the application requirements. The choose of the appropriate development platform will change as HTML5 matures and begins to support more demanding User Experiences and greater access to the mobile device’s hardware and APIs. The basis for choosing between Native Mobile Apps and HTML is covered in depth in the Cloud Strategies article, Choosing between HTML5 and Native Mobile Apps.
SaaS Means Published APIs
The SaaS architecture involves developing a fast, secure, and easy to use data services layer that is the foundation of a public API. SaaS products should have APIs to allow development of additional capabilities by VARs and third party developers, integrate with other software packages especially analytics and Big Data applications, and provide services to mobile applications. Unlike on-premise applications, customers can’t access the data directly on a machine they control — the only access to the data is through the API the vendor provides making a complete set of APIs essential.
A cautionary note is that published APIs must be consistent, dependable, and standard. Once published, APIs should be maintained and rarely depreciated in future versions of the software. This requires public APIs must be thoughtfully architected to ensure they are extensible.
SaaS Means Multi-tenancy
Server side development has significant new requirements. The performance requirements for SaaS environments where many tenants share the same (virtual) server are much more demanding than on-premise software supporting a single tenant. Multi-tenant shared databases require additional security to logically isolate data from different tenants on the same server. Depending on customer security demands, the software may share application servers with multiple tenants, but allow certain tenants to have dedicated data storage which does not co-mingle data between tenants. There are three models for multi-tenancy sharing: Database per Tenant, Database Schema per Tenant, and a completely shared database amongst multiple tenants with each tenant data segregated by a tenant-id within the physical data record. Corent Technologies is one middleware product that supports all three tenancy models.
SaaS Means a STATELESS Architecture
“Decompose your system into small loosely coupled, stateless building blocks”
Werner Vogels,
Amazon AWS CTO
AWS Re:Invent November 2012
Beyond multi-tenancy, SaaS systems should be architected to be stateless applications. Modern software systems expose their functionality through RESTful APIs — those service requests (completed on the virtual server) should be completely stateless for optimal performance, scalability, elasticity, and fault tolerance. When server-side applications are stateless, they can scale readily by creating more server-side machine instances when usage spikes while they can readily contract to free virtual server resources when utilization declines.
Stateless designs require storage services such as Amazon’s Simple Storage Service, AWS Elastic Block Storage, or Rackspace’s Cloud Block Storage not local to any single server which are decoupled from the request processing (server based) services accessed through (RESTful) APIs — a classic three tier architecture. These request processing services built by the SaaS company are given work by the IaaS providers load balancer — this only works with a stateless architecture where any request processing service can perform work for any client.
As stateless compute instances come and go, the storage component cannot be local to any one server instance. In the event of a server failure, the software managing the compute instances such as Amazon’s Elastic Beanstalk will “spin up” another instance to replace the failed compute instance with ready access to the data wherever it exists in the cloud infrastructure. When excess capacity exists, those unneeded virtual server instances will be released and the client application will be connected to an alternative server instance at its next interaction.
A Stateless Architecture is not a strict requirement to provide SaaS applications, but it is a requirement to provide SaaS applications with the lowest cost, highest performance and best reliability.
SaaS Requires Planning for Analytics
Big data can’t ignore issues of data locality. Moving a petabyte over a public cloud to run Hadoop on the unstructured data is problematic. Unfortunately the public cloud infrastructure doesn’t yet support the bandwidth to virtualize storage without planning for the performance ramifications. SaaS systems that produce many terabytes of data which are inputs to the data analytics processes must ensure that the data analysis can be run in the same locality as the SaaS applications.
SaaS Means Frequent, Non-Disruptive Upgrades
SaaS companies are able to rapidly release new functionality without the concern of adding to a large set of software releases which require incremental support and bug fixes. Without this large number of software versions in the field, SaaS companies can focus their efforts on producing new innovation by minimizing the resources spent on maintaining a large set of legacy releases. Companies such as NetSuite and Salesforce generally support two releases and allow their customers to migrate to the newer release within a time window generally from 6 to 12 weeks. Additionally, there isn’t a requirement to test on multiple versions of databases, operating systems, and application servers that exist in various customer sites. With typically one, two or three supported versions each with a single operating environment there is much less testing required of the system in different operating environments.
SaaS companies spend more time on innovation and less time on software maintenance. This is a huge advantage to SaaS companies and their customers over on-premise software since they can get new innovations to the field much more quickly. On-premise clients can’t afford the disruption of going through an upgrade process multiple times per year.
SaaS companies do have to be extraordinarily careful not to disrupt the customer’s environment due to software regressions, the breaking of customer customizations, or UI changes which require additional training and preparation by the customer. Software uptime becomes much more critical as any unplanned downtime potentially affecting thousands or millions of clients becomes much more visible. SaaS software must be architected to be much more resilient from failure and have a short time to recover from a failure (MTTR).
Software upgrades become more complex due to the requirement to upgrade the software without a service interruption, or at worst, during a short maintenance window. This precludes being able to perform lengthy operations that may occur during a software update such as a database restructuring. An advantage of the SaaS Cloud model is that the new release can be fully running on an independent server with the complete new release environment prior to moving any tenants. The process of moving the tenants to the new release on a new machine can happen more quickly in the SaaS environment than upgrading the software environment on the same machine to a new release (and associated supporting software which may also require upgrades) for on-premise software.
SaaS companies are more likely to adopt NoSQL data management software such as MongoDB since it does not rely on a fixed schema which is impractical to change during a short maintenance window (as well as potentially providing higher performance and lower cost data management capabilities).
Some SaaS companies such as NetSuite support two releases simultaneously for a number of weeks and allow their customers the ability to choose the time of transition to a new software release during the period of a few weeks, though most SaaS companies upgrade all of their clients simultaneously.
SaaS Requires High Availability and Redundancy
“Each system has to be able to succeed, no matter what, even all on its own. We’re designing each distributed system to expect and tolerate failure from other systems on which it depends.”
John Ciancutti,
VP Development Netflix
Uptime requirements are a key SLA which needs to be met through a fault tolerant architecture with comprehensive redundancy and fail-over strategies. IaaS platforms do not have the same reliability of large, expensive IT systems, so the resiliency must be a characteristic of the SaaS package. The SaaS architecture must ensure software failover (High Availability – HA) is well designed and the time to recover from data loss or corruption is minimal. Failures of the machine instance (a virtual computing resource running an operating environment), the network, the software, data availability, or of data integrity can occur. The software must be architected to anticipate and recover from failures in any of these areas without material impact to the client. Recovery from the failure to successfully access the data requires redundant data. This redundancy may be provided by IaaS or the database platform. For example, OpenStack Object Storage (code-named Swift) can provide three copies of the data ensuring high assurance of data availability. Data corruption may be the most difficult, and requires the ability to recover the data from a prior state known to be consistent.
SaaS Requires Development Security and Compliance Focus
SaaS providers must now be responsible for application security which was primarily the responsibility of the IT organizations for on-premise software. According to Gartner, the majority of security breaches happen at the application layer.
Compliance and audit issues become more complex with multiple tenants running in virtual environment in multiple (perhaps unknown) locations. Developers need to code for the most common sources of application errors such as Cross Site Scripting and SQL Injection which allows malware to attack data driven applications.
SaaS security must be part of the development process rather than reactively addressed when a security breach is detected. Since the majority of breaches are not detected, detection and mitigation is not a viable strategy. There are many security frameworks such as the Microsoft Security Development Lifecycle shown in the graphic below.
Microsoft Security Lifecycle
Developers of SaaS products need to become expert in building secure SaaS products. Best practices for SaaS security are described in detail in the upcoming post Best Practices for Security for SaaS Vendors – click here to receive the post when published.
SaaS Requires Management of Data Locality
Increasingly countries are passing laws restricting the movement and storage of data. On-premise applications were able to leave most of the issues around the location of the data to the customers. Many countries have strict laws regulating where data can be stored and moved beyond their national boundaries. This is both an issue from the developer’s perspective, and the “DevOps” team which is managing the operation of the SaaS software to be in compliance with these national regulations.
SaaS Requires Consideration for Data Governance
One of the most significant aspects of SaaS is that the SaaS vendor is now responsible for the client’s data rather than being managed by the IT organization. Sophisticated enterprises understand their data is a huge information assets that must be managed to extract maximum strategic value for the corporation — that data now physically resides on the SaaS vendor’s servers, but the enterprise still must have that data subject to its data governance policies. Beyond the data governance issues of Security and Data Locality discussed above, software developers must allow for the implementation of the IT organizations data governance policies. That includes the ability to make all the client information readily exportable so the data can be readily utilized with the enterprises’ other data assets, and to give the enterprise the security to know that they can move to another vendor without “data lock-in”. Other data governance policies including the management of data quality, data handling processes, and risk management of the data must be enabled by the SaaS vendor.
SaaS Requires better Testing
Most failures in multi-tenant SaaS systems impact all the tenants. Failures are more-widespread, more impactful and more public. Testing must ensure there is no interference or loss of security among tenants operating in the shared environment.
Netflix created a rogue program, the “Chaos Monkey” to randomly kill processes and ensure that there was no disruption. At FieldCentrix where we were using early wireless data messages we developed the “Nasty Protocol Module” which created network errors, dropped packets, and additional packet delays to ensure the software could handle all sorts of network errors. SaaS systems must be designed and tested to function in an environment where the infrastructure can and does fail, and the SaaS application must adapt.
SaaS Operations brings new Requirements to Software Development
Other software requirements unique to SaaS are the on-boarding process for new tenants and the billing for tenant use. While there are third party packages to assist in these requirements, they need to be included in the software architecture.
The SaaS company is now responsible for the operation of the software such as system monitoring including performance, fault detection, intrusion detection and remediation, security, and audit streams. These “DevOps” functions previously the responsibility for the customer’s IT organization are now the responsible of the SaaS company, and in some cases, even the SaaS company’s development organization. NetSuite has no separate DevOps organization, but its software development staff also runs the service. In all cases, the software development organization is now much more closely tied with Software Operations.
The SaaS software must be able to work with IaaS/PaaS capabilities for load balancing and automatic provisioning of additional resources based on demand. The SaaS company will be able to get significant help from the IaaS vendor, the PaaS provider (if there is one), and third party tools, but these capabilities need to be integrated with the SaaS software being developed. The SaaS vendor’s responsibility is to ensure their SaaS product fully implements required SaaS operational capabilities with the help of their partners.
SaaS Requires “Best Practices” in Software Development Methodologies
SaaS products iterate rapidly, frequently releasing significant new functionality keeping the SaaS product “fresher”. This requires a development organization with the methodologies to do frequent, high quality releases. This moves development organizations towards Agile development methodologies and away from ad-hoc or older “waterfall” development methodologies.
“Continuous Integration” (CI) methodologies are well suited for SaaS environments making frequent customer releases by ensuring the software is never far from a releasable state. There isn’t the time to “test-in” the quality over a more typical one to three year major software release cycle for on-premise software contrasted with the 3 month typical feature release cycles of SaaS companies.
SaaS Organizations must Invest in their Talent
SaaS organizations must ensure they are investing in building the SaaS skill set of their development team, and bring in resources as required to ensure the SaaS skill sets are present. Just as not every organization and programmer successfully moved from mainframes to minis, or minis to network computing, not everyone will be able to move using software development tools and practices required to successfully implement a SaaS strategy. It is most important that development leadership is committed to the SaaS enabling technology and provides the direction for its successful adoption.
SaaS Development is Different
SaaS products don’t literally require the end of Rich Internet Application frameworks, great User Experiences based on HTML5, published APIs, frequent software feature upgrades, support for third party software integrations, support for analytics, and support for mobile applications, but few successful SaaS companies build a product today without these attributes. There are many company benefits to moving to SaaS, it is crucial that the development organization has a plan to ensure their SaaS product is “world-class” — innovative, robust, extensible, scalable and integratable with a modern user experience that delights.
SaaS application should use these development best practices. They also need to meet the characteristics that make them suitable for deployment in the enterprise including, Security, Privacy, Data Governance, Interoperability, Performance, Availability and Regulatory Compliance as described in the Cloud Strategies post, Requirements for Building Enterprise SaaS Applications.
