Acquiring and Saving on 3rd Party Software in Azure

Acquiring and Saving on 3rd Party Software in Azure

1. Purchase as an Azure Product

When an organization chooses to acquire a 3rd party product as an Azure product, the product is delivered and billed by Microsoft, with no direct relationship with the vendor of the respective product. Examples include Azure Databricks, VMWare, SuSe Linux, and RedHat. Contracts with Microsoft for support, as well as agreed-upon organization-level discounts, such as the Microsoft Azure Consumption Commitment (MACC), are applicable. The costs of such purchases seamlessly integrate into usage reports, providing transparency for showback and chargeback.

Commercially, Microsoft offers commitment-based discounts, similar to those for their internally developed products. For instance, with DataBricks, one can opt for an annual or quarterly monetary commitment, while for Linux, Azure license plans are available.

2. Purchase from the Azure Marketplace

When procuring through the Azure Marketplace, the 3rd party product is delivered by the external party, but billing occurs through the Azure invoice. Marketplace costs are visible on the invoice. However, it can be challenging to correlate these costs with specific usage per Azure subscription, making it more difficult to allocate these costs accurately. Vendors must meet strict requirements to be included in the Marketplace, ensuring Microsoft safeguards proper functionality. The vendor is responsible for providing support. Usage of the Azure Marketplace can, in some cases, contribute to the Azure Consumption Commitment (MACC).

What not everyone may be aware of is that divergent agreements regarding pricing and legal terms are made. It is possible to negotiate discounts on the standard price visible in the public marketplace. Deviating agreements are documented in a Private Offer, which is obtained through the marketplace.

3. Direct purchase from Vendor/Reseller

The last option involves the direct purchase of software from an external vendor or reseller, followed by implementation in Azure. This implementation can be IaaS, PaaS, or SaaS. In the case of IaaS, it is akin to an installation similar to on-premises environments. For PaaS, there are options to apply Bring Your Own License (or Azure Hybrid Benefit), for example, for OS licenses. For SaaS, the product is installed either entirely or partially in the Azure environment, with the vendor taking full responsibility for product management.

In a direct purchase, the buyer and vendor jointly determine the terms for product acquisition. It is often possible to use previously purchased (on-premises) licenses in Azure. Since only maintenance and support need to be paid, the costs are generally lower than new cloud acquisitions. However, this often requires a certain commitment, such as specifying the number of licenses or subscriptions for a year, which may not always align well with the flexible nature of cloud workloads. Because these products are purchased outside Azure, the procurement and usage costs cannot be automatically included in FinOps cost reports. This underscores the importance of collaboration with Software Asset Management (SAM), which must diligently track how licenses in the cloud are used in relation to contracts, especially given the flexibility that the cloud entails. Additionally, an alternative method of showback must be established, or a decision must be made not to consider these costs as cloud costs.

Omdat deze producten buiten Azure worden aangeschaft, kunnen de aanschaf- en gebruikskosten niet standaard worden opgenomen in FinOps-kostenrapporten. Dit onderstreept het belang van samenwerking met Software Asset Management (SAM), die nauwlettend moet bijhouden hoe licenties in de cloud worden gebruikt in relatie tot de contracten, vooral gezien de flexibiliteit die de cloud met zich meebrengt. Daarnaast zal er een alternatieve wijze van showback opgesteld moeten worden of besloten worden deze kosten niet als cloudkosten te zien.

Considerations for the choice of purchasingMethod

The most suitable method depends on various factors that need to be weighed against each other. Some considerations include:

• Existing Software Licenses: For organizations with previously purchased perpetual software licenses, it may be more efficient to implement them in the cloud than to acquire new licenses via the Marketplace or Microsoft.
• Product Availability: Not all products are directly available via Microsoft or the Marketplace, and not all on-premises licenses are suitable for cloud use.
• Multi-/Hybrid Cloud Usage: When simultaneously using the same products in multiple clouds, possibly combined with an on-premise environment, direct purchase may be a good option. This provides the opportunity to negotiate more favorable terms due to the larger combined volume from multiple clouds.
• Speed of Availability: Purchase through Azure/Marketplace generally results in faster availability than through a procurement process with the vendor. However, a private offer in the Marketplace may take more time than accepting a standard offer.
• Flexibility of Workloads: For flexible workloads, purchasing software/services through Microsoft Azure is often the most effective, as you only pay for actual usage. With direct purchase, flexibility may be more limited.
• Support: Depending on the model, support is provided by Microsoft or the vendor. Preferences may vary for each product and organization.
• Capex/Opex: Some organizations prefer buying perpetual licenses (Capex) over increasing cloud costs (Opex).
• Purchasing Power/Volume: For limited use, purchasing via the Marketplace may be more interesting, while for extensive use, taking time for negotiations on terms and prices may be more advantageous, as better price agreements can be made based on volume.
• Cloud Cost Reporting: Depending on the importance of including software costs in FinOps reports, this may play a role in the decision.
• Pricing: The various procurement models have different prices, billing models, and various ways to influence them

Recommended Approach

We recommend, as with any procurement process, clearly mapping the requirements for the above points in each specific case. This analysis will vary per organization and per product. Based on this, a well-considered decision can be made regarding the best approach to procurement and implementation. It is crucial that usage is continuously monitored, and choices are regularly reconsidered to ensure a flexible and cost-effective approach that aligns with the evolving needs of the organization.

Conclusion

In all procurement options, it is possible to influence costs. This can be achieved by using regular cost-saving methods such as commitments or through specific negotiations with a software vendor. It remains important to make a balanced decision considering all influencing factors and not just opting for the (lowest) price, highest discount, speed, or convenience.