PROFESSIONAL SERVICES – BUSINESS EFFICIENCY APPS (SaaS)
HELPING ENTERPRISES BUILD AND/OR CONVERT LEGACY APPS TO ‘CLOUDWARE’
Optimal SaaS Architectural Traits
Bad software architecture is so much more apparent in SaaS products. On-premise Software products that run on dedicated servers or Virtual Machines (VMs) that support a hundred or so users may not scale well when run with dozens or hundreds of other tenants simultaneously. 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.
Many factors have to be considered when developing ‘Cloudware’ Apps. The decision about which IaaS Platform to use 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 complex issues that can hinder conversion.
The good news is that 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. Some companies share a common schema between their on-premise and their SaaS offerings. If the databases are shared with multiple tenants, a ‘tenant-id’ has to be added to the database in the SaaS implementation. A well designed 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 for example), “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. Furthermore, there is a legitimate concern among developers of the ‘lock-in’ to a specific PaaS API’s even more so than with IaaS API’s. Software developers (and organizations) must decide if they will adopt a PaaS platform or “roll their own” implementation on a lower level IaaS stack. There are also 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.
World Class SaaS software will eliminate the requirement for obsolete Rich Internet Application (RIA) frameworks including Flash, Adobe (Apache) Flex, JavaFX, and Windows Presentation Framework (WPF)/Silverlight. Particularly, there is no need for Java Browser Plugin with its frequent update requirements, significant security vulnerability risk, and the horrific Ask Toolbar ‘Crapware’ that many user Desktops inadvertently get infected with due to frequent 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 complicate issues for enterprise IT staff.
Fortunately, 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. 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 also moving away from their RIA support in favor of HTML5. Most modern browsers (such as Chrome, Firefox, and Internet Explorer) have moved to a model of automatically updating their browser, solving the problem of supporting old browser versions and ensuring that compliance with the HTML5 emerging standards occurs quickly.
It is also quite possible that SaaS applications require both a desktop and mobile version. While HTML5 is rapidly become a standard on desktop, its use on mobile platforms is situational based on the application requirements. The choice 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 SaaS architecture involves developing a fast, secure, and easy to use data services layer that is the foundation of a public API. SaaS ‘Cloudware’ should have should have APIs to allow development of additional capabilities by third party developers, integrate with other software packages especially analytics and Big Data applications, and provide services to mobile applications if needed. Unlike on-premise applications, in some cases SaaS 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.
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 (such as a ‘tenant-id’ as mentioned above). 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. 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 that public APIs must be thoughtfully architected to ensure they are extensible.
Beyond multi-tenancy, SaaS systems should be architected to be stateless applications where possible. Modern software systems expose their functionality throughRESTful 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, Rackspace’s Cloud Block Storage, or an Open-Source Object 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 are used for work-load distribution by the IaaS providers load balancer. This type of scalability only works with a stateless architecture where any request processing service can perform work for any client.
As stateless compute instances is dynamic – it comes and goes. The storage component in this case 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 un-needed 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.
Big data applications cannot ignore issues of data locality. Moving a petabyte of data over a public cloud to run Hadoop for instance 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 software / Cloudware should also be able to rapidly accommodate release of 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, developers can focus their efforts on producing new innovations by minimizing the resources spent on maintaining a large set of legacy releases. Effective developers of SaaS Applications spend more time on innovation and less time on software maintenance. This is a huge advantage over on-premise software development since new innovations can reach the field much more quickly.
On-premise clients certainly can’t afford the disruption of going through an upgrade process multiple times per year therefore SaaS developers 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.
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 may not have the same reliability of large, expensive IT systems, so the resiliency must be a characteristic of the SaaS Software design. 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, Open Stack 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.
One other area not to overlook is Software Security. 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 Group, 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 Microsoft Security Development Lifecycle shown in the graphic below.
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. 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.
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. It is advisable to create a rogue program by design to randomly kill processes and ensure that there was no disruption. Smart developers also create ‘rougeware’ for related 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.
Other software requirements unique to SaaS are the on-boarding process for new tenants and the billing for tenant if an organization desires. While there are third party packages to assist in these requirements, they need to be included in the software architecture.
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 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.
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 products that are friendly and easy to use. They require the 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. There are many benefits to moving to SaaS Cloudware, it is crucial that the development organization has a plan to ensure their SaaS product is “world-class” – innovative, robust, extensible, scalable and integrate able with a modern user experience that delights.
SaaS application developers 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.