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 CenturyLink Platform to package a web application for SaaS provisioning.

Solution Overview

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:

  1. All customers could reside on the same instance of the web application and database.
  2. Customers can share a web application but maintain unique databases.
  3. 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, CenturyLink Cloud 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 CenturyLink 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 CenturyLink Cloud’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 CenturyLink Cloud 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 CenturyLink Cloud 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 CenturyLink Cloud. 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, CenturyLink Cloud 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 CenturyLink Cloud 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 CenturyLink Cloud’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 CenturyLink Cloud customers) or private / private shared which restricts access to a given CenturyLink Cloud 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 CenturyLink Cloud 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 CenturyLink Platform to monitor, backup and configure their SaaS environment. After that, we will see how to use the CenturyLink Cloud API to create a provisioning and management interface that SaaS customers could use to create and configure their personal environment.