Embedded server and ISV licensing questions

[urbanhusky]

Hi,

we're considering integrating RavenDB into our customer's application. The only real option for us would be to run it embedded within the context of our other services (we cannot deploy or maintain independent servers).
This makes the ISV licensing pretty much the only viable option, however I've got a few questions before heading further down this path:

• Can an ISV embedded license expire and what effects would this have on the servers in production?
• This is less about what happens if we don't renew the license - but rather about if we would have to deploy a new license to all instances in time (which might be next to impossible in our specific case)
  
• What options do we have available to secure access to the embedded server?
• I ask because we might run RavenDB in a CQRS setup, where we might split writing (from event sourced projections) and reading into separate services. I.e. we might need to connect other processes to the embedded instance
• From what I can tell, I could use UseEmbeddedHttpServer and connect from the other processes, but we still would have to restrict access to the other service user.
• Can we manage the authorisation/authentication at runtime from code? How does this affect access through the embedded document store directly (i.e. is it connecting as the windows user that the embedded service is running as)?
• In short: I'm afraid that I might lock us out of the embedded instance, if we restrict access to a specific user or group and later change membership of the service that is hosting the embedded instance.
• We don't really control this environment (i.e. operations is outside of our control)
  

[Oren Eini (Ayende Rahien)]

Inline

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

On Mon, Jun 27, 2016 at 11:58 AM, urbanhusky <thomas.mu...@gmail.com> wrote:

Hi,

we're considering integrating RavenDB into our customer's application. The only real option for us would be to run it embedded within the context of our other services (we cannot deploy or maintain independent servers).
This makes the ISV licensing pretty much the only viable option, however I've got a few questions before heading further down this path:

• Can an ISV embedded license expire and what effects would this have on the servers in production?
• This is less about what happens if we don't renew the license - but rather about if we would have to deploy a new license to all instances in time (which might be next to impossible in our specific case)
  

You cannot deploy new instances to production with an expired license.

Existing instances will continue to work, and by default, will fetch the new license from the license server automatically.

 

• What options do we have available to secure access to the embedded server?
• I ask because we might run RavenDB in a CQRS setup, where we might split writing (from event sourced projections) and reading into separate services. I.e. we might need to connect other processes to the embedded instance

You can use API Keys in ISV, which allows you fine grain control. 

• From what I can tell, I could use UseEmbeddedHttpServer and connect from the other processes, but we still would have to restrict access to the other service user.

You can also use Windows Auth and limit to specific users, but API keys is probably easier. 

• Can we manage the authorisation/authentication at runtime from code? How does this affect access through the embedded document store directly (i.e. is it connecting as the windows user that the embedded service is running as)?
• In short: I'm afraid that I might lock us out of the embedded instance, if we restrict access to a specific user or group and later change membership of the service that is hosting the embedded instance.

That is why API Keys are better, you aren't limited in this fashion.

Note that when using the embedded option, there is no security, and you can modify the authentication directly. 

• We don't really control this environment (i.e. operations is outside of our control)
  

--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[urbanhusky]

You cannot deploy new instances to production with an expired license.

Existing instances will continue to work, and by default, will fetch the new license from the license server automatically.

Do the ISV embedded instances need an internet connection? Or what do you mean with license server?
Also, what exactly do you mean with deploy? For example, I'd like to embed Raven into a Windows Service. This service might get restarted sometimes...

Note that when using the embedded option, there is no security, and you can modify the authentication directly. 

I'm only considering ISV embedded at this point. So you're saying that it is not designed with any authentication and I could not (reasonably) connect to it from another process?

[urbanhusky]

To put this into context, this is our scenario:

• 150 manufacturing plants all over the world, partially with very intermittent internet connection (if at all?)
• Each plant has their own servers and network infrastructure; operations is managed on site by local teams
• We cannot deploy additional services outside of our own, because this means that the prerequisites (such as Java, Erlang etc.) must be installed and configured in each plant.
• I.e. we have to bundle any dependency within our application
• Some servers host services for multiple tenants (multiple installations of the same application)...
• Some plants might only occasionally update to the latest version (we can't push centrally for various reasons such as: internet, testing, plant-specific processes etc.)
  

With this number of plants and operations requirements, it is not feasible to deploy individual services next to our application.
This leaves only those options where we can run and host our dependencies directly from within our application.

...and "we" is actually two companies: the customer with the plants and infrastructure and the software developers. So even more licensing weirdness that hits us... (the software is only developed for that customer specifically and not sold or distributed otherwise, pure in-house use only)

[Oren Eini (Ayende Rahien)]

Inline

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

On Mon, Jun 27, 2016 at 3:52 PM, urbanhusky <thomas.mu...@gmail.com> wrote:

You cannot deploy new instances to production with an expired license.

Existing instances will continue to work, and by default, will fetch the new license from the license server automatically.

Do the ISV embedded instances need an internet connection? Or what do you mean with license server?

Preferred that they do, but not required. On first start, if they don't have access to the internet, they do require a valid license.

 

Also, what exactly do you mean with deploy? For example, I'd like to embed Raven into a Windows Service. This service might get restarted sometimes...

Very first time that the Windows server starts.

 

Note that when using the embedded option, there is no security, and you can modify the authentication directly. 

I'm only considering ISV embedded at this point. So you're saying that it is not designed with any authentication and I could not (reasonably) connect to it from another process?

Yes, if you are using ISV embedded, then you are only connecting to it from the same process.

You can connect to the studio for looking at things, but it won't work for remote apps trying to connect to it.

[Oren Eini (Ayende Rahien)]

Yes, that would match ISV Embedded scenario

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

--

[urbanhusky]

How is it determined, that the service was started for the first time? What happens if I replace the executable of our service (i.e. update)?

[Oren Eini (Ayende Rahien)]

If the database already exists.

[urbanhusky]

Okay, that puts me a bit at ease. I was worried for a second there that we might face outages in production...
The ISV Server is just plain, installable, standalone RavenDB?

[Oren Eini (Ayende Rahien)]

Yes, same logic with regards to deployment as embedded.

[urbanhusky]

I'm sorry but I don't follow?
I thought the ISV Server is more like the regular RavenDB server?

How does the online activation work? Is that something that we have to host, or is the license checked against your servers?
The license is otherwise just a file, or a configuration setting (which can be set through the application configuration file), correct?
The file/string license has an expiration baked into it?

Consider the following scenarios:
We distributed the application, which was built with a license that expires in 1 month. This application went through tests in a plant and will be deployed for the first time.

Scenario 1: The installation and start of the service happens while the included license is still valid. This should work fine, even if the plant is currently offline? Any further updates, even from expired licenses, should work, as long as the database still exists (i.e. backups are even more important)?

Scenario 2: The actual deployment to production happens just as the license expires (or maybe they rolled back to an older version which has an expired license). We extended the licensing however for yet another year but have not yet built and delivered a new version. What happens now?

Scenario 3: A new deployment is added on the same server for a new tenant. This causes a new database to be installed - so this is similar to Scenario 2.

[Oren Eini (Ayende Rahien)]

inline

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

On Tue, Jun 28, 2016 at 10:22 AM, urbanhusky <thomas.mu...@gmail.com> wrote:

I'm sorry but I don't follow?
I thought the ISV Server is more like the regular RavenDB server?

Yes, it is. 

How does the online activation work? Is that something that we have to host, or is the license checked against your servers?

On first deploy, the license needs to be valid (or internet connection to validate the license).

 

The license is otherwise just a file, or a configuration setting (which can be set through the application configuration file), correct?

Correct.

 

The file/string license has an expiration baked into it?

Correct.

 

Consider the following scenarios:
We distributed the application, which was built with a license that expires in 1 month. This application went through tests in a plant and will be deployed for the first time.

Scenario 1: The installation and start of the service happens while the included license is still valid. This should work fine, even if the plant is currently offline? Any further updates, even from expired licenses, should work, as long as the database still exists (i.e. backups are even more important)?

Correct. 

 

Scenario 2: The actual deployment to production happens just as the license expires (or maybe they rolled back to an older version which has an expired license). We extended the licensing however for yet another year but have not yet built and delivered a new version. What happens now?

You need to get the updated license to the software, either by allowing internet connection, or updating the license file we sent you.

 

Scenario 3: A new deployment is added on the same server for a new tenant. This causes a new database to be installed - so this is similar to Scenario 2.

This is per server, not per database.

[urbanhusky]

Thank you for your help so far :)

I still don't fully understand how the license can be verified online.
I assume that the online license check is made based on the license that the server has available locally. This should pass, even if the local license expired - i.e. the online license verification knows that license X expired, but that it has been renewed as license Y? I mean there has to be some benefit from online license checks in comparison to checking the license file locally.
In short: an embedded server with a local but expired license would still start (initial start), if it can connect online and the license has been renewed?

Also, when I said "server" in Scenario 3, I meant "machine". I.e. we actually end up deploying the application multiple times on the same machine. We separate tenants on the process and filesystem level.
For example, we might have "ApplicationServer tenantA" and "ApplicationServer tenantB" services running (each having their own embedded Raven instance).

I assume that, in this scenario, any additional instances would require a license check before they start for the first time.

[Oren Eini (Ayende Rahien)]

inline

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

On Tue, Jun 28, 2016 at 11:17 AM, urbanhusky <thomas.mu...@gmail.com> wrote:

Thank you for your help so far :)

I still don't fully understand how the license can be verified online.
I assume that the online license check is made based on the license that the server has available locally. This should pass, even if the local license expired - i.e. the online license verification knows that license X expired, but that it has been renewed as license Y?

Yes, the server by default will check licensing.ravendb.net to see that the license is valid, even if it expired.

 

I mean there has to be some benefit from online license checks in comparison to checking the license file locally.

It allows an "expired" license that was update to remain in effect.

 

In short: an embedded server with a local but expired license would still start (initial start), if it can connect online and the license has been renewed?

Yes.

 

Also, when I said "server" in Scenario 3, I meant "machine". I.e. we actually end up deploying the application multiple times on the same machine. We separate tenants on the process and filesystem level.

From our perspective, a server is a RavenDB process (more specifically, the system database is used to determine when a new server is deployed).

 

For example, we might have "ApplicationServer tenantA" and "ApplicationServer tenantB" services running (each having their own embedded Raven instance).

Then they are separate instances and considered deployed