Originally, I pictured the difference between a typical datacenter app an the ideal SaaS app as a two-dimensional continuum, and that you could add more and more SaaS qualities to you app to make it more SaaSy.
But then I realized that it is not a linear continuum. Rather there are various different aspects or characteristics that a SaaS application exhibits, and your application might be strong in one area and week in others. Thus these diagrams are better at describing the differences in apps and the SaaS ideal.In the diagram, I used one spoke for each of the 5 NIST characteristics which are covered in the next section, and a 6th spoke that combines the other characteristics that I have observed. (Sorry, but 6 spokes already challenged my drawing ability, there was no way I was going beyond that!)For each spoke, the center of the hexagon means that the application does not exhibit that characteristic, while the outer edge of the means that the application fully exhibits that characteristic. A dot is placed on the line to identify the amount of that characteristic found in the app. Then lines is drawn between adjacent dots and the indie is filled in. The resulting polygon visual describes the capabilities of the application. A perfect SaaS application is of course a full-sized hexagon.
Issues:The typical process to enable a new employee to access an application is very manual. It involves middle-men, usually the manager and the help desk. Often the notification that the access has been granted goes back to the manager (who initiated the request), and the manager informs the employee.The process is fairly slow. It may take hours (or days) for the ticket to get processed and the employee granted access. May organizations perform this task before the employee is hired.What happens if you need to handle 100s or 1000s of requests per hour?Finally, this process assumes low volume, perhaps only a few requests per day. (Note the backlog that happens when graduates or summer interns are all hired within a few days of each other.)
For self-service, the user can request access to the application. Usually, the user browses to the application and clicks a Register button. This kicks off some automation which performs the necessary tasks to register the user with the application. The last step of that process is to send the user a “welcome” email telling the user how to access the application. At times, this email contains a confirmation link that the user must click on to finish the registration process.The benefits are that this process is fully automated, happens in a matter of minutes, and can handle a high volume of requests.One issue with this process is that if there are access restrictions to the application. For example, not everyone should be granted access to the payroll application. In such a case, the automation might require a manual approval step.
There are multiple ways that your application is accessed:Users can access it via a browserOther application can access it via web servicesOther applications can access it via other IPC mechanisms, such as direct sockets, remote EJB method calls, messaging, etc.
When the application is moved into the cloud, browser and web service access will still work because they use ports 80 and 443, both of which are usually open in the corporate firewall and in the cloud’s firewall. But access via other ports, such as the ones used by messaging, Enterprise Java Beans (EJBs), and other protocols will be blocked by the firewalls.Also, you will want to avoid unencrypted access. Thus use https only, not http, and encrypt the web services.
There are multiple ways that your application is accessed:Users can access it via a browserOther application can access it via web servicesOther applications can access it via other IPC mechanisms, such as direct sockets, remote EJB method calls, messaging, etc.
Once in the cloud, the application will be accessed by a number of different types of devices. And you will no control over what else the user might have on the device (anti-virus, apps, etc.). And many users will want to access the app using mobile devices such as smart phones and tablets.Ensuring that the browsers available on mobile devices work with your application is a good first step, but even better would be to have an app that loads onto the device that provides native access to your application.
If you offer your application services to multiple tenants, you will have to keep the data separated. Acme employees should not be able to se Apex data, and vice-versa.[click]But consider the added value if you provided a Business Intelligence service that worked on the combined data from all tenants. This would enable small and mid-size business to more effectively compete with larger businesses by making use of a larger pool of data for business analytics.
In the first model, each tenant gets their own VM running the application and their own database.
In the second model, each tenant gets their own VM(s) running the application, but they share a common database. Of course, the data still must be separated.
In the third model, the tenants share the VM(s) running the application, but they each have their own database.
In the fourth model, the tenants share the VM(s) running the application and their data is in a single database. The application must ensure that the data remains separated and there is no crossover, even if data from multiple tenant appear in a single table. Usually, the database schema includes a tenant identifier and all queries are structured to return only data related to the tenant.This is the most desired state because all of the resources are shared across all tenants, thus greatly reducing the cost to the application owner.
Animoto is the poster child for cloud delasticity. They developed an application that takes you photos and a music selection and automatically creates an interesting music video. Their service really took off when the added a Facebook application, especially when the Facebook app automatically created a video.Note that the application supports highly parallel processing – each music video request runs on its own.
How should you deploy your application into the cloud?You could choose an IaaS solution. This would be very similar to deploying your application in a VM within your data center. With IaaS, you get an VM running an OS, but in the cloud. The major difference is that the storage space assigned to the VM is very small and is intended to hold only configuration information, not application data. Cloud provides therefore provide other storage mechanism where your data can be held. This might require some changes to your application.On the other hand, if you go the PaaS route, you are looking a having to rewrite your application using one of the APIs/frameworks supported by the PaaS vendor. In some cases this might be easy (ex: you have a .Net app you want to move to Azure, or a Spring app you want to move to a cloud build on VMWare), or it migth be difficult.Another thing to consider with PaaS is that you are then locked into the vendor’s cloud, unless you can find another cloud that supports the same API/framework.There are efforts under way to create a common cloud API, but most of those APIs are for cloud and application management. Thus the API is useful for IaaS deployments, but does nothing regarding the framework differences in PaaS offerings.
Depending on who your users are, certain of the NIST characteristics will be of higher priority for your or your users. The chart given about is a rough estimate and of course your specific concerns might yield other priorities. But here are some examples:If deploying your app to a private cloud accessible only to your employees, self service is probably a low-importance item because on-boarding of employees is not handled that often. In other words, the user population is usually fairly stable. On the other hand, self-service becomes highly important if your users are the general plugin accessing your app in a public cloud.In general, measured service is of low important because you can always charge a flat fee. This way you don’t have to provide and sophisticated monitoring or measuring software, nor a portal for users to see their usage. Of course, if you want to charge per usage, the importance increases.Also, as you increase the scope of the users of your app, from your company’s employees, to employees in other companies (perhaps providing your app as a service to those companies), to the general public, the importance of each characteristic increases.
If you have a virtualized environment, you can probably fairly easily move the individual VMs in a cloud. Most cloud vendors will accept your VMs and run them.Alternately, if you have a virtual environment in your datacenter, and you want to convert to a private cloud, the cloud vendor might be able to place their cloud management solution into your datacenter, effectively bringing the cloud to your virtualized environment. We did this in the Unisys datacenter, replacing the existing virtual machine management infrastructure with the Unisys Secure Private Cloud management infrastructure.
Now that we have looked at the various characteristics of a SaaS application, what is the right blend of characteristics for your application? You don’t have to provide all of the characteristics, and you don’t have to provide the full characteristic. But as you decide which characteristics are important to your app (and to your customers), you will have identified the shape of your application. And perhaps you can initially meet the shape in the upper left and eventually move to the shape in the lower right.
