Determining the size of an acquisition

Each customer must look at the application deployment requirements to determine the appropriate quantity of application platform entitlements needed. This should include all environments such as testing and production. Ultimately, when acquiring a Red Hat JBoss EAP subscription, you must determine the number of cores will be need to run your applications. Red Hat subscriptions are available in 16- and 64-core increments for use in physical, virtual, and cloud environments. JBoss EAP entitlements can freely move between any supported environment.

Pivotal’s pricing strategy, by comparison, is much more difficult to understand. First for on-premise pricing, Pivotal tcServer is available in developer, standard, and spring edition. Developer edition is free for download. Standard and spring editions can be obtained as part of VMware vFabric Suite, independently with a perpetual license, or independently via an annual subscription. In all cases, pricing is based on physical CPUs with up to six cores per CPU. Each additional six cores require an additional license. Choosing support that provides 24×7 or 12×5 support can also impact the overall Pivotal cost of acquisition.

For public Pivotal Cloud Foundry deployments, users must determine the number of application instances and amount of memory used by each. The criteria for sizing a private cloud based on Pivotal Cloud Foundry is information that Pivotal has not made available to the public.

IBM’s pricing strategy, by comparison, is much more difficult to understand. It offers four different types of user-based licensing, four types of capacity-based licensing, and two types of “other licensing” that are used for on-premise deployments. All IBM WebSphere software is priced using one or more of those metrics. Based on discussions with people who have interacted with IBM, it appears that the most common form of IBM pricing metric proposed for licensing terms is based on processor value units, commonly referred to as PVU pricing. Using the IBM PVU pricing metric, a count of cores by CPU make and model is commonly required.

For IBM public cloud entitlements, “charges vary depending on the resources used by a particular service, runtime, container, virtual machine, or support option.” WebSphere Application Server is only available from IBM on BlueMix using virtual machines that is free while in beta (as of May 2016). WebSphere Liberty Profile is available for use with IBM containers or running in a Cloud Foundry buildpack. In both cases, the price is based on the application size and run times, calculated in GB-hours. It takes the number of instances, the total memory of all instances, and then the total hours that those instances have run.

The criteria for sizing a private cloud based on BlueMix is information that IBM has not made available to the public.

Oracle’s pricing strategy for on-premise use of WebLogic Server is much more difficult to understand. There are multiple pricing dimensions to consider.

The first is based on counts of the total processors WebLogic Server will operate on. However, the Oracle definition of processor for licensing purposes does not mean CPU. The US Oracle Technology Commercial Price List is a public document that contains a long definition of “processor.” Part of the definition states that “the number of required licenses shall be determined by multiplying the total number of cores of the processor by a core processor licensing factor specified on the Oracle Processor Core Factor Table.” Put simply, “core factor” is a weighting factor that impacts the final processor count based on CPU type. The theory is that different CPU types perform better or worse than others. For example, Intel chips have a .5 core factor, IBM Power & System Z core factor of 1, SPARC T3 has a .25 core factor, and other chip types have other values. Therefore, determining the total number of WebLogic Server licenses you need requires a total count of cores by CPU type.

The second, pricing dimension to consider is virtualization. Oracle differentiates between hard and soft partitions for sub-capacity licensing; in this approach, only the cores in use by virtualization environments are counted. Soft partitioning software such as Oracle VM, VMware, and KVM does not provide sub-capacity advantages. Instead, the entire set of CPUs–no matter how few are actually running the workload–must be licensed. However, hardware based, or hard partitions such as Solaris Zones (also known as Solaris Containers, capped Zones/Containers only) and IBM’s LPAR may take advantage of sub-capacity licensing.

Additional factors to consider specifically in relation to Oracle virtualization policies for Oracle Fusion Middleware include the following:

  • Oracle Linux is the only Linux distribution Oracle supports partitioning on
  • Only Linux and Docker containers are supported in Oracle Linux
  • Only Hyper-V is supported for Microsoft Windows
  • All of the supported points above require WebLogic Server licensing for all cores in a server

The final pricing dimension to consider is multitenancy, a new add on feature that adds 80% to the cost of the 12.2.1 version of WebLogic Server. Multitenancy in a nutshell allows users to pack more applications into each server instance. Michael Lehmann, VP of product management for WebLogic, used a consolidation factor of three times when interviewed for an InformationWeek article. A three times consolidation on a new license purchase can mean a 38% reduction in Oracle licensing and support fees.

For existing Weblogic customers, the cost savings calculation is not about reducing cores, but rather expanding the number of applications deployed. What drives this inverse calculation compared to new customers is that Oracle has not made public–in any source Red Hat could find–that existing WebLogic customers can reduce the count of WebLogic cores they pay support for using multitenancy. Existing WebLogic customers will continue to pay the same amount of support for the WebLogic cores they already own. Therefore, customers who want to justify using multitenancy must find more applications to run using existing licenses. This requires changing the multitenant factor from indicating a reduction in cores to an expansion of application density. Customers who can’t expand existing application footprints by roughly 70% will find just buying more WebLogic cores to run those applications more cost effective. However, once that application expansion threshold is passed, the value of multitenancy savings might be realized.

Comments are closed.