Partly Cloudy

Many standard applications are very difficult to roll out in a cloud, and the more specific the use case (i.e., software developed in your own organization years ago and adapted to your requirements), the more likely it will run only within its original environment.

Native cloud applications distinguish themselves from traditional applications, in that you can roll them out easily in almost any cloud stack and automatically leverage the available services. In this article, I consider the question of how clouds differ from traditional virtualization and how important these differences are for software that you want to run in a cloud. I also look into what programmers should consider from the outset to prepare an application for use in clouds.

Flexibility Is a Prerequisite

In the cloud community, they say, it is all about cats and cattle. Cats are classical physical or virtual systems that the admin sets up manually, with great attention to detail: A cat is raised by hand, it is given a name, and goes to the vet if it is sick. The corresponding virtual machines (VMs) are also unique and given special treatment. They cannot be recovered easily, for example, because they contain transactional data. Typically when they break, at least part of the entire platform grinds to a standstill. You can't stretch the metaphor beyond this point, because providers typically design special-purpose VMs of this type redundantly, so they survive even the failure of critical infrastructure, such as the hardware.

Clouds need more flexibility. Each VM is ideally the result of a defined and precisely reproducible process, in the course of which it is generated automatically. At any time, it is possible to expand an existing virtual instance, adding another instance of the same type with the same configuration.

This requirement accommodates the very limited likelihood of the availability of individual services. If you run 1,000 or more computers as part of a cloud, you can't set up each individual VM to be redundant without skyrocketing costs. Instead, it is the admin's responsibility with such platforms to keep each VM as generic as possible and to construct the environment so that the failure of individual instances does not lead to failure of the entire platform.

In this context, the comparison with cattle becomes understandable: In a herd of cattle, the animals typically have no names, just a tag in their ear with a number, so it is no longer about the individual animal, but simply the result produced by the group of animals.

IaaS Is Just a Crutch

If companies migrate existing software to the cloud, the goal is typically infrastructure as a service (IaaS; Figure 1); in other words, an application already deployed in a department or at a customer site has simply migrated from VMs in the data center to other VMs, either in the corporate data center or in a cloud operated by a public provider. After the migration, the benefits of this data center are available to the applications in the cloud, such as the ability to launch new virtual instances quickly. The same process might have taken weeks before, because hardware would have to have been purchased.

Figure 1: When you hear the word "cloud," you instinctively think of IaaS, but the trend is clearly toward native cloud apps on a Platform as a Service basis.

Soon the admin in charge will notice that virtually all major clouds – whether public or private – have different services on offer besides IaaS, such as databases as a service (DBaaS), wherein the cloud provider relieves the customer of the responsibility of operating a database, such as MySQL (Figure 2). Using their own interface or an orchestration solution, the customer clicks to compose a virtual database and receives an IP and login information at the end of the process. The customer uses the credentials in this application and then simply shuts down their own VM with MySQL. This process is a typical example of how users leverage generic services in a cloud.

Figure 2: Relic of the past? Native cloud applications no longer expect to have to worry about the database.

The same is true with Platform as a Service (PaaS), which even eliminates the operating system as a component for the user to manage. With PaaS, the customer can use a complete, ready-for-action environment (Figure 3), such as one in which they can run PHP websites or in which C++ programs work. The customer simply installs their application in this environment and – hey presto – it is ready for use.

Figure 3: Real PaaS relieves the user of the need to take care of VMs and operating systems.

At this point, it often becomes painfully obvious where the differences between a native cloud application and one from the classical world lie: Classical apps require individually tailored libraries or interfaces or are rigidly linked to external services such as databases. The most conventional systems tend to be monolithic, with one big program, rather than the many small components you find in a PaaS environment.

Twelve Rules

How should companies develop new applications or rebuild existing ones, to operate them easily and seamlessly in clouds and PaaS environments yet ensure that they scale and cope well with the limited availability guaranteed in the cloud?

The Twelve-Factor App [1] provides important information on this topic. This methodology, written by Adam Wiggins, lists 12 rules that app developers should adopt. The first concern is how the programmer should deal with their code.