Most of us can say there’s no debate about whether video surveillance data should be cloud-based… of course, it should be. More specifically, it should be cloud object storage based. However, putting that into practice hasn’t always been easy.
There’s the accessibility issue. Users located anywhere should be able to access data easily. It’s that simple.
There’s the security issue. Organizations should have control over who has access to their data when it’s in the cloud.
Then there’s the performance issue. This is a huge one. If I put my data on storage … whether it’s in the cloud or not, I don’t want to hear something short of a horror story about how it’s going to be when I try to access it.
With video surveillance, cameras generate data … a lot of data. With economical cloud object storage such as Microsoft’s Azure Blob, Amazon’s S3, Google Cloud, and others, scalability becomes virtually unlimited. Add in the unmatched economics, and anyone would want to use cloud object storage!
But what about accessibility?
Enter LucidLink’s Filespaces.
LucidLink places a cloud-native distributed file system on object storage. This file system provides all the functionality of a file system that one would expect, such as global file locking, support for file system permissions on the local client OS, and availability of the cloud storage via a folder or drive letter on the client machine. In regard to the client machines, there’s no gateway appliance, server, etc., involved … simply, the LucidLink client software is installed on the Windows, Linux, or macOS machines in your distributed environment and voila! That’s it—instant access to the cloud object storage platform of choice.
But what about security?
LucidLink provides a “Zero-Knowledge” security model where only the customer has the encryption key. At no point does LucidLink or the cloud storage provider have the encryption key, so they never have access to the data. Data is encrypted at AES 256 in the LucidLink client’s cache, in-flight, and at rest. Additionally, users can be created and given RO and RW permissions to folders in the LucidLink Filespace.
I’m just up-front here, but it’s obvious that placing data in the cloud with LucidLink is more secure than buying a local storage appliance and putting your data on that appliance. Remember, a storage box’s encryption-at-rest option is not a substitution for LucidLink’s Zero-Knowledge security model.
But … but … what about performance?
Yes, we’re talking about video data here, and the performance must be there to deliver that video data on-demand … with no excuses.
LucidLink is not sync-and-share technology, nor is it some type of gateway appliance technology. With LucidLink, you stream the data bits on-demand to and from the client and storage platform over multiple channels while leveraging read prefetch technology and local disk caching. Only metadata is synced across the clients, not the actual data.
Every Thursday, we host live LucidLink demos. BTW: You can register for these demos here. I regularly take part in delivering these live demos, and what I love to show is this … I take a 20GB video file on a Linux machine and upload it to a LucidLink Filespace with Amazon S3 as the cloud object storage repository. While that file is uploading, I go to a Windows machine and open that same video file whose data is in S3 AND where the upload is still in progress … and open it. It opens with a video time length that equates to the amount of data that has been uploaded to that point. I demonstrate that I can easily scroll to different points in the movie. I close that window and open the video file again, and this time I have more of the movie available for viewing. At no time was it necessary to download the file in order to view it, and I was able to watch the video before it was fully uploaded from another client machine!
Isn’t this what we all want from a storage solution for video surveillance data?
Of course, it is! With LucidLink, a cloud object storage solution is now the preferred storage solution for video surveillance data.