This content is part of the Essential Guide: A look inside the DevOps movement
Problem solve Get help with specific problems with your technologies, process and projects.

Selling SaaS: Evaluating DevOps tools and models for cloud providers

Without using DevOps tools and principles, the task of building and sustaining SaaS applications can quickly create an operational nightmare for cloud providers.

Most cloud service providers don't believe that the most profitable cloud strategy lies in renting cloud-based CPU cycles or platform services for pennies by the hour. Software as a Service (SaaS) may be the most compelling and lucrative of the three major cloud business models, as it displaces more technical-support costs for customers and can be sold directly to consumers.

Success in SaaS isn't easy, however. Without using DevOps tools and principles, the task of building and sustaining SaaS applications can quickly create an operational nightmare for cloud providers. The biggest source of those headaches: automating the lifecycle processes for the services deployed in the cloud.

Cloud demands new provisioning strategy

In the earliest days of cloud computing, much of the work in SaaS deployment had to be done manually or by developing in-house automation software. This was expensive for operators and often created an inconsistent quality of experience for their customers, but a new strategy is likely to reverse these trends.

In a mature DevOps environment, the developer builds the configuration description alongside the application.

Cloud providers traditionally created their operational tools after designing the service, which meant that these tools had to be customized later to accommodate the requirements of each application or application component. This was an inefficient and clumsy process. Updating this model requires providers to generate cloud-deployment tools during the application-development process, uniting development and operations into the same lifecycle. The the concept is called DevOps, a term that comes from blending the words development and operations. DevOps tools and principles aren't limited to the cloud, but they appear to be coming of age there.

All DevOps-bred applications are a combination of a configuration engine and a set of application programming interfaces (APIs), the latter of which connects the app to management interfaces used to set up cloud services, private servers and network management systems. A description of the application's requirements drives the configuration engine; when run, this engine creates management commands based on the application description. These commands set up the application to execute properly.

In a mature DevOps environment, the developer builds the configuration description alongside the application. The DevOps tools and practices now in use, however, allow developers to build configuration descriptions of applications that have already been written.

DevOps tools: Scripts vs. containers

There are two possible models for DevOps tools: a purely script-based model and a container model.

DevOps tools based on the script model will be very familiar to Linux users, as they allow commands to be saved and run with replaceable parameters. Most of the popular, commercial configuration- and management-automation products fit into the script-based model. This includes Microsoft's Windows Azure PowerShell CmdLets, Amazon Web Services' CloudFormation and Chef, an open-source project Opscode developed.

The container model is based on creating an abstraction of the application into what we might call a container, object, or "charm." The configuration engine then processes this container to issue commands. Among the container-based DevOps tools, only one is widely adopted: Juju, an open-source project Canonical Ltd. developed. The container model, which uses what Juju calls charms, may hold the greatest promise.

The benefits of Juju 'charms'

The advantage of the container or charm model is that it allows cloud providers to build a set of reusable charms that describe application deployment and lifecycle, and to run them as needed.

This differs vastly from the script-based model, which requires a provider to translate an application's requirements (also called a domain-specific language, or DSL) into the script's replaceable parameters. This may require application changes to be tracked through the scripts to ensure the application still runs correctly.

By contrast, the goal of Juju is to make the translation purely a matter of policy statements. This means the cloud provider could potentially give the user a greater role in customization and setup, and it makes the maintenance of application descriptions easier for the provider.

The fact that Juju is open source may be of value to cloud providers that want to customize the tool to support their own service plans, but there are a number of other open-source, customizable DevOps tools and projects that may be viable alternatives to Juju. These include Dell-developed Crowbar, OpenStack's Donabe project, and Canonical's Ubuntu Orchestra. While open-source enhancement is always an option, cloud providers will ultimately benefit from selecting DevOps tools that offer the right features and focusing on developing the scripts, containers or charms for that package.

Using DevOps tools to sell SaaS

Cloud providers should begin their DevOps strategies by setting the DevOps configuration requirements for an application as it's being built. This would normally include all of the provisioning rules, including the setup of software instances, database instances and network addressing. Capabilities of various DevOps tools vary in these areas, so it's important to review the applications' needs against the features and the work plan for the project to be sure everything is heading in the right direction.

Since applications recently deployed in the cloud were likely designed without a DevOps model to follow, it's also helpful to verify that any DevOps tools being evaluated offer the ability to author a template -- describing deployment outside the development process -- that can be retrofitted to legacy applications.

While the biggest value of DevOps tools is in developing SaaS applications to run within the cloud provider's own infrastructure, it can also be used to help customers migrate applications to Infrastructure as a Service (IaaS) or Platform as a Service (PaaS) -- and potentially to integrate multiple providers in a cloud federation. Because all of these applications have a low tolerance for error and a potentially high cost for manual support, the use of DevOps in each could increase cloud profitability and customer satisfaction considerably. In a competitive cloud market, that is absolutely critical.

About the author:
Tom Nolle is president of CIMI Corporation, a strategic consulting firm specializing in telecom and data communications since 1982. He is the publisher of Netwatcher, a journal addressing advanced telecom strategy issues.

This was last published in June 2012

Dig Deeper on Telecommunication networking