On Demand, BYOS, say what? Why do I need it?

One of the messages that has been persistently echoed since the emergence of public cloud frameworks has been the “pay as you go” phrase, or “pay based on your use”. This on demand computing model also brings with it some other expectations. I refer to them as “fire up and use”. Customers expect that the instance they are starting and paying for the minute it starts running is ready to use once they log in. From a distribution perspective “ready to use” implies that repositories should be configured and updates should be available immediately. This topic was the primary subject of my presentation at SUSECon last year and will be touched on at SUSECon 2015 in Amsterdam in early November. In order to make this use case possible, on demand images contain code (“special sauce”) executed at boot time to find a region local SMT server and register with it to receive updates. On demand images are available from the quick launch wizard in AWS EC2, the general image repository in Google Compute Engine (including sles11 and sles12 alias’ on the command line), the public image listing in HP Helion Public Cloud, as well as the Gallery in Microsoft Azure. Upcharges over the basic cloud prices may apply, depending on the framework.

On demand images are great for production work loads if you do not necessarily care to have a direct relationship with SUSE or if you handle your own Linux support but want to run on top of a stable well tested platform with over 7000 certified ISV applications. On demand images also come in handy for bursting, testing, and kicking the tires. With reserved instances in AWS EC2 one can also realize significant cost savings for on demand images.

As the public cloud has become more popular more people are starting to move workloads from their data center to the public cloud. In many cases a support agreement with SUSE is already in place as well as a management infrastructure for SUSE Linux Enterprise Server installations. This may include SUSE Manager or SMT (Subscription Management Tool). In SUSE Linux Enterprise Server 12 SP1 SMT will be part of the distribution and will no longer be a separate product with it’s own ISO. For these cases SUSE announced the availability of BYOS (Bring Your Own Subscription) images in AWS EC2, Google Compute Engine, HP Helion Public Cloud, and Microsoft Azure at SUSECon 2014. BYOS images are found in the general catalog in AWS EC2 (Launch Instance -> Community AMIs -> SUSE Linux) then search for “byos”, in GCE as part of the general listing once you subscribe to the “suse-byos-cloud at googlegroups dot com” mailing list, in HP Helion Public Cloud as part of the general listing of public images, and in the VMDepot in Microsoft Azure. The BYOS images come with no “special public sauce” other than the initialization code for instances to ensue ssh keys are injected and you are able to login. Thus, an instance launched from a BYOS image is equivalent to a physical machine that just received a SLES installation from the ISO image. Once logged in you can connect this instance to your running SUSE Manager or SMT infrastructure or register it directly with the SUSE Customer Center. If you already have a support contract with SUSE this is the way to go. On demand images are of course still a great option if you need to have extra capacity for a certain period of time. However, because of the “special sauce” in the on demand images those should not be registered with your existing update infrastructure or with SCC (SUSE Customer Center). Such a registration will only cause trouble.

Update 2017-05-26: The google group “suse-byos-cloud at googlegroups dot com” has been deleted and BYOS image in GCE are public and can be instantiated just like other public images.

Update 2018-08-13: VMDepot in Microsoft Azure is long gone and BYOS images are found in the Azure Marketplace next to on-demand images, so make sure you choose the image that fits your need. Speaking of choosing the image that fits your need. It is not possible to switch from on-demand pricing to BYOS or vice-versa, meaning once you start with BYOS you are going to be on the BYOS model as long as the instance is running. The only way to switch between on-demand and BYOS is to start over, i.e. start with the other image and re-build your system.

In case everything or large chunks of your workloads are moving to the Public Cloud you will also find SUSE Manager BYOS images available. Some special considerations for running SUSE Manager in the Public Cloud are documented here  and a CloudFormation Template that automates much of this in AWS EC2 can be found here. Therefore, with the BYOS approach you can move your SUSE Manager setup into the public cloud along with your workloads and register any instance created from BYOS images directly with SUSE Manager just as you did in your data center.

In summary, if you already have a direct relationship with SUSE you generally want to start out with BYOS images and use the entitlements you already have along with any update infrastructure you may already manage. For excess capacity needs on demand images are great, but remember that registering those with SCC or your own update infrastructure will create conflicts that are not easily solved.