Middleware White Paper

Executive Summary

Red Hat’s Middleware portfolio offers a range of products that aim to facilitate and streamline the development, deployment, and management of enterprise applications. The open-source, collaborative nature of the product offerings, platform independence (On-Site/Cloud) combined with the industry best Red Hat support subscriptions elevate this portfolio considerably.

Red Hat Middleware portfolio is segregated into following three major product lines:

Red Hat Runtimes

Red Hat Integrations

Red Hat Business Automation

These product offerings have been transitioned to IBM’s product portfolio. For more information refer to the IBM announcement “IBM expands business automation portfolio with open source process and decision automation” (link no longer available).

Red Hat offerings for these products are however not as simplistic. We will explain how Red Hat defines its services offerings for various Middleware products in later sections of this white paper.

This white paper will guide Software Asset Management (SAM) professionals and IT leaders trying to understand Red Hat Middleware Applications licensing terms and help manage the compliance position for their organisations or customers. This white paper also aims to discuss possible optimisation opportunities that may slip under the radar.

Introduction

In navigating the dynamic landscape of Red Hat’s evolving licensing terms and policies, staying current may prove challenging. Genuine expertise in Red Hat licensing expertise is cultivated over years practice and knowledge on the subject is pretty scarce. This white paper serves as a point of reference, of all the relevant information curated by experienced professionals and, delivered succinctly to provide proper guidance.

Red Hat releases a Red Hat Application Services subscription guide at the following link^[1]

This white paper does not attempt to replace the Red Hat Subscription Guide but to add much needed context derived from experience running successful SAM programs and Red Hat subscription audits. This white paper should be useful for Software Asset Managers, Software Licensing Specialists, IT Procurement, IT Sourcing Experts, IT Managers, CIOs and other IT leaders alike.

Problem Statement

Red Hat Applications (including Middleware Applications) are licensed through Red Hat support subscriptions which have their own complex licensing policies. Licensing middleware application services becomes even more daunting when we consider following aspects:

• Overlapping functionalities and products across bundles
• Metric definition of cores used for licensing
• Available products for fresh purchases vs renewals
• Subtle differences in licensing various IT environments
• Red Hat’s All or None policies
• Red Hat’s backdating policies

Red Hat has always followed the license-only enforcement structure which entails that their products do not technically restrict usage based on non-availability of licenses/subscriptions. Combining this aspect with the IBM acquisition and transfer of ownership, complex licensing metrics and multiple bundling scenarios, IT stakeholders must be on guard and organisationally ready to defend Red Hat reviews and IBM audits.

In the following sections we start breaking down the problem into pieces and offer advice along the way, discussing the most common issues and then delve deeper into license compliance and optimisation process.

Other relevant products

• Fuse Services Works and Fuse are in the same product now.
• JBoss Data Virtualization has reached End of Life in January 2023
• JBoss BPM is now known as Process Automation Manager and is now licensed by IBM
• JBoss BRMS is now known as Decision Manager and is now licensed through IBM
• JBoss Operations Network is now contained in JBoss Data Grid

Most common issues

Based on our experience managing and auditing Red Hat Middleware Application environments, we’ve determined the most common issues as follows:

1. Managing Red Hat Contracts and Procurement
2. Navigating Subscription Bundles
3. Navigating Layered Products
4. Licensing Challenges
5. Subscription Support

1. Managing Red Hat Contracts and Procurement

This section provides key insights to IT leaders and Procurement specialists involved in Red Hat Support subscription purchases.

• Red Hat product and services are governed by the terms and conditions listed in the Red Hat Enterprise Agreement^[2]. This agreement is deemed to be accepted on purchase and/or utilisation of Red Hat products. Procurement and Legal teams should regularly review the agreement document for any changes.
• Red Hat account teams and managers are segregated across geographical boundaries and generally do not have view of subscriptions purchased outside of their remit. Procurement/Sourcing must be informed while renewing their subscriptions.
• All RHEL purchases are linked to an organization Admin Account which is allowed to access the Red Hat Customer Portal. Red Hat requests information for this admin account during every purchase. Sourcing should make sure to standardise one account as admin so that all purchases are allocated and visible under the same account.
• All Red Hat subscriptions follow the Break-in-Subscription policy where subscription renewal for an expired subscription requires payment for the period between the expiry and the renewal. Sourcing teams must analyse the costs of back payments before deciding to renew an expired subscription or letting a subscription expire.
• In the event of an audit, Red Hat will backdate RH installations that at some point in time did not have an active subscription attached.
• Red Hat also follows “All or None” subscription policy for its product families. It means that if there is at least one active subscription, all RH application installations require an active subscription. This rule ensures that customers fully license their use of RH products, rather than only partially licensing their deployment and sharing the update packages, leading to loss of revenue for Red Hat.

