The Public Cloud Module — A closer look

With SUSE Linux Enterprise Server 12 the concept of modules was introduced. For general information about modules see the SUSE Linux Enterprise Server 12 Modules white paper and my previous blog on the subject.

Today I’d like to take a closer look at the stuff we (the public cloud development team) put into the Public Cloud Module and what the life cycle designation of “continuous integration” means. Since the “continuous integration” part is probably the most “scary” part for “traditional” enterprise customers lets start there.

The Public Cloud is a really fast moving set of services that continues to grow in importance in the enterprise as well as in many other aspects of people’s lives. Historically enterprise distributions were focused on data center installations where systems administrators install a set of applications onto physical hardware. The applications run for as long as the hardware is deemed suitable or the hardware croaks. Thus, stability of the underlying OS with as few changes as possible is very much desired. Not just by the systems administrator, no changes no additional maintenance work, but also by ISVs.

If there are no changes to the underlying OS the application developer has nothing to worry about. However we all know that the world is a different place. First there are those pesky bugs that get found every now and then and then there is that security stuff we have to worry about.

Anyway, over the years a reasonably stable equilibrium has developed where enterprise distribution vendors rarely break an application with bug fix or security updates and developers at ISVs have come to terms with the stream of changes in an enterprise distribution. This, lets call it gentleman’s agreement, provides enterprise customers what is needed with respect to support for long periods of time.

The problem that arises from this model is that the world is not static. There are hardware changes, for example, and if an OS and application get migrated to the new whizbang hardware it sure would be nice if both could take advantage of the new hardware and run faster. These types of requirements are handled in the enterprise distribution model with update releases or service packs to a given base.

One can think of a service pack as a transition point where compatible changes are introduced into the system that are of a bigger nature than just your everyday bug fix. All of this has worked reasonably well in the past. However, over the past few years, not only has the feature development in hardware accelerated, these days one gets the feeling that it is impossible to buy the same hardware (meaning the exact same components) for more than six months, but the use of virtualization and the public cloud have introduced additional velocity into the system.

Public cloud providers continue to add new services to make it easier for people to use their offering and migrate some or all of their workloads into the public cloud. The new features introduced by public cloud providers are generally usable through a web UI and command line tools. With SUSE Linux Enterprise 12 we deliver the command line tools, more on this later, as part of the Public Cloud Module. Therefore, when new features are available in these tools it only makes sense to have the features in the packages provided through the Public Cloud Module repository.

In general this requires a version update and often also version upgrades of dependencies. In order to support these reasonably frequent version updates the designation chosen for the life cycle model for the Public Cloud Module was “continuous integration.” Thus, for the module “continuous integration” does not imply that the repository is magically connected to GitHub or where ever the code may be developed. Rather it implies relatively frequent version updates when those are warranted. Primarily the version updates will occur when new features are integrated into the command line tools or improvements are made in instance initialization code. This is a perfect segway into “what is in the Public Cloud Module”, but before we get there lets take a short detour.

As we have seen above “continuous integration” for a module is not all that continuous. However the life cycle designation of “continuous integration” still makes a lot of sense and is certainly better than “relative frequent version upgrades for the content.” The term of “continuous integration” is well known in the IT industry and associated with frequent change. Thus, while packages in the Public Cloud Module do not continuously change they do change frequently.

The content of the Public Cloud Module can roughly be separated into 3 groups, the command line tools, instance initialization code, and infrastructure for Public Cloud providers.

Command Line Tools

The Public Cloud command line tools are tools that allow you to manage services and server deployments in a given public cloud framework. This includes starting and stopping instances, setting up network interfaces and network rules, to name just a few features. At present the Public Cloud Module provides packages for command line tools for Amazon Web Services, Google Cloud Platform, and OpenStack, covering the frameworks of our partners. Those following the Public Cloud story will notice that command line tools for Microsoft Azure are missing. The reason for this is that the available tools are based on Node.js and the development model and handling of dependencies of Node.js is not conducive to providing a maintainable and supportable solution for our users. The Public Cloud team at SUSE is working on a solution to this problem. Watch this space for news about this in two or three weeks. All of these command line tools have a dependency chain of course, and these dependencies are also delivered with the Public Cloud Module, some are found in the core of SLE 12.

Instance Initialization Tools

The various cloud frameworks make data available to an instance as it is being launched. One very important data set is the ssh key to support log in. After all launching an instance in a public cloud and not being able to login in is probably not very useful. The initialization code is responsible for retrieving the data from the framework and using it to set up the instance that is being launched. This code is necessary when building images that are targeted to run in a public cloud framework. For the most part we handle this part for our users by providing on demand as well as bring your own subscription images in the public cloud frameworks of our partners.

Packages for Cloud Service Providers

SUSE has a number of partners that provide SUSE Linux Enterprise in their cloud framework without SUSE being directly involved in the maintenance of the update infrastructure. For these partners a number of packages are included in the Public Cloud Module that makes it easier to set up and maintain an update infrastructure.

If you were looking for a package list when you started reading, I am sorry I hate to disappoint. However, hopefully this provides a good insight about what “continuous integration” for the Public Cloud Module means and what types of packages you will be able to find in the repository.