Virtualization encompasses various computing technologies and can be achieved both at the hardware level and at the software level. In an enterprise, virtualization can enhance the ability of software services, especially SaaS applications. It’s also the most effective way for enterprises to reduce their IT costs. But put virtualization and SaaS together and you may have a winning combination.
What Is SaaS?
Software as a service (SaaS) is a software licensing model in which the software is licensed on a subscription basis and is hosted centrally by a vendor or a service provider. These distributed software applications are made available to customers over the Internet.
- Easy administration
- Easy updates and patch management
- Compatibility (all users will have the same version of the software)
- Global accessibility
SaaS is also considered part of cloud computing nomenclature along with:
- Infrastructure as a service (IaaS)
- Desktop as a service (DaaS)
- Back-end as a service (BaaS)
- Platform as a service (PaaS)
- Information technology management as a service (ITMaaS)
Virtualization and Software Delivery
The concept of virtualization has been rightly adopted and accepted in the software development community. It has the ability to provide faster development and test mechanisms by creating development and test environments rapidly.
VMware and VBox are the most widely used technology, and they enable multiple users to run on different operating systems, versions and instances. Most software development enterprises adopt the virtualization technique by first adopting the software virtualization mechanism and then gradually moving toward hardware virtualization.
Virtualization and SaaS
In spite of having so many advantages, SaaS has yet to get its due credit. There are many factors that are responsible for this. These include:
- Huge Start-Up Cost: The revenue invested in the setup is recovered over a period of years.
- It May Violate the Principles of Free Software: Software freedom activist Richard Stallman refers to SaaS as "service as a software substitute (SaaSS)," and considers it a violation of the principles of free software.
"With SaaS, the users do not have a copy of the executable file: it is on the server, where the users can’t see or touch it. Thus it is impossible for them to ascertain what it really does, and impossible to change it. SaaS inherently gives the server operator the power to change the software in use, or the users’ data being operated on," Stallman wrote on the GNU website.
A good example of SaaS over virtualization is Amazon Web Services (AWS). AWS offers a host of software and platforms. The software is installed on virtual hosts and can be scaled up or down as and when required.
If we focus beyond the infrastructure and start-up cost, once deployed, an SaaS application platform should only be concerned with reproducibility. Each and every instance of the SaaS-based application should be identical to each other. There should be minimal differences in order to maintain the consistent behavior of every application instance for each customer and for the support team. This is done so that they have a uniform base in order to troubleshoot any issue, if required. The support engineer would not like to discover a problem caused by a missing library module for a single customer instance. Similarly, neither would a customer like to know that there could be a problem in each application ordered because the SaaS-based company cannot reproduce the issue using the same steps for every order. The entire process should be automated for consistency and cost benefits.
It becomes important to understand the complex nature of deployment for today’s applications — be it the SaaS model or traditional model. Even the simplest Web application is no longer responsible for managing the underlying data storage layer. The standard practice is to have a database, for example, MySQL, Oracle, DB2 or SQL Server. Combining these with typical Web stacks such as Java, Ninja, Grails, Rails, etc., leads to a multi-tiered architecture demanding scalable deployment. For example, while setting up a Rails environment, we used MySQL.
The agile nature of applications, which allows for easy upgrades of the software via plugins, patches, macros and mashups, can easily be integrated into the SaaS model. An extension or a patch is developed for a smaller issue, most of the time a bug fix, which needs to be delivered as a patch on the exiting software. Usually a customer wouldn’t like to hear that a problem occurred due to a resource constraint or some other circumstances, or that it is created by another customer.
As per Wikipedia, separation of concerns is the premise to breaking down an application into distinct features, which minimizes functionality overlap. With virtualization in place, this concept can be applied to the infrastructure. Separation can be applied down to the per-application, per-customer, and/or per-cluster basis. While still using the hardware to its maximum capacity, it provides the ability to scale horizontally and vertically. This is beneficial for single-tenant applications that wish to enter the SaaS market. Instant multitenancy on the underlying hardware with near-zero code change can be achieved with ease.
There are two deployment models deployed on Contegix’s SaaS platform. The differentiating factor depends on how the application is developed:
- To support one single customer per deployment, or
- To support multiple customers on a single deployment
The other common deployment model is to provide a higher degree of separation. The underlying infrastructure applications are separated into virtual machines, each scaled at the respective required levels. Apart from the single-tenant model, this model allows scaling at not just the individual components in terms of virtual machine resources, but also the number of instances. This model serves very well for large instances or multiple customer applications.
Regardless of the deployment model, it is very important to separate the operating system and application installation from the application data. This leads to discussions on how upgrades are processed and handled. The operating system and application installation should take into consideration the amount of volatile data, which should be capable of being replaced at any time with a refreshed copy or new version.