2. Navigating Subscription Bundles

We briefly touched upon the various product lines for Red Hat Applications in the executive summary section of this white paper. In addition to these product lines, Red Hat also provides its various applications as part of flexible subscription bundles. These subscription bundles can be found at this link^[3]

Below are some of the noteworthy aspects of these subscription bundles:

• While not explicitly stated, an organization purchasing a NEW subscription for even one of the applications, say EAP, would probably have to purchase a bundle which contains EAP. We have come across instances of Red Hat sales teams pushing bundles for new subscriptions.
• Similar to RHEL and individual Red Hat applications, usage of bundles is also regulated by definitions of use-cases and purposes in Appendix I^[2] of Red Hat Licensing Agreements.
• A bundle subscription entitles the user to a fixed pool of cores that can be allocated across all applications contained in the bundle. For example, a 64-core subscription of Red Hat Runtimes, would allow the user to deploy 32 cores of JBoss EAP and 32 cores of Data Grid but not 64 cores of EAP and 64 cores of Data Grid.

3. Navigating Layered Products

Red Hat application products are usually layered i.e., subscription to a particular application allows subscription support for all layered products under that application. For example, a Red Hat Fuse Subscription includes an entitlement for Red Hat AMQ and JBoss EAP. Details of layered products can be found at this link^[4].

While Red Hat suggests that these layered products should be used for the same use case, these are not restricted use rights which means that these entitlements can be used standalone on separate hardware.

However, the concept of pooled cores applies in this scenario as well. A 64-core subscription of Red Hat Fuse does not include 64 cores of AMQ and 64 cores of EAP.

A thorough cost benefit analysis must be undertaken before deciding between layered and standalone product purchases for any requirement.

4. Licensing Challenges

Red Hat presents unique licensing challenges to SAM professionals. Many of these challenges have been discussed in our RHEL White Paper. The following sections of the RHEL White Paper are equally applicable to this discussion:

• Visibility Risks
• Complex Licensing Agreements
• Compliance Risks

We shall now discuss some of the licensing challenges unique to Red Hat Middleware applications below:

5. Subscription Support

Red Hat Application production support is available in two levels. Standard and Premium. The service levels available for each type of support subscription is available for review at this link^[6].

Few important points with respect to subscription support are provided below:

• There are no self-support subscriptions available for Red Hat Applications.
• “All or None” policy does not apply to the type of support subscriptions. It only specifies that all or none installations must be covered with a support subscription. Customers are free to mix the support levels within the same environment.
• Customers must also be aware of the PAYG scenarios for Red Hat Applications on Public Clouds. Usually, the support for applications is included in the monthly billing in case app services are being utilised.
• Red Hat support for public cloud BYOS scenarios require Cloud Access registration.

Problem Solving Process

In this section we detail the process of effectively licensing various IT environments for Red Hat Middleware products. The licensing process includes the following major components:

1. Data Collection

• Entitlement data
• Software inventory data
• Hardware inventory data

We have discussed in detail the Data Collection aspect of the licensing process in our RHEL White Paper. Readers must review this section in the RHEL White Paper for better understanding on how to identify requisite information for effectively licensing their IT environments for Red Hat products.

For Middleware Application licensing there are specific Hardware/compute information required in addition to those mentioned in the RHEL White Paper. These additional data elements are listed below:

• number of compute cores available in the hardware.
• number of compute cores allocated to the middleware applications.
• For public cloud:
  • of VCPUs available for use for the application
  • Hyper-threading status of the cloud instance
  • Core to VCPU ratio for the cloud instance

All Red Hat middleware applications are licensed with the Core metric and require the similar hardware/compute information. Requirements specific to any application shall be discussed in the following section.

2. Subscription Allocation Analysis

Red Hat middleware applications are licensed with the core metric and have the same licensing requirements. We can use various middleware products as examples, but the process can be interchangeably used for any middleware applications. Accordingly, we would now discuss licensing aspects for various IT environments.

Before we discuss each IT environment and various scenarios, below are some of the basic universal licensing rules for all middleware applications:

• All applications are licensed with the core metric.
• While calculating core counts to be covered with a license, we need to consider the number of cores allocated for the application use. However, the total count of cores for a server to be covered with a license, cannot be more than the actual physical cores on the server. i.e., if the total virtual cores for a configuration are 16 but the actual physical cores are 8, then license must only be purchased for the 8 physical cores.
• All installations of a Red Hat application must be covered with a license – all or none policy.
• Core Bands purchased for Red Hat Subscriptions can be broken/shared across multiple environments i.e., these subscriptions are sold in core band units (of 2, 16 and 64) but do not need to be allocated to IT environments in multiples of core band units.

