Now that we have our SQL server licensing models laid out, we can move onto the next level of complication: Editions. Microsoft first deploy SQL Server Express to see if it is sufficient for their specific applications and will only move to the fee-based editions when they can confirm that Express will not meet their requirements.
Developer: This edition allows you to build, test, and demonstrate applications in a non-production environment. It is important that the ‘non-production’ element is upheld in this edition, since using the developer edition on anything that is full production can result in heavy fines. A piece of software will be considered in production if individuals, either inside or outside of the organization, use the software for any reason beyond development, including evaluation acceptance testing such as a review of the application before it is put into general use.
A SQL server will also be considered in production if it is connected to another database that is in production or runs as a backup or to provide disaster-recovery to a SQL server in production. As you can probably imagine, mixing production and non-production environments is a recipe for disaster, as this can cause hyper complexity and compliance issues, especially if access controls are not established that prohibits use outside of development and testing. There are a few ways to counteract this problem:
- Use naming conventions for SQL Server instances to explicitly state if a Server is in development or in testing.
- Install the SQL server on a separate network segment or cloud environment to lower the chance of unauthorized interaction.
- Require that installs be developer-specific editions.
The main challenge with these editions is proving which edition you have. For example, if you are in a software audit, unless provided with evidence that proves otherwise, the software auditors will assume that you only have Enterprise editions, which are the most expensive. Proving which editions, you have could mean the difference between owing hundreds of thousands of dollars and owing nothing.
Licensing for Development Environments
While Development and Express environments can be great in saving you money, in testing and demonstrating your software before deployment, it is important that these scenarios are licensed properly and that you understand their limitations. There are two types of SQL Server Development licenses:
Developer-Specific Licenses: Used primarily for debugging, designing, development, testing and demonstrating purposes. This license is for non-production use only and is often purchased when programmers, professional testers, technical writers, database professionals, or IT administrators are involved. Developer specific licenses are assigned on a per-user basis, in which Users can install and access an unlimited number of SQL Server instances and share those instances only with other users who have been assigned the same type of developer-specific user licenses.
That means, for this licensing model, if anyone wishing to access a development environment requires a developer-specific license, even for tasks as hands-off as administrative purposes. The only exception to this is user acceptance testing. Installations can be set up and taken down at any time and can be placed on desktops, dedicated servers, shared servers, and cloud environments. Some potentially less expensive alternatives to this license include the following:
- Purchasing new production licenses
- Cloud-based services like Windows Azure, which are usually based on a monthly subscription model (if you have an MSDN subscription, it includes Windows Azure credits, discounted rates and the ability to use MSDN software at no additional charge)
- Free editions like SQL Server Express and the SQL Server Compact (a free embedded edition of SQL specifically for developers)
</div class=”listbox”>Evaluation Licenses: Used to assess the software for potential business use. Again, only used for non-production environments but it is not often used in development and test environments. Usually comes with an expiration date (60-180 days to evaluate the use of the software) when obtained through volume license contracts.
Licensing Virtualized Environments
It is possible and necessary to license virtualized environments, and you have the ability to cover your VMs under your Enterprise + Software Assurance addition licensing model if you have one. This will cover all the VMs that your software environment will ever see, which comes in handy since VMs are so easily and quickly cloned and installed.
However, it is terribly important to consult with your Microsoft Rep to ask if virtualized environments can be properly covered by your software assurance as you don’t want to run the risk of facing any compliance issues with Microsoft. You will need a license for every virtual core that you have.
Licensing your Virtual Environment all depends on the licensing model you choose, with the per core model proving much more cost-effective for many clients. If you aim to license the Virtual Cores on Virtual Operating System Environments (OSE), then you will need a minimum of four licenses per processor if you have more than four cores on each of your virtual processors, then you’ll need to calculate what you’ll need based on the number of cores. If your OSE is mapped to different pieces of hardware, you’ll need additional licenses for anything the OSE is touching.
