Problem solve Get help with specific problems with your technologies, process and projects.

Building cloud-ready applications: What changes?

To maximize profits, providers must understand cloud-ready applications, learn how to meet their unique requirements and offer facilitating services.

While nearly any application can be cloud-hosted in some way, there are design and development steps that will optimize cloud deployment and thus facilitate cloud growth. Cloud providers need to understand the concept of a cloud-ready application, build their cloud infrastructure toward a cloud-ready future and offer facilitating services if they want to maximize their profits in the cloud.

Cloud readiness means addressing cloud differences. The cloud hosts applications or application components on virtual resources, and these resources differ from a typical virtualization-equipped data center in several important ways. First, the resources are assigned dynamically, whereas in most virtualized data centers, virtual machine assignments to applications are largely static. Second, they are distributed over a wide-area network (WAN), whereas most applications expect resources to be locally connected. Third, they are partially or completely outside the customer's control, which means that resource allocation and management follow the rules of the public cloud hosting provider -- not the application's user.

To accommodate dynamic resource allocation, the cloud-ready application must include the use of a formal DevOps tool for deployment and redeployment. During development, the application architects and development team must create the necessary scripts or descriptors to define how the application is mapped to the server, storage and network resources it requires. These scripts or descriptors are then used by operations personnel to deploy and integrate the application into the company's workflows.

Cloud operators can facilitate DevOps-readiness in two ways. First, they can provide management hooks from popular DevOps packages to their cloud management systems to help users and developers deploy cloud-ready apps. Second, they can offer "DevOps as a Service," meaning they would host a DevOps tool as part of their cloud management platform. If providers combine hosted DevOps with application integration tools that facilitate the connection of public cloud resources with enterprise-hosted applications and components, the result is what is now being described as an integration Platform as a Service product. Not only would this give operators a new source of revenue, but it would also help users build cloud-ready applications and encourage developers to think about cloud deployment as applications are written.

Distributed networks in cloud present new challenge

To accommodate dynamic resource allocation, the cloud-ready application must include the use of a formal DevOps tool.

A distributed network architecture is the other unique cloud property, and it has two dimensions in cloud readiness terms. At one level, the network connectivity an application needs is a dimension of its DevOps descriptions. Most applications can be visualized as a virtual LAN hosting one or more components that is linked to users through a default gateway (typically a router). Creating this configuration is part of deployment and redeployment requirements, so it must be considered in the DevOps process outlined above. But at the second level, distributed networking will affect application design, particularly in the area of componentization and orchestration.

The paramount rule of cloud readiness -- in terms of distributed networking -- is to avoid separation of components or resources that create significant workflow movement over the WAN. Reading or writing a database record by record is an example of a workflow that shouldn't be run over a WAN, and thus databases in the cloud should be integrated with the components that access them wherever possible. This is an element of application design. The most popular strategy for creating a cloud-ready data access design is to define a database management system "component" that accepts a query (in SQL form, for example) and processes it against a local database to return only a result. Hadoop and MapReduce are also architectures defined to allow for cloud-hosting of query processing -- not cloud access to individual database records.

Cloud operators can help users deal with issues associated with distributed networks by providing cloud application telemetry designed to spot inefficient workflows. They may also offer structured query-oriented services like a relational database management system delivered as Software as a Service, or they could offer Hadoop with specific management tools to help integrate these services with cloud applications. Monitoring intra-cloud traffic is the easiest way to spot problems with workflows, but sometimes even knowing the structure of how customers link database services to their cloud applications will signal a potential issue related to distributed networking. Fixing it in the pilot phase will help the customer make the business case for the cloud.

Cloud-ready apps require more visibility

Perhaps the most complex issue in cloud readiness is that resources are not under the direct control of the application's owner. Traditional hardware and software management are either modified or ceded completely to the cloud provider, and the provider's management interfaces make only certain management functions available. The issue can be divided into two areas: management visibility and control of an application's quality of experience (QoE).

Providers don't want customers to plan on installing hardware in their cloud, so to collect management data on application and network performance, the cloud will either have to host software elements collaterally with the applications to collect data and send it to the application user, or the cloud provider will have to make performance and status information available to the user through a management interface.

Most providers offer basic management data but no mechanism for capturing all of the data typically needed in order to manage application QoE. This means that customers will not only have to attempt to collect the data in a way transparent to the provider, but they must also integrate it in some unknown way with other network and application performance data to manage application performance and availability. It would be wise to consider offering not only performance information on cloud resources a user consumes but also network data on the cloud-side connection to the network.

Cloud readiness demands application awareness in the cloud. Providers should recognize that the long-term evolution of cloud services will move toward Platform as a Service as more cloud-hosted service elements become integrated with applications during the development phase. This increases the customers' business case for the cloud, the budgets they make available to fund cloud projects and the overall profit of cloud operators.

About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecom and data communications since 1982.

Next Steps

An overview of programming languages for cloud applications

The differences between native mobile apps and cloud mobile apps

Which UC applications are best suited for the cloud?

This was last published in July 2013

Dig Deeper on Telecommunication networking