{"id":1765,"date":"2014-06-05T00:00:00","date_gmt":"2014-06-04T22:00:00","guid":{"rendered":"https:\/\/wwwneu.strehle.de\/tim\/weblog\/archives\/2014\/06\/05\/1724\/"},"modified":"2014-06-05T00:00:00","modified_gmt":"2014-06-04T22:00:00","slug":"1724","status":"publish","type":"post","link":"https:\/\/www.strehle.de\/tim\/weblog\/archives\/2014\/06\/05\/1724\/","title":{"rendered":"Cloud software, local files: A hybrid DAM approach"},"content":{"rendered":"

There\u2019s been two interesting articles on hybrid Digital Asset Management systems<\/strong> this week: Jeff Lawrence\u2019s Finding the Perfect Balance Between SaaS and In-House DAM<\/a>, and Ralph Windsor\u2019s Combining On-Premise And SaaS DAM Strategies<\/a>.<\/p>\n

I don\u2019t know which DAM products already work the way Jeff is describing \u2013 a \u201ctightly integrated hybrid DAM solution\u201d that keeps work in progress in a local system, pushing finished assets to a SaaS component for external distribution. [Update: Jeff says<\/a> \u201cPicturepark<\/a>, SCC<\/a>, Kaltura<\/a> and many others\u201d.]<\/em> I\u2019ve been thinking about hybrid DAM for quite a while from the developer\u2019s perspective. Here\u2019s an idea that I haven\u2019t gotten around to implementing yet (click to enlarge):<\/p>\n

\"Local<\/a><\/p>\n

The primary benefit of a hybrid DAM is fast internal file transfer because the files remain inside the local network. So let\u2019s assume the asset files (images, PDFs, videos etc.) are stored on a local server<\/strong>. That local server will also deliver the files via a simple Web server, and run minimal file processing software to be able to ingest files and accept uploads, create renditions and extract file metadata.<\/p>\n

The rest of the DAM software will run \u201cin the cloud\u201d<\/strong>: The user interface, metadata database and search engine index. When you\u2019ll run a search in the DAM UI, the system will know your files\u2019 URLs and point your Web browser to load them from the (fast) local network. (Just what image search engines on the Web are doing: They copy text and metadata into their index and provide the search interface, while the image files you\u2019re seeing are downloaded from the original servers.)<\/p>\n

Upload and ingestion<\/strong> will be a two-step process with the files going onto the local server, which then sends all metadata to the cloud DAM (to put it into its database and search engine index). Instructions for creating renditions (how many, how large) can be fetched from the cloud.<\/p>\n

We\u2019ll now have decoupled \u201csoftware as a service\u201d from \u201cstorage as a service\u201d<\/strong>: The storage, delivery and processing of files is cleanly separated from the DAM software, the metadata database and the search engine index. The latter \u2013 which require a lot more ongoing maintenance (software updates, search performance tuning etc.) \u2013 will nicely be dealt with by the DAM provider in their cloud. The local file server component can be installed relatively easy, or run from a pre-packaged virtual machine appliance or even a hardware offering (\u201cyour local DAM storage box\u201d).<\/p>\n

Now what about distribution of assets<\/strong> to the outside world which doesn\u2019t have access to your local network? If you expect low traffic, your local file server could be made available on the Internet and directly serve the files. Or files to be distributed could be copied to Internet-connected storage (in the DAM cloud or at any other storage provider). Maybe you\u2019ll just want to copy smaller renditions of the files into the cloud, and redirect download requests for large files to your local server.<\/p>\n

I\u2019d add a small component that keeps copies of the metadata records<\/strong> on the local server. If the Internet connection fails or the DAM cloud goes down, you\u2019ll be able to perform basic searches on your local server. (Or easily move to another DAM cloud provider since all the data is still under your control.)<\/p>\n

If you wanted to get really creative, imagine the local server software running directly on your Windows or Mac client computer. Asset files could remain on your hard disk, while the heavy DAM machinery runs in the cloud. Or the \u201clocal server\u201d would actually be running in a different cloud. With the protocol between DAM cloud and local server being open and well-documented, there could be multiple interoperable implementations. How about a distributed, \u201cpeer-to-peer\u201d DAM<\/strong> with many local servers contributing to the same DAM cloud instance?<\/p>\n

I\u2019m pretty sure someone\u2019s already doing this. Any pointers? [Update: Jason Wehling of NetXposure<\/a> writes that NetX can sync portions of the repository onto local drives or shares.]<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

There\u2019s been two interesting articles on hybrid Digital Asset Management systems this week: Jeff Lawrence\u2019s Finding the Perfect Balance Between SaaS and In-House DAM, and Ralph Windsor\u2019s Combining On-Premise And SaaS DAM Strategies. I don\u2019t know which DAM products already work the way Jeff is describing \u2013 a \u201ctightly integrated hybrid DAM solution\u201d that keeps […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_share_on_mastodon":"0"},"categories":[1],"tags":[],"class_list":["post-1765","post","type-post","status-publish","format-standard","hentry","category-weblog"],"share_on_mastodon":{"url":"","error":""},"_links":{"self":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts\/1765","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/comments?post=1765"}],"version-history":[{"count":0,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts\/1765\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/media?parent=1765"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/categories?post=1765"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/tags?post=1765"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}