In the Valley of the Cloud the License Manager is King
I’ve just returned from Dublin, where I had the privilege of presenting a session at the ITAMOrg 2019 conference. My focus was specifically around a topic that not many people, from what I see around the industry, are talking about. Yes, there are many posts about controlling costs in the cloud, largely centred on consumption of Virtual Machines (VMs) on Microsoft Azure and Amazon Web Services (AWS) platforms amongst others, and optimising contracts and costs with Software as a Service (SaaS) applications. Consultancies host webinars on managing your cloud costs and it is a frequent conference topic; but you rarely see mentions of the one acronym that can cause you all sorts of problems if you are not careful – BYOSL (aka Bring Your Own Software License).
Datacentre or cloud?
In the rush to migrate workloads to public cloud platforms, thereby reducing on-premise costs with respect to hardware and managed service implementations, licensing is a frequently overlooked side issue. Over the last year, I presented at three conferences on the topic of ensuring your Software asset Management (SAM) process is aligned to datacentre change. Whilst the word datacentre was in the title, I repeatedly stressed that this process should also include public cloud platforms. After all, isn’t cloud just someone else’s datacentre?
Allowed and to what terms?
Let’s assume you are migrating a business application workload to an Infrastructure as a Service (IaaS) platform and you intend to continue using your on-premise licences. You will consider the technical impacts of the migration and look at the costs associated with running the VMs you believe you will need to support the application. But do you actually investigate the licence implications? You really should. Every major vendor will have a change of terms around the usage of their products in public cloud. In general the vendors will allow you to deploy software to certain cloud platforms. But some terms of certain vendors change radically.
Software Vendor Cloud Policy
Take Oracle, for example. Students of Oracle licensing practices will know that the vendor’s Partitioning Policy and the way it targets VMware virtual platforms can cause much pain to customers, and many will bear the battle scars. Some time ago, Oracle introduced their “Authorised Cloud Policy”. Once they understood that many customers wanted to shift their licensing in to public cloud (and not necessarily Oracle’s at that!), they introduced a mechanism to make it easier for customers to calculate the correct number of processor licences required to support an Oracle Database Enterprise implementation on, for example, Microsoft Azure VMs. That said, this policy only applies to three (yes, three!) IaaS platform types, two of which are provided by Amazon Web Services (EC2 and RDS) whereas the other is Microsoft Azure.
Platform of choice
What if you want to deploy to a different public cloud? You are free to do so – in this context, use of the word “Authorised” does not mean that Oracle only sanctions usage on those three platforms. It means they are the only ones where you can use the Oracle special cloud processor calculation for licensing. What that effectively does mandate, however, is that you must treat other cloud provider platforms as you would (your own) on-premise datacentres. If your provider runs their platform using a major virtualisation technology like vSphere, you would have to apply Oracle licences in the same way as you would in your own datacentre, thereby losing some of the benefit of deploying in this way.
By now you should hopefully see why it is critical to engage your licence manager or consultant. A full analysis is required and an understanding of the licence impact of shifting licence X to platform Z is critical. Make sure you understand what reporting is available from your cloud provider and what data they will give you about the underlying technology. Check your vendor’s contract terms and cloud policies to see whether your provider is an “approved” partner. Negotiate any special terms into the provider contract to get the reports you need before you sign it. Understand your reporting obligations in the event of a vendor audit. Finally and most importantly, don’t just migrate the licences and assume everything will be OK.