Let us now discuss licensing scenarios in various IT environments.

2.1. Physical Production Environments

Configuration 1

Physical environment without OS partitioning with a total of 16 cores.

Configuration 2

Physical environment with OS partitioning (or capping) with a total of 16 cores.

Extended Lifecycle Support: If in any of the above configuration, if the Red Hat application version running is in ELS lifecycle phase, then we need to allocate separate ELS subscription for that application.

Example: In configuration 2, Red Hat Web Server version is in ELS Phase. In addition to the base application license, we also need to allocate 8 cores of ELS Add-On for JBoss Web server for effective licensing.

2.2. Virtualised Production Environments

As discussed earlier, Red Hat allows for limiting allocated cores for the purpose of subscription licensing. One of the benefits of Virtualization is efficient utilisation of compute resources by allocating resources various VMs as per requirement.

In the above example, there are 2 VMs running on the virtualised host. The first VM only utilises 6 virtual CPUs while the second VM is allocated only 4 virtual CPUs.

ELS licensing shall follow the same concept as discussed in the Physical Environment licensing.

2.3. Disaster Recovery Environments

For the purpose of Red Hat applications, the disaster recovery environments are segregated in the following categories:

The definitions of these environments can be found in the Red Hat Subscription Guide

Licensing Requirements

• All cores in the Hot DR/Failover environments are counted for allocating application subscriptions. The core counting is still based on the rules discussed under Physical and Virtualised environment sections above.
• Cores in Warm DR and Cold DR environments are not counted for the purpose Red Hat applications. Organisations must take care of the definitions of these environments along with product use case referred in Appendix I^[7] of Red Hat agreements.

2.4. Public Cloud Environments

Red Hat allows customers to utilise their subscriptions as Bring-Your-Own-Subscriptions (BYOS) on public clouds hosted by Red Hat’s Certified Cloud and Service Provider (CCSP) partners. This is achieved through Red Hat’s Cloud Access Programs. You may read more about Cloud Access in the Cloud Access reference guide.

Currently Middleware applications are allowed^[8] as part of cloud access program. For BYOS scenario’s the licensing process shall be as below:

• Licensing Red Hat applications on public clouds BYOS scenarios is similar to other environment discussed in earlier sections.
• Since the licensing metric for Red Hat applications is cores, licensing calculations depend upon the VCPU to Core ratio for the cloud instance on which the application is installed. VCPU to Core ratios are regularly updated by cloud providers based on the hyper-threading capabilities of the cloud instances.
• A cloud instance of VCPU to Core ratio of (1:1) and total 16 VCPUs would require 16 cores of Red Hat Application licenses. On the other hand, the same cloud instance with VCPU to Core ratio of 2:1 would require only 8 cores of Red Hat Application licenses.
• Similar to other IT environments Red Hat customers can aggregate all licensable cores for their cloud environment for various middleware applications while planning purchase of entitlements.

2.5. Development and Test Environments

Appendix I^[7] of the Red Hat agreements segregates development/test environments on the basis of the number of users and product use cases.

• In a Single-User environment with use cases limited to code development, prototyping or product demonstration, Red Hat allows for usage of its applications without a subscription. Cores allocated for these environments are not to be counted for calculating subscription requirements for Red Hat products.
• Multi-user development environments along with product uses such as functional testing, integration testing, UAT, staging, pre-production etc. are all considered under the “production” use case as per the Red Hat product use cases.

For all such environments, Red Hat requires the customers to count the number of allocated cores for licensing their application products.

The cores are counted in the same manner as discussed in earlier sections for physical, virtual or cloud environments.

Various Licensing Rules and their official sources referred in the above sections are detailed in Appendix A.

Conclusion

Navigating the complexities of Red Hat’s licensing terms and policies can be daunting, especially as these evolve over time. Expertise in Red Hat licensing is both rare and valuable, developed through years of practice in a field where knowledge is scarce. Traditionally, Red Hat has employed a license-only enforcement structure, meaning their products do not restrict usage based on the absence of licenses or subscriptions. However, this approach, coupled with the IBM acquisition and the resultant changes in ownership, has introduced more intricate licensing metrics and various bundling scenarios. As a result, IT stakeholders must be vigilant and prepared to manage Red Hat reviews and IBM audits effectively.

Appendices

Appendix A

Glossary