Licensing is an important part of the design and implementation of your UrbanCode Deploy infrastructure. Ensuring that you can actually run deployments is the most obvious goal and reason for understanding and reviewing your licensing configurations. The second part of this is optimizing your runtime costs to support your growth and day to day operations. I will keep the sales aspects of this to a minimal but we understand that each license type has a different cost profile.

There are a few options for UCD license types:

• Server/Agent (Virtual Server and Managed Virtual Server)
• Managed capacity - aka IBM Processor Value Units (PVU)
• Simultaneous sessions ( Sessions or Token licensing)

This maps on to the UrbanCode Deploy deployment architecture of one or more central servers, and each managed endpoint running an UrbanCode Deploy Agent. As of 6.x there is no cost associated with running Agent Relays so while you will have infrastructure costs, there is no additional licensing cost for adding Agent Relays to your topology, which you should using if you are not already btw.

Buy or Rent

Another thing that may be interesting here is whether you are looking to purchase licenses perpetually and pay yearly support or lease software in yearly or multi-year increments. This has an significant effect on the capital investment and ongoing investment to keep the products supported and patched. IBM does not currently support increments less than a year, but it would not be surprising to see this model become available due to demand.

Server / Agent Licensing

The most common type and simple to understand is the Server/Agent model, in this model you buy a license for each server (Virtual Server) that you will be active, ( This includes any long standing environments there are currently no “non-production” type licenses. And then a license will be associated to each corresponding Agent that you are managing, this is a static licensing model as you license agents when they come online and they hold the license until you explicitly un-license that agent.

At deployment time, a licensed server is required to start a deployment, when a deployment starts all agents in the target Environment will perform an entitlement check before taking any process actions on that target machine.

This is the lowest cost option for getting started if you do not already have a significant IBM investment in Tokens that you can leverage. This model scales well to the first few thousand agents or to an environment with a high level of concurrency.

Simultaneous Session

The Simultaneous Session model is not immediately obvious, but this works like a standard floating license model the point of control is shifted from user/deployment to license based on the number of endpoints that are being utilized. Here the entry point cost is higher as this is a much more flexible solution, you can run as many servers and agents as you want, but you are now only able to run deployments that touch X number of endpoints. This model supports is the same from the end user perspective whether it is done contractually via Tokens or Simultaneous Session licenses.

The value proposition here is the increased flexibilty that this model provides, if you do the math this still ends up costing a bit more in a head to head comparison. However, when we look at the use of Simultaneous Sessions in the Token model, this involves a given Simultaneous Session License costing you X tokens from a pool of tokens that can be used for a number of licensed products. Thus you can consolidate your investment in a pool of tokens for products A through N. Thinking of a traditional software development lifecycle, iterative development, or follow the sun development we have different peaks in different tools so it is possible to use your shared pool of tokens to achieve a real savings based on the fact that you are probably not running all your tools at any one time. Think architecture, design, developing, build, code scanning, performance testing, deployment automation, release management, and service virtualization. These are all tool based capabilities that you probably use, and some go together but they are mostly exclusive based on where they are applied to a development artifact as it flows through your delivery pipeline.

Managed Capacity

I will start with if you don’t already know what PVU’s are, then this model is not for you. For those of you who do use PVUs today, this model works by measuring the number of PVUs that you will be managing deployments to via UrbanCode Deploy not the size of the UrbanCode Deploy server.

Conclusion

Knowledge is power here, so it is key to understand how the tool works, what your needs are, what your budget is. A more advanced topic than the mechanicals that may be of interest is looking at how to try and do a ROI/TCO analysis or a project savings type breakdown. In the case of automation cost savings tend to be 2-4x over estimated as we do not include the cost of change and implementation. So taking a pragmatic approach and an honest inspection of what you are capable of is the key to setting some realistic expectations. From here you can look at what models really do work for you.

For most clients starting out, the Server/Agent model is a solid starting point for the first 2-3 servers, and 1-2K agents. Once you grow beyond that size you may want to look at whether tokens or standard session model could provide you any savings or simplify your overall lifecycle license management.

Reference:

• UrbanCode Deploy 6.2.1 Information Center - Licensing Scenarios