Partly Cloudy

Central Code

In a classical setup, the admin typically copies an app from server to server as a tarball and then individually extracts each. In clouds, this approach is not practical. Preferably, all of the required code is kept in a version control system (e.g., Git), so it can be checked out anywhere. Version control is especially useful if you want to roll out different setups in different clouds with the same source code. At the same time, this process ensures that everyone really does use the same source code.

Another condition must be met: The source code of the application must not contain customer-specific details or configuration files for a particular setup. In clouds, the basic expectation is that the configuration comes from the environment. You can achieve this in different ways. One way is to have a configuration database running in the background (e.g., Etcd, Consul, or Fleetd) that is rolled out along with the application and fed the required data. The application then connects to this service to retrieve its data.

Another way is to save the configuration data in the metadata of the cloud environment. All major clouds offer the option of defining metadata when you create VMs. The metadata must contain all the information required for operating the platform, and the application must retrieve that information accordingly. Amazon – or clouds that seek to be compatible with Amazon – solve the problem with cloud-init. When a cloud VM boots, the tool connects to the pseudo-address http://169.254.169.254 and reads the stored metadata. An application on the VM can use the same approach.

For the application to be executable on as many vanilla VMs as possible, you also need to define its dependencies cleanly: For example, to roll out automatically, a PHP application has to ensure that all required PHP modules are installed. The same applies to virtually all scripting and programming languages.

Services in the Background

Most web applications are dependent on other services (e.g., MySQL), but because the application itself has no influence on these services, Wiggins assumes that it does not need to worry about them. Therefore, the admin's task becomes providing a working MySQL database for the application. The app receives the information about where to find the database, along with the configuration, as previously described.

Wiggins takes this one step further: Native apps for the cloud basically make no assumptions at all about how the physical environment in which they run is designed, including the concrete implementation of services, such as persistent storage, or the virtual network. The behavior of the application is affected in different places, such as the logs: Conventional applications write their logs to files. Instead, Wiggins basically urges developers to write all log output to stdout and then let the surrounding platform decide where this output goes.

Dynamic Development

The need for cloud compatibility affects the way applications are developed. The principle is simple: Strictly separate development from the operation of a solution. The use of development versions is thus ruled out in production operations.

The principle of "release early, release often" also applies: The delta between production and the current development version should be as small as possible. Multiple rollouts per day are therefore preferable to a large rollout every six months. In the same category, within an app, any system should be replaceable at any time by a new version of itself.