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 CenturyLink Cloud 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 CenturyLink Cloud 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 CenturyLink Cloud 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 CenturyLink Cloud engine went to work provisioning that environment for the customer.
About securely calling the API
Note that before an application can successfully call the CenturyLink Cloud 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 CenturyLink Cloud 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 CenturyLink Cloud 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 CenturyLink Cloud 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 CenturyLink Cloud 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 CenturyLink 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 CenturyLink Cloud 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 CenturyLink Cloud 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, CenturyLink Cloud 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 CenturyLink Cloud can help ensure that the underlying platform provides everything you need.