When running a deployment of Openvidu Pro, it requires an open outbound port to send requests to an openvidu licence service. I’ve just got a couple of questions surrounding its use:
What information is sent from the deployed clusters to Openvidu and does it include anything other than the licence key validation (secret key, available cores)? If so what is the information that is sent?
What happens to the cluster when the licence service is unavailable (downtime etc)? Would all deployed Openvidu clusters stop functioning due to the licence key information not being able validated?
Only the amount of minutes and number of cores of each node (of course along the license key) is sent to the license check system. No other information is sent.
If the license check fails, OpenVidu Server Pro will shutdown. It does not punish right away: OpenVidu Pro has a “trust” algorithm that will allow more license check failures due to a unexpected network drop, that increases as OpenVidu Server Pro keeps up and running. Either way, this scenario is only necessary for OpenVidu Pro clusters deployed in private networks for users inside that same private network. Because OpenVidu Pro will require Internet access if any user wants to connect from the outside, and if in this case OpenVidu network drops, then your media streams will be destroyed anyway.
Thanks for the quick response. Just to confirm for a Openvidu Pro distribution that caters for client connections over the public internet (not contained in a private network), if there is any problem with the licence service responding the cluster will shutdown and be non-restartable. Meaning that any deployment of an Openvidu Pro cluster relies on the external licence service staying available - if that service has downtime for any non-trivial length of time (1+ hours for example) all Openvidu Pro deployments that are not inside private networks will also be taken offline?
Is there any SLA available to cover the event of Openvidu as it will mean the full loss of service to “pro” account customers?
Of course, if the external service fails for a long enough time, OpenVidu Pro clusters would shut down. This is all internal, non-publicly available information, but just to let you know: the license check system is implemented as serverless services deployed in AWS, with a backup solution ready in case something fails. We have a health check system always running and in case of a long failure in Amazon (which of course I haven’t seen not even once) the trust system in OpenVidu Server Pro would protect the running clusters for a while.
In the end, OpenVidu license check system won’t fail unless something really bad happens. But any other PaaS streaming services (Twilio, Tokbox, Temasys…) has the exact same problem. If the entire Internet shuts down, there are is not much we (or others) can do.
I think the main difference here is that with full PaaS providers (Tokbox, Twilio) you are provided with a standard of service agreement and are not maintaining your own deployments but run the risk of out-of-your-control downtime (but for a lower cost per month).
One of the reasons to pick Openvidu Pro over the pre-mentioned providers is for more control and protection over areas like downtime. Taking on the cost of maintaining your own video service is balanced by the fact that if something goes wrong be it AWS regional failure, AZ failure etc, we can engineer our deployment to recover from it.
My issue with the above is that with an external licence service (be it serverless or not) we lose the full control over any outages, and without any service guarantees it seems there is a bit of a trust relationship that Openvidu also have the same level AWS fault tolerant deployment (serverless is still effected by S3, compute, cloudfront, etc failures). Bottom line - Openvidu forgets to pay their AWS bill, anyone running a Pro deployment will be taken offline.
Correct me if I’m completely wrong here but if we wanted to run a deployment of Openvidu which is free from dependent Openvidu services I’m best to use the CE version and configure my own scaling behaviour & log aggregation tools? I think the Pro version does hold some value offering these extra solutions out of the box, but I’m struggling to balance this against the risk of an “out of our control” service outage.
Of course we work very hard to guarantee our Pro users that no service outage ever occurs. Again, that would be an extremely rare thing to happen. Basically for it to happen Amazon Web Services should fail at a great scale as it has never failed before. If that’s a concern to you, I cannot really tell you other thing that it is our priority that this possibility will not ever affect the users.
But of course, OpenVidu CE is open source and free to use and modify as you please. You can do whatever you want with its source code and if you want to implement your own scalability logic on top of it, you can.
Thanks again for the reply. I agree AWS failures these days are fortunately rare, last full regional failure was a couple of years ago I think but they do still happen. It does sound like the CE version will be a better fit for our needs for now, if in the future a version of Pro without the external dependencies is available we can go back to using a paid for version with the extra solutions.
Many thanks for for providing the extra information in the thread about the licence service, it’s been a great help.