SUSE Blog

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

rjschwei

By: rjschwei

September 10, 2015 1:32 pm

Reads:3,331

Comments:3

Score:5

Print/PDF

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.

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.

2 votes, average: 5.00 out of 52 votes, average: 5.00 out of 52 votes, average: 5.00 out of 52 votes, average: 5.00 out of 52 votes, average: 5.00 out of 5 (2 votes, average: 5.00 out of 5)
You need to be a registered member to rate this post.
Loading...

Tags: , ,
Categories: Cloud Computing, Enterprise Linux, Expert Views, SLES on Azure, SUSE in the Cloud, SUSE Linux Enterprise Server, SUSE Manager

Disclaimer: As with everything else in the SUSE Blog, this content is definitely not supported by SUSE (so don't even think of calling Support if you try something and it blows up).  It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.

3 Comments

  1. By:mrmichael112002

    How is the build/release version control managed? Is there a traceable method to positively identify SUSE builds between two geographies? If I have a USA region for AWS and a Euro AWS source, how can I confidently know the two sources are exactly equal for kernel, rpm, etc,.? Each marketplace per region gets a new AMI number, so that won’t do it. SW qualification on specific builds are a mission critical requirement. How does this process work?

  2. By:rjschwei

    All images have a date code, such as v20170620 the latest release of the on-demand images. Images with the same date code are identical. If you are looking for a specific image you may alos find pint [1] helpfule.

    [1] https://www.suse.com/communities/blog/riddle-me-this/

Comment

RSS