When deciding to deploy your Software as a Service (SaaS) cloud solution you need to decide if you will be a provider of SaaS services, which method to use, and/or if you will be an end user to an existing solution provided by another vendor. In this white paper will first examine your options as a SaaS provider, which include Platform as a Service (PaaS) and Infrastructure as a Service (IaaS).
With deploying SaaS, your customers don't choose any of the server, storage, or networking specifics, and they don't choose an operating system, or even a language to develop new tools in. Rather, they get an application, such as email, a customer relationship management (CRM) application, or a word processor. They can't choose anything other than the settings allowed by the application, possibly including things like the amount of storage desired, default font, or things of an application nature.
You, as the provider, however, will need to consider all these issues, and many more, in developing your application. In order to provide a simple experience for your customers you will need to think about providing all the tools end users will need to use your application. This is a lot of work — probably more so than deploying an existing application on IaaS or PaaS.
In this white paper, you will also receive some guidance around being a SaaS consumer for various aspects of your IT infrastructure needs. We'll talk about the reasons why organizations use various SaaS solutions. We'll also give some examples of common SaaS solutions to get you started, as we have with the IaaS and PaaS white papers in this series. Before we get started, though, let's briefly review SaaS cloud computing at a high level to set the stage for our discussions.
When you become a SaaS consumer you'll expect the same level of ease of use, self-service support, etc., that you will want to provide your own customers. Keep in mind that it's possible that you may be both a provider and a consumer, such as providing an email platform and using a SaaS provider for your CRM needs. This is the most familiar scenario to most people today, even if they don't know these applications are SaaS applications. Things like Gmail and MapQuest are ubiquitous today.
Note that SaaS applications can be accessed via a browser where the great majority of the processing is done on the cloud provider's infrastructure, or via an application, such as one that runs on Android or iOS, or even a Windows or PC application, where the processing is shared between the cloud provider's infrastructure and the consumer's device. In either case, data is typically stored on, or at least synchronized with, the cloud provider's infrastructure.
SaaS is at the top of the pyramid of aaS choices, where the customer gets to make very few choices beyond the application settings such as font, text and background color, and content to cache locally as previously mentioned. Be sure to read the terms and conditions and service level agreements (SLAs) provided by the cloud provider to ensure that your needs are met, especially with regard to any backups, uptime guarantees, etc.
The advantage of SaaS from a consumer perspective is that you don't need to worry about any of those decisions — you just use the application and let the provider handle all the details. The downside is that you have no control over most of the configuration, performance, or reliability of your application. You'll need to trust (hopefully, after carefully reviewing the SLA) that your provider has all those issues covered. You'll also need to consider how to get all of your corporate data from the existing application (if any) into the new SaaS application, and more importantly, how it can be pulled back out of the provider's system if the provider does not live up to their promises and/or they go out of business. Remember, you're betting the success of your business and all of your corporate intellectual property on the provider and its security controls, backups, etc., so choose carefully.
In this model, all the underlying infrastructure may be shared across companies, with very little, if any, control over whom the infrastructure is being shared with. Your intellectual property (IP) may exist next to a competitor's, and you are trusting the provider to keep both sets of IP segregated. Now, let's get started looking at the issues and considerations around becoming a SaaS provider yourself.
When deciding to deploy your SaaS solutions on either an IaaS or PaaS cloud, there are additional factors you need to consider.
Choose how your customers will access your application. This is perhaps the most important factor you'll need to consider.
You may choose to deploy it as an application instead. In that case, you'll need to consider how your target audience will use the application.
Maybe your application will be phone or tablet based instead. Again, you'll have choices to make from a platform perspective. Will your app run on iOS? Windows? Android? Maybe your application will be available on all of the above mobile, desktop, and web-based platforms. The more you support, the broader the base of customers you'll reach, but the greater the complexity in creating and maintain them all and the more staff will be required to make it appear seamless.
Determine how to back up your customers' data. It is virtually guaranteed that your customers will assume that you are protecting their data. You would be very upset if your Gmail or Hotmail emails were lost or your OneDrive account had files lost. You will need to devise a backup strategy.
Devise a high-availability strategy to handle any outages your provider may experience as well as any outages your own platform may run into. You expect 24/7 access to your data and so will your customers. They won't care that an Internet cable was cut or an earthquake occurred. Some of this may be handled by deploying applications that run locally and then synchronizing the data with your infrastructure, allowing offline access.
Consider the performance of your platform. Most people will be used to experiencing whatever your app does locally and will expect a similar level of performance from you. Remember, it's not just your app and what it needs to do from a computing-and-storage perspective, but network latency end-to-end. In other words, from the customer to your app and back. You will need to tune and optimize your app locally (i.e., in the data centers you choose to deploy your application) as well as consider where to deploy it.
In general, the closer the proximity to your users, the lower the latency and the better the experience. This may mean that you need to deploy your app in multiple locations around the globe and leverage global load balancers to direct your customers to the closest site. But in doing so, remember any data sovereignty laws, privacy rules, etc., and consider how that impacts your design in this regard, as well as the previous two issues we described (backup and service outages). Determining how to synchronize your data across data centers if you deploy your application infrastructure to more than one is key. One other thing to consider again is the use of local applications (mobile and/or desktop based) to reduce the dependency of your infrastructure always being available at a very low latency.
Lastly, remember that security is critical. If people don't feel that you are protecting their data, Intellectual Property, privacy, etc., you are unlikely to get and keep many customers. You will need to consider the security of data at rest (on your storage platform) as well as in transit (crossing the network, both internally within your app as well as externally between your customer and your app). This extends to any data that is stored on the end user's device (if any). You may have little to no control over that, or it may be managed by others, but you'll need to consider those implications from the start.
There are a few unique consideration to PaaS cloud solutions that you'll need to consider as well. Here are a few:
Consider the PaaS components you'll need to implement your solution, including not just the platform itself, but any storage, database, authentication, etc., services that your solution will require. You'll need to determine how to get the components to work together as well, especially if they come from different vendors. Remember that if this data crosses the Internet, you'll need to be aware of any security implications as well as any bandwidth charges imposed by any/all of the vendors involved. All else being equal, you may wish to stick with as few vendors as possible (ideally just one) to minimize these complications.
As with PaaS, there are some factors unique to IaaS that you'll need to consider as well. You can refer to the IaaS cloud white paper, but a few factors are highlighted below:
Once you have carefully planned out how you will deploy your application, the next consideration is whether or not to deploy the entire solution yourself or whether you leverage other PaaS options to provide some of the ancillary infrastructure such as authentication or backup. One is not necessarily better or worse than the other, but you will need to consider all the necessary components, how each one scales, and the licensing implications as your application scales. However, as with PaaS, keep in mind security implications, bandwidth charges imposed, and the number of vendors involved. Some IaaS vendors also have PaaS offerings such as Microsoft or IBM, while others are primarily focused on IaaS only, such as VMware.
Let's switch gears from being a SaaS provider to being a SaaS consumer. In the remainder of this white paper, we'll look at the issues around consuming various components of your IT needs by third parties. We'll look at use cases and some common SaaS offerings a little later in this document. The advantages of using SaaS applications in general include the following:
On the other hand, disadvantages include:
SaaS applications come in almost every shape and size imaginable. While not endorsing any particular application or group of applications, here are some to get you started (sorted by category):
Office Applications:
Email:
CRM:
Accounting:
Expense Management:
Project Management:
Web Conferencing:
Video Conferencing:
As we've seen with the other cloud options, there are many considerations that should be taken into account when deciding on whether to provide SaaS to others or to become a consumer. In fact, for some organizations, you may be both a provider of SaaS applications (CRM, for example) and a consumer (enterprise resource planning [ERP], project management, or accounting, for example). Careful consideration of the issues described herein will become key in having a successful outcome by making you a better provider or consumer.
John Hales is a VMware, SDN, and SoftLayer instructor at Global Knowledge. He is a lead instructor for the SoftLayer offerings worldwide. John is also the author of many books, from involved technical books from Sybex to exam preparation books, many quick reference guides from BarCharts, to custom courseware for individual customers. John has various certifications, including VMware VCA-DCV, VCA-DT, VCA-Cloud, VCP, VCP-DT, VCAPDCA, VCI, and VCI Level 2; the Microsoft MCSE, MCDBA, MOUS, and MCT; the EMC EMCSA (EMC Storage Administrator); and CompTIA A+, Network+, and CTT+. John lives with his wife and children in Sunrise, Florida.