Joseph Foran, Contributor
Software licensing, the bane of thousands of IT managers, just got more complicated. Managing how many users can access PeopleSoft or how many licenses of Windows 2008 R2 you need is straightforward: add the total up and write a check. But managing the number of licenses you need for a cloud deployment of your custom application? Not so easy.
Do you license by user? Do you license by processor? The complications are endless. There are some very basic license models that come into play when a cloud computing project is kicked off, and understanding these is crucial to the licensing success of a project.
The three basic license types are per-user, per-device and "enterprise." Paying per user is a tried-and-true method wherein a user is granted a license to use the application or server. This is subdivided into concurrent users and total users. A concurrent-user license simply means that you are licensed up to x number of users simultaneously. You can have 25 concurrent licenses and 2,500 users, but as long as only 25 people are using the system at one time, all is well. If the license is based on total users, 25,000 licenses are needed.
Per-device licenses vary widely. Again, there is the per-concurrent device and total device model, but there is also the "per processor" model, most often seen in databases and large applications. These licenses are given based on the total number of processors (or processor cores) present in a host system. You may have a SQL server, for example, with eight single-core processors serving up an application with 10 or 10,000 users, each accessing that database. In this case, you pay per processor in the host system.
Then there is the "enterprise" license, the all-you-can-eat smorgasbord of licensing. Whether you have 10 users, 10 devices, 10 thousand users or a million devices, an enterprise license can cover you. Of course, each of these licenses goes deeper. To put an application out to a user population inside a company, one must license the server operating systems, the applications, the databases and the end users, plus any development tools and middleware.
While complex, this is merely a math-game of knowing what model best supports the needs of the organization and those consuming the application. For example, deploying a SQL-based application via IIS to Windows 7-based users in a company of 300,000 employees is easy -- buy an enterprise license.
Licensing plus the cloud
Now add in the cloud. Dynamically increasing and decreasing the number of servers hosting an application to meet demand is great when it comes to uptime, reliability, stability and performance. But figuring out how to license this is a nightmare. What if an application scales from 10 servers to 300 servers because of a huge increase in demand, such as a retail store during the December holiday season?
How do you predict and license appropriately? The answer thus far has been simple -- use open source options like Linux servers, Apache, MySQL, Tomcat, Ruby on Rails...the list goes on. These tried-and-true stalwarts of the economically-challenged and deep-pocketed alike all have licensing costs equal to the number of Bugatti Veryons in the average person's home -- zero.
True, open source support costs are often just as high as with closed source, but support is a cost to be paid regardless of platform. When an application can't be built using open-source tools, however, there are frequently complications, and these complications are often severe enough to limit cloud computing projects to "low-hanging fruit" – i.e., projects that can be implemented using only free and open-source tools.
One option to deal with this complexity is to utilize the proper vendor. While most major cloud providers like Amazon and Rackspace allow for Windows-based servers and applications to exist in their clouds, running them there is often the wrong choice. The right choice, at least until Microsoft's cloud licensing models change, is to either run the application internally on specified platforms with known licensing information (forgoing the dynamics of growing/collapsing your cloud on-demand) or to use Microsoft's own cloud services, which have fixed prices for the applications most commonly used.
Making use of SQL Server in the cloud practically necessitates this, as it is impossible to tell just how many processors are being used in a cloud-based server. That sort of hardware information, while appearing to be readily available via typical administrative tools (Task Manager, System Information, etc.) is often completely deceiving. In a VMware environment, for example, your SQL server may be running in a virtual machine that shows one processor in Task Manager, but it may be running on an ESX/VSphere host with eight processors or more. While that can be controlled in-house with VMware's tools, that is not always the case with cloud providers. Using SQL Server via Microsoft's own cloud platform eliminates any questions about licensing those processors.
Working with open and closed source software
Keeping the free and open source software (FOSS) separate from the not-so-free and closed source makes systems easier to manage. While this is an easier way to deal with the complexities of licensing across the two major spheres of applications, there are also complexities that are more subtle and potentially more derailing to a project.
One such problem can occur when you have a "stack" that encompasses both FOSS and closed applications. An example of this would be a Linux server accessing an Oracle database serving information via an Apache/Tomcat server. Sounds fun, right? It gets worse. Many common platforms, such as Oracle's Real Application Cluster, are completely unsupported on cloud platforms like Amazon EC2 because of technical and licensing requirements. The database example above is actually one of the simplest, because the database can be kept anywhere where it is accessible to the application, including in-house. Having the application itself be elastic and closed source is an exercise in mathematics that can drive even a theoretical physicist to the bottle if the potential for periodic and explosive growth is there. Oracle itself is very clear on this topic:
"For the purposes of licensing Oracle programs in the cloud environment, customers are required to count each virtual core as equivalent to a physical core. This policy applies to all programs available on a processor metric.
When licensing Oracle programs with Standard Edition One or Standard Edition in the product name, the pricing is based on the size of the EC2 instances. EC2 instances with four or less virtual cores are counted as one socket, which is considered equivalent to a processor license. For EC2 instances with more than four virtual cores, every four virtual cores used (rounded up to the closest multiple of four) equate to a licensing requirement of one socket.
Under cloud computing, Oracle Database Standard Edition can only be licensed on EC2 instances up to 16 virtual cores.
Under cloud computing, Oracle Standard Edition One may only be licensed on EC2 instances up to eight virtual cores."
This means that if you spin up 10 database servers, you know what you pay. If you have a third-pary tool that will spin up more dynamically, you might not know until it's too late. And this brings us to the real dark side, as if any of these complex issues were a light-side -- the penalty for non-compliance. If an application is tightly locked around licensing, it may come to a screeching halt for some or all of the people who need to use that application when the license maximum is reached.
Take a Citrix XenApp installation with 100 users, for instance. When user 101 tries to log on, they are out of luck. If an application is limited to 10 installations, the 11th just won't spin up, no matter how dynamic or elastic the cloud behind it is. And then, since the cloud providers might be on the hook too, there is the very real possibility of dealing with the Business Software Alliance or another watchdog body about the licensing infractions. A $100,000 fine doesn't sit well with anyone, least of all the board of directors and other money-conscious members of a company.
Choice is the bread-and-butter of a good negotiator when it comes to complex enterprise contracts. It also entails accepting the possibility of having to live with difficult-to-fathom levels of license complexity that are not yet fully developed and "in the mainstream." As the market stands now, developing, running and licensing applications with a minimum amount of complexity is best done through open source tools like the LAMP stack or in an all-Microsoft environment in Azure. As these environments grow, and as customer needs change, so will the cloud licensing landscape. Until then, two maxims should be followed with zeal, the KISS principle and the classic caveat emptor.
ABOUT THE AUTHOR:
Joseph Foran is the director of IT at FSW, a Bridgeport, Connecticut nonprofit social-services agency. In his role as director, he is responsible for working with executive and line management to come up with cost-efficient uses of technology that will better enable client services, employee efficiency and increased grant revenue. Joseph serves on FSW's Leadership committee, where he advises and collaborates with company management on both technology and business decisions. FSW's services extend across Connecticut from six locations across the southwestern portion of the state.
Prior to FSW, Joseph was an IT manager at filtration manufacturer CUNO, Inc. and at sports league Major League Soccer, and he has been a systems admin with consumer goods giant Unilever, as well as a consultant for the State of CT's Dept. of Corrections, Dept. of Mental Health and Dept. of Education.
This was first published in April 2010