Add-Ons In the Public Cloud

Update 2024-09-26

If you are interested in LTSS for PAYG instances a new streamlined process for LTSS has been implemented, see Long Term Service Pack Support for PAYG Instances Simplified. For other add-on products the outlined process below continues to apply.

End Update 2024-09-26

SUSE offers a number of services and products around SUSE Linux Enterprise Server such as LTSS (Long Term Service Pack Support), SUSE Linux Enterprise Live Patching, and HA (SUSE Linux Enterprise High Availability Extension). While the additional products and services are agnostic to instance types and flavors (BYOS or on-demand), it is a matter of cost that favors the use of BYOS instances when you want to use any of the add-on services and products. Before answering the question why BYOS is in most cases favorable I will need to cover some technical details about repositories.

Add on services and products generally come in the form of extra repository streams that get added to a running system (VM). Repositories in turn are managed by a repository service. For BYOS instances this repository service is provided by SCC (SUSE Customer Center), your own RMT (Subscription Management Tool) server, or as of SUSE Linux Enterprise Server 15 RMT (Repository Mirroring Tool),  or SUSE Manager.

For on-demand instances the repository service is provided by the SUSE operated update infrastructure in the Public Cloud framework, Amazon EC2, Google Compute Engine, or Microsoft Azure. Repository services are great in that they manage the system repositories based on what the service offers. If a repository is removed from the server that provides the repository that repository is also removed from the connected client system, rather than triggering an error upon refresh of the repos. However, all of this was designed and implemented when things like on-demand instances didn’t exist or were in their infancy. Therefore, functionality that would let  a client interact with more than one repository service provider  was not needed. Times have changed, of course, and we are trying to find a solution to this problem. It is a hard problem to solve and will take time. This is the technical background to keep in mind.

The business background is a data privacy issue and data privacy is very important. For on-demand usage of SUSE Linux Enterprise Server in the Public Cloud, SUSE receives revenue from the Cloud Service Providers (CSP) but no customer information. After all, on-demand users are customers of the framework provider and only indirect customers of SUSE and thus SUSE should not receive customer data from the service providers. This brings with it a disconnect of information. Since we cannot tell if a given user is running an on-demand instance, as this is not track-able, we also cannot correlate such usage to an entitlement of an add-on product. Since all add-on products also require a SLES subscription there is no way for SUSE to connect the dots.

But what does this all mean for using add-on products with Public Cloud instances?

Because we are unable to connect the dots on the business end between on-demand instances and direct subscriptions for add-on products you will have to get a SLES subscription from SUSE directly and then you can get a subscription to the add-on product. This implies that effectively you are paying a premium. For oon-demand instance we are already being paid through the cloud service provider. This is not a good situation for your budget which is why using BYOS instances for the use with add-on products is the favorable solution. When you use BYOS instances you are using a known SLES subscription for which you can easily add any of the available add-ons.

But this is not the end all. If you started with on-demand and you want to use add-ons you have 3 options:

1.) Rebuild your system starting with a BYOS image. A conversion from on-demand to BYOS is not possible, sorry. This is controlled by the framework providers and there is no going back and forth between BYOS and on-demand.
2.) Pay the above mentioned premium, the payment is somewhat implicit
3.) Use SUSE Manager

When you use SUSE Manager you can manage on-demand instances. This is described in SUSE Manager 3.0 arrives in the Public Cloud . Since SUSE Manager is only available as BYOS, you have a direct relationship with SUSE. This allows us to connect the dots and thus you can manage add-on products with SUSE Manager and push them to on-demand instances without incurring the premium described earlier.

None of this is really as bad as it may sound. Before firing up a new instance you have already thought about the workload that will be running on the instance. This provides you with the basic parameters to make a decision about BYOS or on-demand. Can the work load tolerate to go through a system upgrade once every roughly 18 months (yearly service pack releases + 6 months overlap period) and/or can the workload and usage thereof stand reboots for kernel updates on a more or less regular basis. If yes, then on-demand is a great way to go. On the other hand, maybe you have a work load that should not ever go down and thus Live Patching is what you want. In this case BYOS is the more cost effective choice to start out with.

As you can see the thought process about the workload that will be deployed also provides the necessary information that helps you make the decision about BYOS and on-demand and when in doubt, there is always the “Magic 8 Ball“.