Throughout this series of articles, we have looked at the architectural considerations and solution components that are necessary for delivering software as a service (SaaS). We have seen that upfront design is critical when building software that can be successfully used by customers with unique needs. A full-featured cloud service provider like Tier 3 offers many of the infrastructure automation and management services that makes it possible to efficiently deliver such software at scale. In this final article, we take a look at the choices that a SaaS provider needs to consider when deciding upon a support strategy for their customers.
One overarching consideration that any SaaS provider has to make is whether they plan on providing consumer-oriented, personalized service, or something with a more mass market flavor. Each approach has merit but would result in different implementations of four suggestions below.
Standardize wherever possible
One of the only ways that any software provider, SaaS or otherwise, can sell at scale is to standardize their offering and avoid per-customer customization. While everyone loves the idea of “I want it my way”, that concept quickly falls apart when the software provider is maintaining unique code bases, support instructions, and pricing.
The most successful SaaS providers focus on repeatability and avoiding one-off solutions for customers. The goal is to keep support costs as low as possible, and be able to scale the business without scaling the support staff. Providers should consider implementing a common pricing model consisting of only a handful of variations, and build the SaaS software to support user-driven customizations that don’t impact the underlying software.
Interactions with the cloud infrastructure provider should also be standardized and consistent. In the scenario used for this article series, we looked at provisioning unique server clusters for each customer. That deployment model will only work if the cloud infrastructure provider let users provision, scale, secure, update and monitor these environments in a uniform way. Imaging trying to maintain hundreds of servers clusters where each one has its own security settings and performance metrics! Providers like Tier 3 let customers define such settings at a global level and have them cascade down to each collection of servers. Likewise, updating software across a massive collection of servers can be daunting unless the cloud provider supports automated, reliable software installations that can be run on a schedule, or on demand.
Prepare the support team
In order to successfully manage a SaaS platform, one needs an efficient support staff that has a significantly higher server-to-administrator ratio than in traditional data centers. One survey shows that a single administrator can only manage 10 physical machines whereas hardware virtualization changes that ratio to 1:500+. Cloud infrastructure providers report an even higher ratio than that. What’s important to understand is that SaaS providers should be able to operate in a lean fashion, but only if the SaaS offering is one-size-fits-all (see above) and the team is well prepared.
If the SaaS software is running on top of a cloud infrastructure provider like Tier 3, then the support staff must not only be trained in the SaaS software, but also the management of the cloud infrastructure. This means either getting training documents directly from the cloud infrastructure provider, or more likely, preparing training material that is specific to the software provider’s staff and needs. For instance, the SaaS support staff that uses the Tier 3 cloud may not need extensive training on our PaaS Web Fabric offering if they are only leveraging infrastructure services. Likewise, if the support staff will never configure unique network segments for their customers, then the platform training can skip over that topic. Some Tier 3 customers build formal training documentation for their support staff, and yet others use more informal wiki-style repositories for FAQ and scenario walkthroughs.
A strong governance model is also key to a well-supported SaaS application. Documented procedures should exist for securing cloud servers, adding new support team members to the environment, scheduling maintenance activities, responding to performance problems, and making any changes that impact the availability or functionality of the entire platform. While not an exciting topic, governance plays a key role in SaaS platforms as all customers are sharing one environment and failing to follow procedures can result in a massive issue that impacts an entire user base.
Supporting a SaaS platform can be a 24x7 endeavor that requires additional staff, new training and a well thought out governance plan. However, the payoff can be enormous as a well-prepared support team can operate at a low cost and with high efficiency.
Understand that outages happen
One of the biggest misconceptions about cloud computing is that any application can be deployed to the cloud and it will instantly work at cloud scale and with 100% uptime. The reality is much different. A poorly architected application in an organization’s own data center will still be a poorly architected application in the cloud. While we can definitely build and deploy software in a highly available fashion, it is critical that those selling SaaS software honestly prepare their customers for the inevitable outages.
Tier 3’s own Jared Wray has written extensively on the topic of highly available cloud systems and how to partner with a cloud infrastructure provider to maximize the uptime of an application. Applications can be “built to fail” and gracefully recover from unexpected errors, but this can be both difficult and expensive. Some of the best architected web properties in the world have experienced downtime when their underlying infrastructure provider had hiccups. Some of these web sites have disaster recovery locations set up in geographically dispersed areas and use sophisticated synchronization techniques to avoid data loss, but this is an expensive undertaking that other software providers knowingly do not do. Some software vendors accept that downtime is acceptable compared to the cost of building a 100% available system.
SaaS providers must make a conscious decision about how much uptime they will pay for. If they willingly build a solution that is susceptible to hardware or software failures, that’s ok, but it should be open discussed and represented in the service level agreement (SLA) offered to customers.
One lesson that cloud infrastructure providers have learned is that customers cannot tolerate silence in the face of an outage. At the same time, it is clear that customers laud their providers when issues are promptly communicated and explained. This is part of a broader communication strategy that defines how a software provider interacts with their customers.
Depending on whether a more personalized approach is taken or not, communication can take many forms. For large SaaS environments with hundreds or thousands of customers, it makes sense to set up customer forums where questions and feedback can be collected at a wide scale. For a smaller customer base, one could choose to have dedicated account managers who have personal interactions with each customer. Many organizations also use public-facing communication mechanisms like Twitter, status (uptime) dashboards and blogs to share information in a timely fashion.
What should be communicated to customers? Some items are obvious, such as outages or billing changes. However, customers also need to know a general release schedule so that they can plan around it. Many multi-tenant SaaS platforms have every customer on a single version of the software. This means that everyone gets the update at one time, whether they are ready or not. By sharing a release schedule that provides ample lead time for customers to digest the upcoming changes, the software provider will receive fewer panicked support calls!
While it is entirely possible to deliver fantastic software with a non-existent communication plan, we see that the software companies that actively engage their customers form long-term, loyal relationships that can survive the occasional outage or misstep.
We hope that you have enjoyed this series of articles on how to “SaaS your app.” Much more goes into it than just taking an existing software package and pushing it out to a few cloud servers. We’ve seen the importance of architecting, automating, managing and supporting your software in way that makes it both efficient and profitable. Tier 3 has extensive experience in this arena and would love to partner with you when the time comes to offer software at cloud scale.
So far, we have reviewed many considerations for designing, hosting and managing a SaaS application on a cloud platform. One of the hallmarks of cloud computing is the notion of “self service”, and for SaaS providers, it’s the only way that they can efficiently scale to hundreds or thousands of customers. In this article, we will look at how to use the Tier 3 web API to create a self-service sign up and management portal that lets SaaS customers administer their applications without requiring help from the software provider.
We have been working through a scenario with a fictitious SaaS application that acts as a public face for candidates running for elected office. The application’s developer chose to deploy unique server clusters for each customer in order to isolate their sensitive donor and donation data. The management database, which holds account details and application configuration data, was shared.
In previous articles, we walked through the steps of creating a blueprint for the server clusters, and now need a way to automatically provision these clusters and enable a self-service management experience.
Adding New Customers
The first thing that our developer provided was the ability to add new SaaS customers. For this example, the SaaS developer chose to use ASP.NET and C# for the website administration portal. ASP.NET provides a useful Membership Provider model for creating and storing user credentials, thus saving the developer from creating their own repository and tools. The SQL Server Membership Provider enabled secure credential storage. After the required schema was added to a database, we had the necessary tables available.
The required Membership Provider settings were applied to the ASP.NET administration portal, and we used the rich CreateUserWizard control to collect sign up data.
The result was a simple three-step process for gathering key data from the new customer.
After each new customer completed the wizard, the web application performed four discrete tasks:
1. Called the Tier 3 web API to create a new Group for this customer. Recall that Groups give us an easy way to organize and manage each customer by providing unique permissions, performance monitors, scale policies and much more. This group served as the container for all of the servers used by this customer.
2. Created an Account Details database record that had the user name and billing details. The customer was asked for billing information during the account creation process and those details were stored in a shared database that the SaaS provider could use to generate invoices.
3. Created a Website Configuration database record that drove the website’s look-and-feel. One of the key aspects of SaaS software is the ability to customize and re-skin the appearance to fit the customer’s needs. This text and color scheme of the website is driven by this database record.
4. Called the Tier 3 web API to deploy the application blueprint. Recall that previously we crafted a blueprint that defined an environment consisting of two web servers and a database server. When this API is called, the Tier 3 engine went to work provisioning that environment for the customer.
About securely calling the API
Note that before an application can successfully call the Tier 3 API, it’s necessary to first create an API user for the account. This set of credentials is used to authenticate the user of the service. In this case, an API user was created within the Control Portal.
Calls to the Tier 3 API are secured with a token (cookie) acquired by passing the API credentials to the Logon operation. This process is straightforward and ensures that API calls are both secured in transit (using SSL) and only being called by authorized users who have a valid security token.
Once that provisioning process finished, there were a number of new resources in the environment. First, there was a new Group visible from the Tier 3 Control Portal.
Next, there was a new record for this user in the Account Details database table.
Additionally, the Website Configuration database table had a new record with some placeholder values (e.g. “banner color”) that would later be changed by the customer.
Finally, we saw that the blueprint had executed and three new servers were added to the Group.
Once the servers were online and configured, we viewed the website and saw both the placeholder text and default color scheme.
Build a Summary Dashboard
With the environment provisioned, the next step was to give the SaaS customer the ability to see their application at-a-glance. The Tier 3 web API gives developers full access to a wide range of resources like servers, groups, blueprints, networks and more. Our SaaS developer wanted to build a dashboard that showed the SaaS customer which resources were used by their application.
After calling the Tier 3 web API to get the unique identifier of the Group (as all we had up until this point was the friendly name of the Group), the application retrieved all of the Group’s servers by using the Get Servers API operation.
The API returned entries for each server and details about their allocation of RAM, CPU and storage. In addition to showing details about the environment, the developer also added a button that would reboot all servers in the environment if the need arose.
After the page was styled and formatted, we saw all the details about the servers in this customer’s cluster.
See and Change Application Configurations
As mentioned earlier, any good SaaS application gives the user the opportunity to rebrand the site without changing the underlying software. This particular application used a database to store its look-and-feel settings and this administration portal gave its users a way to view and update those settings.
The developer added a website page that allowed users to change the text, images and color scheme used by the site.
Upon saving the configuration settings, the user could instantly see changes reflected in the live application.
It takes a concerted effort to build a metadata-driven website that can easily be changed without recompiling code. For software developers looking to build SaaS-friendly applications, this upfront design effort will pay significant dividends down the road and make system support much simpler!
Manually Scale Environment Up
While one of the key benefits of SaaS solutions is abstraction away from infrastructure, at times it can prove useful to give customers the opportunity to alter their application’s environment. In a previous article, we looked at how the Tier 3 platform provides a series of administration tools for manually or automatically scaling a group/server footprint. Consider the scenario where the SaaS customer anticipates an influx of website visitors due to a marketing campaign or televised debate. While they could rely on automation in the underlying infrastructure to protect them against such a surge in traffic, the SaaS developer chose to give the customers the ability to proactively change the size of their environment.
First, the developer used the Tier 3 web API to retrieve the details of each server in the Group.
Then, code was added to detect changes in the server configurations and send those changes to the Configure Server API operation.
Now, the SaaS user could use the portal to modify capacity, such as the memory allocation of the web servers.
The call to the Tier 3 web API launched a blueprint that updated the memory configuration for the web server. Within a matter of moments, the server had more resources allocated.
This updated allocation was visible from the custom administration portal.
While it may not always make sense to reveal underlying infrastructure aspects to SaaS customers, there are very real use cases where this information should be surfaced and editable. However, one could choose to provide categories of service instead of asking users to choose individual server configurations. For instance, this SaaS developer could offer environments for “local campaigns”, “state-wide campaigns” and “national campaigns” where each category had a particular resource profile based on the usage expectations of the campaign type.
Using this technique, the customer can still scale their system, but they aren’t forced to size individual machines. Similarly, the SaaS sign-up experience could be enhanced with a series of questions that help the system decide which plan to offer the customer. Either way, Tier 3 offers an expansive web API that gives developers plenty of choices when decided what capabilities they wish to expose to their end users.
In this article we analyzed some of the key parts of building a self-service component to a SaaS application. Software developers need to consider how their customers may want to alter the appearance or behavior of their application. This may cover superficial aspects like color schemes, or more complex dimensions like security settings, data object definitions, workflow tasks, and business logic. Either way, building SaaS solutions requires significant forethought and engineering and partnering with a cloud thought leader like Tier 3 can help ensure that the underlying platform provides everything you need.
So far in this series of articles, we’ve looked at how a software provider can deliver their product in a Software-as-a-Service (SaaS) manner using the Tier 3 Enterprise Cloud Platform. While provisioning and deployment of solutions is an exciting topic, the majority of an application’s life will be spent in maintenance mode. In this article, we will look at how a Tier 3 cloud user can efficiently manage and monitor their SaaS environment.
Defining Customer Capacity Thresholds
You may recall from the last article that our fictitious SaaS application is targeted at candidates for political office. In this scenario, the application developer chose to create individual pods of servers for each customer instead of co-locating the customers on the same application or database server.
Each of the pods of servers go into a Tier 3 Group which creates a logical segmentation of servers. Each Group can have its own permissions, maintenance schedule, performance monitors and much more. From the Tier 3 Control Portal, we can browse the individual server groups and have at-a-glance visibility into the resources being used by each server.
In an upcoming article we will look at how to allow SaaS customers to increase server resources to handle greater loads, but what if the SaaS provider wanted to limit how much capacity each customer could consume? Each Group has settings that control its capacity thresholds and software providers, or customers, can use these settings to ensure that they don’t provision more resources than they are willing to pay for. The Group Capacity settings, which are inherited from the parent group by default, define the maximum CPU, memory and storage for a given group.
Depending on whether the SaaS provider is passing resource utilization costs directly to their customers (or simply charging a single recurring fee for the software), it can be very useful to put these governor limits in place to prevent consumption from growing too rapidly.
Monitoring Performance and Scaling Environments
While we hope to initially provision servers that can withstand whatever load we send its way, there often comes a time to reassess the resources that have been assigned to the application. The Tier 3 Enterprise Cloud Platform offers a range of performance monitors that paint a picture of a server’s health. Monitors can be set at both the Group and individual server level. Let us consider our scenario and assume that our web servers should not exceed 90% CPU for a long duration. From the Control Portal, our SaaS administrator can view the monitors for an individual web server and override the inherited settings that come from the group.
The administrator can then change the alert threshold to 90%, and, define which user in the account will receive the email notification when the threshold is exceeded for an extended duration. While alert messages are used for proactive notification, an administrator can also view reports that track usage compared to monitor thresholds. The Reports view is available at both the Group and server level. Here, users get a visual representation of their server performance and can observe historical activity for up to one year.
The SaaS administrator observes a sustained spike in usage and needs to expand the application footprint, they have multiple options. First, there are two manual ways to increase capacity. An administrator has the option of scaling horizontally by adding new servers to the Group. This can be done via the typical server provisioning process or through an existing blueprint. The other manual option involves scaling the server vertically by expanding the server’s available resources. For some operating systems, like Windows Server 2008 R2, this capacity adjustment will occur without taking the server offline.
Both of these manual options are available to administrators and can relieve the pressure from an overtaxed application. However, if we assume that this SaaS application becomes extremely popular, our SaaS administrator will become overtaxed in their attempt to monitor and scale each customer’s environment! That sort of model would be unsustainable. Fortunately, Tier 3 will soon be releasing an intelligent Auto Scale capability which can do both real-time and predictive scaling of the servers in a Group. The real-time scaling occurs when usage load exceeds a particular threshold for a sustained period. More capacity is automatically added to the server and the customer is notified of this change. The predictive scaling uses historical trends to foresee potential problems and scale the server before an overload actually occurs. In all cases, the SaaS administrator has full control over how scaling will occur and can prevent runaway provisioning by setting the maximum (and minimum) number of servers that a group can have.
How does it work? In the case of group or application scaling, the administrator sets preferences for when scaling occurs (i.e. the “aggression level”) and the preferred method (i.e. “horizontal” or “vertical”). For horizontal scaling, the administrator provides a template that defines the type of server to add to the cluster.
Individual servers can also have their own Auto Scale policies that define resource ranges and approved maintenance windows for applying the new resource allocations.
If a SaaS provider decides to use a limited multi-tenancy model and dedicate environments to each customer, then they absolutely need a way to create a self-healing environment that can ebb and flow automatically based on utilization.
Taking Server Snapshots
Server snapshots provide a way to capture the current state (i.e. memory, disk content) of a server and have it available for restoration in the case of failed upgrades or corrupted configurations. Tier 3 offers this capability for application owners who want a way to perform configuration changes with the confidence that they can quickly revert back to a particular point in time if necessary. To be sure, snapshots are NOT a substitute for a backup and shouldn’t be used as such. Rather, they are best for short term rollback of changes to a server.
If our SaaS provider decides to try upgrading a server to the latest version of the web application, they could choose to first snapshot the web server in case the update fails. Snapshots may be applied at the individual server level.
However, it is also useful to be able to perform this action in bulk from the Group’s perspective.
Once a snapshot is created and saved, an administrator can restore to a snapshot via the Tier 3 API or by opening a ticket with our expert Network Operations Center (NOC). These capabilities help application owners safely and consistently apply changes to their environments without risk of causing irreversible damage.
If you would like to understand more about how snapshots work, please take a look at this overview from VMware.
Performing Data Backups
One of the biggest fears of an application owner is experiencing a major crash and realizing that critical data is lost and unrecoverable. Given that in our scenario, each customer has their own environment, the need for a consistent and comprehensive backup strategy is even more imperative.
All servers in the Tier 3 Enterprise Cloud platform automatically undergo a nightly backup procedure. These backups contain the full state and data of the server. Depending on what service a customer has requested, there can be a rolling fourteen day backup. All of this ensures that customers can rest easy knowing that they only face a minimal data loss in the case of a catastrophic event.
For many modern web applications, the applications servers themselves don’t maintain much (any?) state and can be added and taken offline with little impact. The real heart of most applications is the data repository. If a Tier 3 customer wants to do database-level backups, they could choose to manually log into the database server and backup the critical data. However, that is extremely time consuming and inefficient. Customers can have custom database backups configured for them by the Tier 3 NOC, or, create instantiate backups through the robust Tier 3 web API.
While operational support is not the most thrilling aspect of the application lifecycle, it is most certainly the longest! If your cloud hosting provider cannot provide a strong set of automated management controls, then administration of a SaaS application will be an overwhelming and never-ending set of tasks. The Tier 3 cloud includes an ever-growing set of self-service mechanisms for governing, monitoring, scaling and providing durability for your applications. Next up, we will take a look at how to use the Tier 3 API to build an application management application for SaaS customers.
In the first article of this series, we discussed the major things to consider when looking to create a software-as-a-service version hosted on a cloud platform. One major factor called out in that article was the need for a solid hosting environment. In this article, we will look at how to use the Tier 3 Enterprise Cloud Platform to package a web application for SaaS provisioning.
To provide some real-life applicability to this article series, let us work with a fictitious, but realistic, use case. Elections to government posts are a regular part of most societies and it’s becoming increasingly critical for candidates to have a robust web presence. Let’s imagine that a web developer successfully built a web site for a local candidate and has realized that this site template could be reused by multiple candidates. Recall from the previous article that an application can be multi-tenant (and thus easier to maintain for multiple customers) in multiple ways:
- All customers could reside on the same instance of the web application and database.
- Customers can share a web application but maintain unique databases.
- Each customer gets their own web application and database instance and MAY share underlying infrastructure.
There are benefits and risks of each choice, but let’s assume that our web developer chooses option #3 because candidates will be hesitant to intermingle their donor list with others in the same database, and each candidate may want to perform some unique customizations that wouldn’t be shared by all web application users. Option #3 only works at scale if your hosting provider has significant automation capabilities that can handle actions like OS patching, system upgrades, and server scale-out with limited manual intervention. Fortunately, Tier 3 offers substantial environment automation capabilities that make management of distinct “per customer” environments entirely manageable.
Today, this web developer has a simple two tier application.
What he hoped to have is the ability to bundle up this configuration, and deploy one of these “pods” for each customer. Then, he wanted to add a single provisioning and management interface that could be shared by all the customers. The Tier 3 Enterprise Cloud Platform allows servers to be managed in “groups”, so in this case, each customer (candidate) will be provisioned into their own group. This makes billing, scale thresholds, and configuration much more personalized.
Creating Application Templates
We’re going to help this web developer out by showing the steps necessary to get his application deployed in a SaaS-y way. The first activity to perform involved creating templates of each “pod” of servers. A basic pod consists of two web servers (for a load balancing) and a single database server. Using Tier 3’s “template” technology, we can take a server and turn it into a reusable image. So first off, we needed to create a template out of the web server that had the web application installed. However, note that the database server will NOT be converted to a template as we want a fresh SQL Server installation for each new pod. Unless a specific sysprep occurs on a SQL Server machine, there can be issues (e.g. server name collisions) when instantiating a SQL Server-based virtual machine snapshot. As Tier 3 doesn’t yet offer a SQL Server-specific sysprep, we’ll rely on a bit of automation and a bit of manual intervention to get each pod deployed.
First off, we built a web server that could be templatized. In the Tier 3 Control Panel, I navigated to a Group meant to hold all of this customer’s servers.
After clicking Create Server, I selected which Group to put this server into, and chose a location, type, and name for the machine.
Next, I had the option of defining the network segment, resource allocation and server operating system.
At this point, we’ve walked through what many Infrastructure clouds have to offer when provisioning servers. What follows after that is fairly unique to Tier 3. The final (optional) step for any server provisioning is the choice of server tasks (e.g. reboot machine), software installation (e.g. SQL Server) or script execution (e.g. “install Windows Active Directory”). In this case, we wanted a server that already had the IIS 7.5 web server installed so that we could avoid doing it manually.
The Create Server button queued up the server for construction, and within a few minutes, the machine became available for access. The next step was to install the web application onto this server. By default, Tier 3 servers aren’t exposed to the public internet, so we used a VPN client to access the machine. Once connected, we transferred the web application bits to the server and created a website in IIS 7.5.
With this web server in a “complete” state, it was now ready to be turned into a template. The “server details” page on the Tier 3 Control Portal has a button called Create Template which, when clicked, crafts a reusable template from a server. These templates than then be leveraged for new servers or play a part in a Blueprint.
Building the Application Blueprint
Blueprints are Tier 3’s orchestration component which lets developers and system administrators craft complex environments that can then be deployed with a single click. In this case, we want a Blueprint that creates a pair of web servers (based on our just-created template) and a database server. This Blueprint can then be used by every customer and save the SaaS provider from manually constructing each and every environment.
This Blueprint started off with a name, version and privacy setting. Blueprints can be made public (for all Tier 3 customers) or private / private shared which restricts access to a given Tier 3 account holder.
The second step of a Blueprint involves adding servers. Our first two servers relied on the web server template that was created earlier. During the configuration of each server, we had the option of selecting server tasks, software installation and script execution activities to apply to it. For the web servers, no new software was needed because everything we needed was already contained within the template.
After defining the two web servers, a third server was added to the Blueprint. For this one, the Blueprint installed SQL Server 2008 after the machine was built.
With all the servers defined, we could then rearrange the build order, add tasks (such as software installation) and even embed OTHER Blueprints! In this case, the Blueprint was finished and could be saved. After the Blueprint was published to the library, it could be instantiated, or “deployed.” The first deployment step required us to pick server passwords, which Group to place the servers in, and since we chose to install SQL Server, we were asked for database credentials.
The second step of this wizard simply asks the user to confirm all their choices before the Blueprint runs and builds all the servers. Satisfied with our selections, the Blueprint was deployed and its status could be closely monitored.
Testing the Deployment
All three servers were now online. To finish provisioning this environment, we first needed to install the application’s database on our new database server, and then update the web application’s connection strings on the two web servers. There are new capabilities in the Tier 3 product pipeline that would automate this step, but for this example, the process was done manually.
Note that we had yet to configure a centralized management application (that’s coming in an upcoming article!), so for now, the configuration tables were also included in this website’s database. In total, the WebsiteDb database had two tables: one for storing donations to the candidate, and the other which drove the look-and-feel of the website.
The WebsiteConfiguration table described the colors used by the site, the candidate’s name and more.
Finally, the website application was updated so that it pointed to this database for its configuration and donations.
Upon browsing the website, we could see that everything was working and online.
In this article, we saw how a developer could decide to “SaaS their app” and bundle their previously-built web application into a template that could be deployed over and over again for each customer. However, deployment of the application is just one piece. In the next article, we will look at how the SaaS provider can use the Tier 3 Enterprise Cloud Platform to monitor, backup and configure their SaaS environment. After that, we will see how to use the Tier 3 API to create a provisioning and management interface that SaaS customers could use to create and configure their personal environment.
It will surprise no one to say that Software-as-a-Service (SaaS) is a hot topic. Really hot. In 2010, Gartner reported that 95% of organizations are planning to grow or maintain their SaaS investment. According to the influential technology blog GigaOm, the valuation of SaaS companies is skyrocketing compared to more traditional enterprise software vendors. While most organizations are increasing their use of SaaS products, some are looking for ways to offer their own software in a SaaS delivery model. What does it mean to “SaaS your app”? This series of articles will walk through the considerations and techniques for creating (or converting) an application for a SaaS offering. In this first article, we will lay the foundation for the series by identifying the critical aspects of SaaS and what you should look for when planning and architecting your software.
Comparing Application Hosting vs. Software as a Service
Isn’t SaaS just a rebranding of the products and services offered by Application Service Provider (ASPs)? The answer is a resounding NO, but it’s easy to become confused when you find so many products with “cloud!” slapped on their label. To be fair, SaaS is an extension of the ideas introduced by ASPs, but there are fundamentals differences.
Let’s do a quick comparison between the two delivery models.
Software either (1) owned by each customer and operated by ASP, or (2) owned by ASP and environment provisioned for each customer.
Software created and maintained by SaaS vendor.
Typically web-based software built to scale for single customer.
Frequently built as series of decoupled components that cleanly scale for all customers.
Each customer resides in their own environment, thus making maintenance more time-consuming for ASP.
Each customer runs on shared infrastructure and often on the same software instance.
Customer sometimes have direct access to machines that run the software.
Customers only have access to the software itself.
Favors a “scale up” strategy of providing more resources to existing hardware.
Built to scale up and out to accommodate user growth.
Pay annual or long-term contract for hosting services.
Leverage per-user, pay-as-you go model where annual contracts are offered but not required.
Limited “free” customizations as each change increases support costs. Changes to the data model, business logic or security model are typically executed by the ASP.
Per-customer configurations and customizations that survive upgrades. Changes to data structure, business logic or security model are performed by the customer themselves.
Software upgrades or patches require environment downtime.
SaaS software often requires no scheduled maintenance times as rolling updates are performed.
Requires VPNs or scheduled, bulk data transfers.
Most SaaS products have published APIs for interfacing with the system.
In essence, ASPs operate software environments for customers while SaaS vendors let you rent their software in a scalable, self-service environment.
SaaS Your App - Verify the Architecture
Before an application can be delivered in a SaaS style, it has to be evaluated for architectural readiness.
Stateless web servers. In order to cleanly scale horizontally and easily provision new machines, it’s critical to build web applications that don’t maintain any local state. The web servers should rely on some sort of shared database for their configuration. To truly offer a cloud-friendly application, then the architecture must support no-touch elasticity which can’t happen if you have web servers with local state.
No hard coded connections. If your application has web servers that has hard coded values (e.g. IP addresses) for database connection strings or server-to-server communication, you’ll have problems when you migrate your application to the cloud. These things can be tricky to trace, but you really want to make sure that each individual layer of your application can scale independently without breaking connections between the tiers.
Extensible data model. This comes into play if you foresee subscriber-specific customizations taking place. Should customers be able to extend existing data objects, add new ones, or apply unique validation logic? If so, then it makes sense to design the data repository in such a way that customer extensions can take place.
Multi-tenant support. This isn’t as straightforward as it may seem. One of the key principles associated with SaaS is putting multiple customers, or tenants, on a single server or software instance. The benefit of this model is that the software provider gains operational efficiencies because they don’t have to uniquely maintain each customer’s environment. That said, multi-tenancy could happen at multiple layers of your application. Three viable options include:
- Provision unique web applications and databases for each customer. While the underlying infrastructure may be shared among tenants, it is feasible to carve out unique application environments for each customer. The benefits include physical separation from other tenants (which may matter in some industries like healthcare) and the option to upgrade each tenant on their own schedule. This starts to blend back towards an ASP model, but well designed software coupled with a highly automated application provisioning process can still make this delivery model sustainable.
- Have customers share an application (version) but maintain their own unique databases. In this case, a single version of software is installed, but each customer configuration includes a reference to their own database. Here, physical data segmentation still exists and features like per-customer encryption or direct database tunneling are possible, but overall application maintenance is simpler.
- Finally, you could use a Salesforce.com-like model where all tenants share both an application version AND database. Data is logical separated, but physical co-mingled.
Surfaced configurations. If someone is expected to rent your software as-is with absolutely no changes, then there’s limited need to expose user-driven configuration points. However, if you want customers to have the flexibility to extend the data model, change the application look-and-feel, define organization-specific workflows and set up security users/groups, all in a self-service fashion, then it will be key to design your software to support user-driven configuration changes. A critical principle of SaaS is “self service” and not requiring users to call up a service provider in order to implement any changes. By exposing supported, user-driven configuration in your architecture, you make self-service a reality and keep application support costs down.
APIs. If you aren’t offering APIs, then you aren’t offering a real cloud application. Applications without APIs become siloed and more difficult to integration with or manage from afar. Good API design requires work, but the payoff is immense for the customers of the SaaS application.
Thoughtful security architecture. Clearly security is a major consideration when building an application that may be “shared” by hosts of diverse users. In this case, “security” refers to items such as how you identify (authenticate) and assign permissions (authorize) to users, encrypting data at rest, securing data in transmit, providing audit trails and more. Ideally, your application allows Single Sign On (SSO) through a standard mechanism like SAML which then requires one less password for users to create and maintain.
Integration with other cloud platforms. While not a necessity, it’s powerful when cloud applications embrace other cloud applications. Would users of your SaaS application benefit from integration with Google Docs or Microsoft’s SharePoint Online? What about providing a federated identity story using a user’s Facebook or Twitter ID?
While not exhaustive, this list of focus areas should help you identify where you may want to revisit the architecture of the application before offering it up as a SaaS solution.
SaaS Your App - Find the Hosting Environment
So you have a great SaaS-friendly application architecture. Congrats. How do you deploy it in a way that maximizes reliability while minimizing support costs? You will want to find a mature Infrastructure-as-a-Service (IaaS) provider with a mature, elastic environment that has the following capability areas.
Metered Billing. Pay-as-you-go is a key aspect of SaaS software and you want to make sure that you can easily capture usage metrics that can factor into the monthly cost. While you may simply charge a flat price per application user (and forego chargebacks for individual infrastructure costs such as storage, bandwidth and CPU cycles), it will be useful for your hosting provider to show you a clean breakdown of the costs associated with your SaaS application.
Quick horizontal/vertical scale. Sometimes you need more horsepower for a given application server and increasing RAM or CPU makes sense. But recall that “cloud” is associated with easy horizontal scale of commodity hardware. The platform beneath your SaaS application needs to be able to rapidly scale both automatically and through a self-service interface.
Access to web-based installers. Instead of leveraging virtual machine snapshots and rehydrating them when you need more servers, consider building the servers automatically when scaling is required. If you use VM snapshots, you still have to deal with patching and managing them so that they are usable when you need them. Instead, if you have access to the application source code (or web installers for packaged software), you can use any number of tools to quickly and reliably build new servers.
Active monitoring. In order to be able to support a large number of customers on your application, you’ll need to be able to quickly respond to the inevitable issues that arise with the hardware or software. Your SaaS hosting platform needs to be vigorously watching the health of its servers and not only be able to notify you of problems, but also be able to perform prescribed responses (e.g. reboot server, take offending server offline, add more servers).
Global deployment options. One value of SaaS software is that it’s on the public internet! This means that the application may be accessed by users across the globe. If there’s a chance that your SaaS application would be used by global users, consider hosting providers that have an international presence and support provisioning across global data centers.
One-click provisioning. A cloud application architecture may not be simple. Your software may have numerous front end web servers, a web service layer, distributed database system, batch job processing servers and more. If possible, try and find an IaaS provider who allows for “templating” a solution stack and supports a single-click deployment option.
Robust backup and restore options. Disasters happen. Even the best cloud environment experience unexpected issues that can take down an entire data center. You want to make sure that your application data can be readily (and regularly) persisted in a location outside the primary data center. Disaster recovery planning is serious business and ideally, your hosting partner has lots of experience in this arena and can provide both the thought leadership and tools that make this a reliable capability.
A well-architectured application that is stuck in a sub-par hosting environment will quickly result in customers fleeing your service. Unless your service provides unparalleled (and necessary) functionality, the customers will simply flock to competitor solutions that exist on a more reliable foundation.
SaaS Your App - Provide Registration, Management and Billing Services
If the application is well built, and hosted on world-class infrastructure, all that’s left is to make it simple for customers to consume it. In order to build a maintainable platform that requires minimal manual intervention, you should address the following areas.
Sign up pages. This may seem obvious, but you will want to carefully construct a straightforward way for customers to quickly get started with your software. If your sign up process requires someone to call a phone number, you’re doing it wrong.
Management dashboard. Earlier we discussed the value of surfacing application configuration values that allow the customer to make certain changes to the appearance or functionality of the application. Your customer shouldn’t have to make these changes by executing a series of shell scripts or REST API calls, but rather, they must have an effortless way to view and edit configurable values. Likewise, a good management dashboard also exposes key capabilities like security role definitions (and user provisioning) and billing services.
Data import/export services. Congrats, someone decided to use your SaaS product. Now how are they going to migrate their old data into it? If your answer is “key it in by hand,” then you have already started off on the wrong foot. Data import tools make it possible to start using an application right away, and, create some instant data gravity along the way. Just as important as supporting easy data import capabilities, you need to offer a way to pull data out of your application. While the natural inclination may be to lock people into your platform, you’re both harming your customer AND making simple integration scenarios harder.
Spend some time thinking about how you can make it easy for customers (or potential customers) to evaluate, buy and get started quickly with your application.
This first article is meant to get your mind rolling and set up the conversation for the subsequent articles in this series. Coming up, we’ll talk about how you can use Tier 3’s world class environment to quickly create blueprints of your SaaS-ready applications and deploy them to a robust environment. Read the next article in the series: Blueprinting your application.