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
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 or 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 New Choices to make
- There are new(er) languages and tools that may not be well supported by current IDEs (Integrated Development Environments) — Visual Studio isn’t quite ready for HTML5 (yet); Eclipse 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 for billing systems. 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; the tenant-id is irrelevant for on-premise offering. 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 Means HTML5
New products will dominantly employ HTML5 technology 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 discontinuous 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 HTML5 emerging standards happens quickly.
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 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 analytic 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 legacy releases. Additionally, there is only one production environment so there is no need to test and resolve compatibility problems with different versions of operating systems, databases, and networks.
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 more Security and Compliance
SaaS security must be more rigorous since access to the application is not controlled by a corporate firewall. Compliance and audit issues become more complex with multiple tenants running in a remote location. In some cases, such as with PCI compliance, the data locality becomes a mandatory requirement requiring software awareness and control of the location of the data.
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. 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 Methodology
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 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.