Disclaimer: The purpose of this page is to give a high-level introduction to the different ways in which Gurobi can be deployed and licensed. It does not contain all license types with their pros and cons or provide any commercial information. The goal is really to explain what factors are important when it comes to choosing a license type. Make sure to work with a (Technical) Account Manager to learn all the details and make the right choice for your situation.
Concepts
In this document we use a few important concepts.
- Model: The mathematical description of a particular problem you want Gurobi to solve.
- API: The part of the Gurobi software that you interact with when you write your own application code. You call API functions to describe a model, to ask Gurobi to solve it and to retrieve the solution.
- Engine: The part of the Gurobi software that takes a model and finds the optimal solution. This part contains all the algorithms for mathematical optimization.
Architectures
To work with Gurobi, you will work with both the engine and the API. There are essentially three ways in which you can combine those two parts. Note that the way you work with the API and the algorithms used in the engine for solving your model, are the same for all options.
- In-process: Your code uses the API to define the model in-memory. As soon as you ask Gurobi to solve the model, the engine runs in the same process using the in-memory representation of the model.
- Client-server: You still use the API in your code. In parallel, you run the Gurobi Compute Server component as a separate process, typically in another machine or container. As soon as you ask to solve your model, the API automatically sends it to your Compute Server which hosts the engine. Once the solution is available, it is sent back through the API to your application code.
- Cloud: The above options all run completely on your own environment (either on-premise or in a cloud environment managed by you). The third option is to let us manage and run the engine for you in our AWS or Azure environments. Your application still uses the API, but as soon as you want to solve the model, it gets sent to Gurobi Instant Cloud. We make sure a machine of your choice is running to solve the model and return the solution. Under the hood, we use the same Compute Server technology.
Licensing mechanisms
The goal of licensing is to make sure Gurobi is being used in the way that was agreed contractually. This includes counting the number of concurrent usages of the same license. We offer various mechanisms for this.
- Machine-based: Your license will be "locked" to a particular machine as soon as you activate the license. It cannot be activated or used on another machine. The machine with the license is the machine where the engine will run.
- Token Server: Again the license is locked to a particular machine, but that machine will run the Gurobi Token Server. The engine can run on any machine (typically a different machine than the Token Server, or in a container). When the engine wants to solve a model, it needs to acquire a token from the Token Server which is responsible for counting concurrent usage. We also call this approach "floating use" and it works with containers too.
- Web License Service: Another possibility is that we manage the license and tokens for you in the cloud. You don't need to run a Token Server. Instead, the engine (which still runs in your environment) will connect to our online service for retrieving a token.
For Instant Cloud, there is no need for any of the above options since the Gurobi engine is managed by us.
How to choose?
The following factors should be taken into account when discussing license types.
- Flexibility: How many machines/containers will be running applications that need to use Gurobi? How often does the architecture change?
- Security: Will you be able to connect to external services like Instant Cloud or Web License Service or are there policies in place that prevent this?
- Expected performance: How quickly do your end users expect a result? Can they wait?
- Usage: How often will Gurobi solve a model? What does an average day look like? What is the expected peak usage?
- Performance: What are the typical runtimes for your models? Have you analyzed log files to consider parameters that may improve runtimes, or discussed this with the Gurobi team?
- Scaling: Do you need to be able to scale up your application independently from the Gurobi engine?
- Features: Do you need capabilities like queuing, priorities, authentication/authorization, asynchronous solving, dashboards and a REST API?
As you can see, the choice of a license type is not simply a matter of taste or price. Answers to the questions above should guide you towards the right architecture and license type. The Gurobi team is happy to discuss these topics and look at your models to determine the best choice for you.