Main image of article Developing Cloud-Based SaaS Web Applications
The demand for Web development skills needed to design, build and deploy Software as a Service applications should continue to increase over the next several years as more companies seek solutions tailored to the capabilities of the cloud. According to SaaS blogger Dave Key, designing software for SaaS is fundamentally different from designing software for the more traditional client/server model in terms of architecture, user interface design and the exposure and use of APIs. Key points to consider:
  • Design for Distributed Infrastructure and Platforms: While traditional client/server applications essentially run on just two computers, cloud services can, and often do, run on several different servers. Developers must be aware of and design for the potential lag time with various Web service APIs, database servers and application servers, as well as both synchronous and asynchronous processes within any given server. Your design must allow for bandwidth limitations and server load issues, and address issues around horizontal scaling.
  • Design for Device Independent User Interface: With the growth of BYOD, HTML 5 is emerging as a standard way of providing a rich user experience across a variety of devices. It’s designed around HTML, CSS, DOM and JavaScript, without the need for proprietary third party plugins like Adobe Flash. Using HTML5, it’s possible to design your app so that regardless of which device a user is operating on, you need to create only one core set of code.
  • Determine Your Use of Others’ APIs: One of the cloud’s attractive business features is the ability to share data between applications. Users only have to enter data once. So, for example, an inventory application could populate a point of sale application. While designing your application, deciding which services to use is both a business and technical decision. Three major technologies for exposing Web Service APIs are REST, SOAP and XML-RPC. SaaS developers will likely need to use some combination of them to connect with related applications.
  • Expose Your Services through APIs: Just as selecting APIs is both a business and technical decision, so is exposing them. From a business perspective, you must consider which of your functions or resources you wish to expose, and to whom. From a technical perspective, you must decide which methods (REST, SOAP, XML-RPC, etc.) you will use to expose your Web service. Documenting these APIs is crucial to the adoption of your services by other developers.
  • Design for Seamless Upgrades: SaaS is “always on,” and unlike desktop software, you can’t just run an upgrade program and reboot. Design your software in small, clearly defined, highly cohesive modules, with loose coupling and well-defined roles, interfaces and responsibilities. Then, ideally, your development team should be able to “simply” swap out one module for another.

Solid Software Engineering Principals

Because Web applications built for the cloud are a set of connected services and smaller programs running on several servers, it’s imperative that they be built from the beginning with solid software engineering principles in mind.
  • Cohesion: Whatever programming languages you use, your fundamental programming components should be small, have a clear purpose and well-defined inputs and outputs. In other words, they should be highly cohesive. If you can’t describe what the module, class or subroutine does in a sentence or two, you probably need to look at your design again.
  • Coupling: A component shouldn’t depend on the internal operations or results from other components. It shouldn’t care what processor or operating system provides the functionality it requests. It shouldn’t depend upon side effects of other components. Theoretically, in the cloud any given function call could be to a process running on a different server anywhere in the world.
  • Stable and Well Defined Interfaces: Once an interface is in use, it should not be removed. You can add to it, or supersede it for future functionality, but you shouldn’t remove it or alter the implementation in such a way that any code that depends on it can’t receive the information or functionality it requires.
  • Hidden Implementation Details: Because the interface is so important, components shouldn’t care about how other components do their job, only that the job is done.
  • Appropriate Application Design Patterns: Certain design patterns lend themselves very well to cloud computing, most notably the Factory Pattern and the Model/View/Controller (MVC) Pattern. The Factory Pattern allows you to expand and upgrade functionality, while the MVC Pattern allows you create an application that will run on a diverse set of user interface devices.

Security and Accountability

SaaS developers have an ethical (as well as legal) responsibility to steward the data managed by their services. Users and businesses must have a well-founded trust in the vast majority of SaaS applications or the entire SaaS model, along with all of its benefits will ultimately fail. On a closed LAN with a few users, network security is often sufficient. On the cloud, as demonstrated by recent high publicity security breaches, public access has inherent risks.  Every SaaS developer should be familiar with the Information Security CIA Triad:
  • Confidentiality: This means protecting a user’s privacy and a company’s sensitive information. Be sure your application doesn’t show information to a user that the user is not supposed to see. Be sure that your application does not “leak” sensitive data on the internet. One easy to implement policy to prevent leakage is to make sure that all http requests and responses are delivered over https.
  • Integrity: This means data isn’t accidently or maliciously changed. Who has the right to modify the data? How do you ensure that data isn’t accidently changed as an unintended consequence of a software defect? What are the backup and recovery procedures and processes for application data? How does the application interface with those processes? Who is allowed access to them? These are some of the major questions you must ask when developing your SaaS application.
  • Access: This means that authorized users can get to their application when they need to, and that unauthorized users can’t. Login screens look simple: They are “just” a username and password, and occasionally a third or fourth authenticating factor. However, if every SaaS application requires the user to login separately, they become frustrated quickly. Thus, users are moving toward, single sign on, or SSO. Common methods for inter-application authentication are OAuth,  OpenId and CAS.
As more software moves to the cloud, certain industries, most notably the healthcare and the financial services, require personal accountability data creation, access and modification. Therefore, many SaaS applications will need to be built with more logging than traditional applications, where access can be limited by workstation. Remember, however, that certain sensitive information, like credit card numbers, should not be included in the logs.