This is the final article of a four part series by AJ Witt of ITAM Review and Josh Brazee of Aspera. The series explores concepts & practical advice for managing Cloud deployments to minimise cost and risk whilst maximising value.
These articles are also available as a whitepaper, downloadable here (no registration required)
The previous articles in this series have outlined the scope of cloud optimisation, the business case for managing it, and provided an outline team structure for doing so. This article puts all that into practice by suggesting approaches to practical cloud optimisation for common service and application providers.
Cloud services are generally billable by relatively simple metrics – per user or per minute. These metrics are easily measured, and the vendor is able to bill you very accurately, simply because they have full visibility of your usage of their service.
This means that virtually all cloud services have public price lists, a number of service tiers, and, in the case of IaaS, perhaps hundreds of SKUs built around differing service levels of computing resources. In the case of AWS, the price list is so huge that Amazon provide an API to enable you to query it programmatically.
The scale of cloud offerings makes automation necessary. You need to find a way to process and understand the billing information you receive from these services monthly, which can’t be a manual process. As stated in part 3 of this series, your team may no longer require the detailed publisher-specific knowledge of license terms, but it will need people who are able to prioritise workload and get to grips with integrating & normalising this veritable firehose of billing information.
These are the general principles – integrate, normalise, prioritise and automate. In the next section we look at practical cloud optimisation in more detail for key vendors
Amazon Web Services (AWS) is a pioneer and dominates the public cloud IaaS market. What started as a way for Amazon to monetise systems that were only being used at peak times has grown into a huge ecosystem. AWS optimisation splits into two broad approaches – selecting the correct instance type and closing down un-utilised resources.
AWS started as a means to acquire powerful computing resources on a Pay-As-You-Go (PAYG) model. Over time this PAYG model has evolved to meet differing use cases, such as permanent deployments, non-critical computing resources, and Bring-Your-Own-License (BYOL). Each instance type charges a different price for what is effectively the same amount of computing power.
Reserved Instances provide predictable license costs for long-term deployments. If you know that you will be using a particular server for 3 years, committing to that spending via a Reserved Instance will save you money. Reserved Instances guarantee computing resources for a period of either 1 or 3 years. In exchange for your commitment, AWS will provide substantial discounts – perhaps up to 65% versus an unreserved on-demand instance.
The flip-side to Reserved Instances is Spot Instances. Spot instances are a Vickrey auction – an automated sealed-bid process where the winning bidder pays the second-best price. In this case, there is no commitment from AWS to provide you with any computing resource. If you don’t bid what you’re willing/able to pay you likely won’t win the auction, and your workload won’t run. This lack of commitment from AWS means that spot instances are the cheapest type of AWS resource – up to 80% cheaper than list price. The downside is that with no guaranteed compute available, they can’t be used for mission critical or production workloads. Amazon make Spot Instances available because they have to have capacity to cope with peak demand – for example month end, or Black Friday. For the days when demand is low, this capacity is still switched on, ensuring that Amazon will at least see some revenue. And they know that for many deployment scenarios a spot instance simply isn’t practical, so the risk of everyone buying spot instances is low. Furthermore, the greater the demand for spot instances, the higher the price.
Certain publishers enable you to make use of existing licenses in public cloud deployments. For example, Microsoft allow this for most of their server and application products. However, in order to benefit from this approach, existing license terms often require that you will have to purchase a Dedicated Instance. Dedicated Instances are physical hardware assigned to your company, and only your company. This ensures compliance with license reassignment rights for example – particularly for Microsoft software if you don’t already have Software Assurance-granted mobility rights. Dedicated Instances are the most expensive of all AWS general compute products. As such, BYOL probably makes little sense from a pricing perspective, particularly once you factor in compliance costs and the added complexity of deploying on-premises licenses in the cloud.
If you leave an instance switched on 24/7 for a whole month, you’ll be charged for 728 hours. But what if your AWS instances are only being used during business hours? If we assume that’s 8 hours per day, leaving instances permanently running increases your costs three-fold. Find a way to identify which instances can be turned off and work with your cloud team to ensure that they are switched off at the end of the working day.
Similarly, track usage of instances to determine whether they’re actually in use and providing business value. The VM sprawl that plagues on-premises datacenters still exists in public cloud deployments; the difference is that there is now a per-minute charge associated with it.
AWS has hundreds of instance types, each with their own allocation of computing power, memory, and storage space. Track the utilisation of these key metrics, and work with technical teams to shrink over-sized instances and reduce costs.
Much of the above section on AWS optimisation also applies to Microsoft Azure. Spot Instances in Azure are known as Low-Priority VMs, for example. However, Azure does include one significant benefit for Windows Server & SQL Server licensees – Azure Hybrid Benefit (AHB). AHB, formerly known as Azure Hybrid Use Benefit, can result in cost savings of around 40% for Windows Server & SQL Server. Perhaps to be expected, there are complexities associated with this approach, particularly around reassignment rights (90-day rule) and dual use. Even so, this could be a means to enable transition from on-prem workloads to Azure at a lower cost than expected.
Previous articles in this series have looked at the size of the SaaS market. The important takeaway is that many of the providers are the same companies that provided and continue to provide you with perpetually-licensed on-premises software. The market leader, for example, is Microsoft, and Adobe is also in the top 3. How do we go about optimising spend with these mega-publishers?
Opportunities for optimising Office 365 are two-fold. Firstly, look at overall usage stats. If a user has a subscription assigned but are showing no usage, investigate and potentially suspend/remove that subscription. If you’re in an EA, you won’t have the opportunity to true-down immediately, but at least you can put that subscription back “in stock” for allocation to new employees. If you’re buying O365 via Cloud Solutions Provider (CSP) – good news – you can true-down each month to remove unused subscriptions.
With unused subscriptions identified and optimised, the next step is to look at the assigned subscription level. This is somewhat more complex, not least because Office 365 has four subscription levels for Enterprise customers. How do you determine which subscription a user needs? Office 365 optimisation tools will provide this information by tracking usage of individual components.
Adobe was the first mainstream publisher to convert from perpetual licensing to SaaS subscriptions, starting in 2011. Optimisation for Creative Cloud is simple with effectively only two purchasing options to consider for most enterprises – Single App, or All Apps. Furthermore, it is relatively easy to track usage, and there is also the opportunity to get several weeks of free app usage by being mindful of your monthly proration date.
As a rule of thumb, if a user only requires a single app, buy a Single App subscription. If a user requires 2 or more applications, buy an All Apps subscription. That’s it. There are exceptions to this rule, particularly if one of the apps is Lightroom or Acrobat, but in general this holds true, particularly given that Adobe regularly discounts the All Apps bundle.
Furthermore, because Creative Cloud apps are installed locally, your existing SAM tools should be able to detect whether an application is being used. Creative Cloud subscriptions are always co-termed to an annual anniversary date so all you need to do is reconcile usage against assigned subscriptions around 2 months prior to the renewal, and only renew the subscriptions you require. You don’t even need to uninstall the software if the user’s subscription has been removed, because it will be automatically deactivated by Creative Cloud’s licensing server.
For those seeking to squeeze even more cost savings from Creative Cloud, it may also be worthwhile paying attention to the monthly proration date. By doing so, and timing your purchases, you can get almost your entire first month subscription for free.
Your proration date is the day of the month that you took out your original agreement. For example, if your annual anniversary date is May 16th, your proration date is the 16th of each calendar month. You only pay complete months for a CC subscription, so in the above example if you purchase licenses on the 1st of the month, you only start paying for them from the 16th, meaning you get 15 days of free access to the applications.
To maximise these savings, aim to purchase your first Creative Cloud subscription (which sets your anniversary and proration date) on the 29th of the month. Buying a single subscription will set this date for the duration of your agreement. If you then purchase further licenses the following day, you’ll get almost a month of free usage for those licenses, because you won’t be billed until the 29th of the following month. It’s a small savings – an All Apps subscription costs around £2 per user per day – but requires no effort other than instructing your purchasing team to submit new orders the day after your anniversary & proration date.
Salesforce effectively invented the Software-as-a-Service business model. By doing so, and by being hugely successful (at least 15% revenue growth per annum year on year since day 1), they have revolutionised how software publishers do business.
As with other services, your optimisation opportunities around Salesforce are in getting your users on to the correct level subscription and recycling dormant subscriptions. For Salesforce licensing, the elevator only goes up – there is no possibility to true down – so it is important to only buy new licenses when it is absolutely necessary. Salesforce optimisation is complex, but fortunately they provide the ability to integrate external toolsets. These toolsets to varying degrees can suggest potential optimisations, baseline your usage, and provide cost forecasts.
This article has highlighted a number of optimisation opportunities for managing your cloud spend and avoiding cloud shock. This is an emerging area of opportunity for ITAM professionals, and it is notable that solutions are often not integrated. You may find that you will need more than one solution to manage your entire public cloud spend. This in turn means that the optimum approach from a reporting and governance perspective is to have a core ITAM toolset that is extensible and can integrate data from multiple sources to provide a single view of your estate.