Partly Cloudy

More Overhead from Many Standards

Although the experts currently largely agree on how native cloud applications differ from conventional programs, the PaaS example on one hand and Docker, Kubernetes, and their kin on the other hand make one thing clear: A gold standard for the operation of native cloud applications does not exist so far, and it is particularly evident in the question of how the operation and how the setup of such applications should look.

From the developer's point of view, distributing an application in prebuilt containers is a convenient approach. However, it does require the customer to find a suitable platform on which the corresponding container will run, which is not currently possible with any of the large public cloud providers, because they have their own ideas of how native apps are to be integrated into their platforms.

As a prime example, Amazon offers so many features in its AWS cloud, that newcomers quickly lose track. From genuine PaaS through semiautomatic platform rollouts via Cloud Formation (Amazon's proprietary cloud orchestration service), almost all variants are conceivable. Microsoft's Azure is similar. If you instead choose a public cloud with OpenStack, you will need to adapt your deployment to specific conditions.

The MySQL example makes this clear: Most popular applications assume that access to some kind of database is available. The conventional approach is to launch a private MySQL on a separate VM on an IaaS basis. Significantly closer to the spirit of PaaS would be to leverage a database specially provided by the cloud (i.e., DBaaS).

If you want to roll out such a setup on Azure, AWS, or OpenStack, though, you will find yourself doing battle with three different orchestration tools (Figure 4). Although the application perhaps approaches a native app, deployment of the software is complicated and is strongly dependent on the selected target platform.

Figure 4: The common goal is a MySQL database, but Amazon, Azure, and OpenStack take different paths to get there.

Greetings from the Container Universe

A sure indicator of microservices winning the day is evident if you take a look into the world of containers. For years, Docker, in particular, has been forging ahead in the same direction as native cloud applications: Docker allows developers to package their applications so that other users can simply download and deploy prebuilt containers.

Many practical examples show that admins should not do this: A huge Docker container with a LAMP stack, in which the admin has made untraceable, manual changes, is a disaster in terms of operation and maintenance. Because Apache, MySQL, and other databases are not native cloud apps, you will have to make trade-offs in many places.

Native cloud applications leverage containers in a better way: A properly optimized workflow allows program authors to package the individual microservices of a cloud application cleanly in standard containers. In the best case, automatically creating appropriate container images will be part of the release process: Whereas the customary process of creating software typically produces a tarball as the final release, a standardized Docker container could just as easily be the result of the release process for native cloud applications.

On platforms like Kubernetes or Docker Swarm, rolling out the relevant application then becomes child's play: Kubernetes, in particular, with its principle of pods and individual containers, is made for native cloud applications (Figure 5). Unlike with PaaS, developers have to take care of a part of the operating system. On the other hand, you can guarantee that the entire environment will roll out on any platform compatible with Kubernetes or Docker without additional overhead.

Figure 5: Kubernetes provides the perfect environment for native cloud applications, but it is not meaningfully compatible with other solutions.

Conclusions

Changes in IT are usually lengthy processes. The cloud itself is the best example. Although several cloud offerings have existed for years, companies are only gradually switching to the new system, and native cloud applications will foreseeably take many years to spread globally.

Applications that have been built especially for clouds are different in many ways from their conventional predecessors and make optimum use of the services typically offered in clouds. Cloud providers and the companies that operate a solution in the cloud have been dealt new cards: From the corporate perspective, the single virtual instance plays virtually no role. Customer expectations of a cloud provider are far more likely to be that they offer the necessary services as PaaS.

In a win-win scenario, the supplier can rely on appropriate standards and thus noticeably facilitate the development and maintenance of the system. In return, customers achieve considerably more flexibility: An application that runs in one cloud will run in another, although still with some imperfections. The ideal state for a software author would be a single container image or a single version of their software to roll out and support in any environment, but so far, the current offerings lack standardization.

The principle of native cloud applications is thus only at the beginning of its story, but with the spread of the cloud and the increasingly powerful services offered by public cloud providers, the principle will definitely pick up speed in the future. Both providers and customers have a strong interest in speeding up the process.

The Author

Martin Gerhard Loschwitz works as an OpenStack Team Leader at Sys Eleven in Berlin. In his free time, he enjoys sailing, preferably on the Baltic Sea.