Cloud Computing Models: SaaS versus PaaS

1 SaaS vs. SaaP

1.1 History

Traditional SaaP developers was focusing on how to access Operating Systems (OS) APIs and how to handle those APIs in order to utilzie them inside a software via the development framework in use. After a while, the question of application portability came under discussion in early 90’s due to numerous

operating system segmenting the OS market. In 1995, James Gosling introduced the platform-independent Java and became the first scientist to tackle portability issues. Java programms were running on a virtual machine enabling applications to be ported in all Operating Systems. After that more

and more frameworks started to follow the path of Java to enable platform independency such as .NET framework by Microsoft, different implementation of Python and etc.

With Internet gaining huge popularity and profitability in the Dot-Com Bubble era during 1995-2000, IT industry started to invest remarkably in Web Infrastructure. However there was no disucussion about SaaS yet. A similar concept called Utility Computing was already introduced by John McCarthy in MIT in 1981 as ”an imagination of nearly infinite amount of computational resource”, however the SaaS dialect evolved after the release of Gmail, which was a successful implementation of SaaS. What was unique  about Gmail was the ability for the user to extend its API and utilize it as an email service inside his own applications. After Gmail gained popularity, companies started to invest more and more in SaaS engineering. In 2003, Amazon with its EC2 service truely started the Cloud industry. Not only Amazon  offered Infrastructure but also platforms to be used as a service. This initialized the cloud dialect after their service models were introduced, i.e. Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS). Recently, Microsoft has launched its Office 365 SaaS project, in order to allow users to pay for their use of software, instead of paying the whole license at the purchase time. This had made software development process to evolve in a complete different path than it used to be.

1.2 Features

While developing SaaP, vendor has an approximately large set of concerns in most cases. First is the application requirement regarding operating environment, hardware and software dependencies. Second is the application portability issue. Each framework has its own boundaries while dealing with system APIs and therefore either team members should be assigned to test the application against different operating environments, and re-write the software components or limit the user to specific functionalities in case of incompatibility. As a result, due to tight-coupled software and hardware package, changes in software are costly and are avoided in case of appearance of bugs that have low-severity level of destruction toward the system or customer dissatisfaction. Last concern of vendor is the customer’s data. Whether sensitive or not, customer’s data could be damaged by misuse or fatal bugs that SaaP-based applications could create.

With players involving more and more in the cloud market, it is apparent now that SaaS experience is completely different experience than it was in SaaP, either reviewed from a customer or a developer’s point of view. Some of the highlights of SaaS unique features can be listed as follows:

• There is no need for installation of any software rather than a standard Web Browser.

• Customers are working with the latest release of software. They may not even know this fact themselves, therefore they cannot choose not to.

• Customers do no longer have to worry about backing up their data as it is now the responsibility of SaaS providers to operate data back-up processes.

• SaaS software runs on a uniform and tightly coupled hardware, chosen by developer and therefore compatibility is no longer an issue. It should be remembered that no longer binaries are distributed amongst operating systems as it did in SaaP.

• Developers can upgrade the software and underlying hardware as frequent as they need to, without changing the API of the application.