How Microservices And Cloud Services Are Changing DAM
This feature article was contributed by Martin Wilson, founder of Asset Bank.
“Her husband works in software – something to do with microservices”. It was when I overheard a non-techie friend of mine saying this in a soft-play area that I realised microservices have become mainstream. Although technology trends come and go, it really does seem that cloud services and microservices are set to revolutionise software development. Today, any team considering the development or extension of anything but the simplest software application should be considering a microservices-based architecture. Whether they like it or not, that includes DAM vendors.
What is a microservice?
A microservice is a small, modular software program that exposes a (usually) REST interface enabling other applications to make use of its functionality. For a more detailed explanation I doubt I’ll do better than Martin Fowler in his 2014 article about microservices.
An application built using microservices typically consists of a front-end developed in JavaScript that runs in users’ browsers and talks directly to distributed microservices (sometimes via an application API), removing the single points of failure and bottlenecks usually associated with traditional monolithic applications.
What is a cloud service?
While microservices have been gaining traction with software architects, the number of third-party, cloud services has exploded, prompted by the convergence of a number of recent concepts: REST APIs, the cloud and the App Store. It is now possible for developers to pick and choose from a large set of existing pay-as-you-go cloud services and to start using them with a click of a button. Heroku’s Elements Marketplace and Amazon’s AWS Marketplace are good examples of this.
Technically, a particular cloud service just needs to expose an API and may be implemented using microservices or a monolithic application. However, in architectural terms it can be treated as a scalable, self-contained component, the inner workings of which are of no concern to the client applications using it — just like a microservice.
Will microservices be good for DAM?
DAM systems are software applications and so benefit from the general advantages of microservices-based architectures such as scalability and reliability (extra microservices can be spun up as needed), maintainability (they are cohesive, decoupled, independently deployed components) and reusability.
Reliability and scalability should be a given these days, and many monolithic applications manage these “abilities” well too. In theory, a well-designed monolith can also score highly for maintainability, although in practice many applications that start out architected well end up deteriorating over time, owing to developer turnover and pressure from sales to bolt on new features quickly. An alarming number of successful commercial applications are really big balls of mud but as an end user you often won’t know that. Instead you might notice that an application that used to be cutting edge now isn’t, as it struggles to evolve quickly enough to adapt to fast-changing requirements.
Reusability is where microservices are having a big impact, as they have started a trend for smaller front-end applications (usually JavaScript) that focus on specific business areas. Rather than one monolithic application catering to the needs of all users across many business domains, imagine a number of different applications sharing and using the microservices they need, each providing a user interface designed specifically to support a small number of business processes really well.
DAM commentators and some vendors have been talking for a while about the idea of moving beyond DAM applications to DAM platforms, which centralise an organisation’s digital assets and provide DAM-related services to other applications across the enterprise. Of course this is possible with monolithic applications (assuming they provide suitable APIs) but microservices have the advantage — they are designed for this approach.
DAM applications are dead. Long live applications.
Before long, the idea of buying a single DAM application will probably seem quaint. Instead, organisations will buy solutions that are plugged together to meet their exact needs, consisting of a number of microservices (DAM-related and otherwise) and multiple front-ends. The idea that an organisation’s DAM strategy should be based on a modular and process-oriented approach is not new (it was predicted by DAM News in this 2013 article about DAM Value Chains) and microservices could be the “how” we’ve been waiting for.
Does this mean everyone will need expensive custom solutions? Not at all — solutions will be built from out-of-the-box components with little or no programming. Obviously this requires a similar paradigm-shift to reusable components in the front-end as well as the back-end, but this is already happening with JavaScript libraries such as React. If an organisation’s requirements are just like everyone else’s then it can use pre-existing microservices and vanillia front-end applications. If its requirements are 80% standard and 20% bespoke then it can mix-and-match pre-built components with those custom-developed to meet its exact requirements.
That last scenario, a mix of standard and bespoke requirements, is typical in digital asset management (which seems to cover a large range of user requirements) and is one of the reasons there are so many out-of-the-box DAM solutions currently. Small-to-medium vendors can specialise in niche areas of DAM, and provide the combination of configurable software and consultancy that most organisations need to get the right solution. It is also a scenario for which the microservice architectural style is perfect.
What about existing DAM vendors?
Do cloud services and microservices spell the end of the fragmented DAM market? Probably, at least as we know it now. As pure microservice vendors move into the DAM space, the number of complete DAM solutions on offer will almost certainly reduce. Instead we are likely to see an increase in the number of microservice and cloud service vendors, each specialising in one or two functional areas where they will try to maintain their position as best-of-breed. Competition will be fierce, as the cost of switching microservices is relatively low.
Is this the beginning of the end for the hundreds of DAM vendors out there? That depends. In the short-term, I predict some vendors announcing (or keeping quiet about) a strategy for moving over to a microservice-based architecture, or at least refactoring their monolithic applications so they can meet the requirements of a DAM platform (effortless scalability, comprehensive APIs, specialised front-ends).
Longer-term, vendors wedded to their own software solutions will struggle as the pure microservice providers focus on DAM functionality, and also move into the user-facing market by providing vanilla and extendable front-ends.
However, the varied requirements of digital asset management are unlikely to go away and the enlightened companies (let’s not call them ‘vendors’ anymore) will view third-party microservices as extra tools they can use to help meet their clients’ needs. As Ralph Windsor has pointed out before, DAM companies are mostly systems integrators now. The trend to cloud services and microservices is likely to complete this transition.
One reason that small-to-medium companies have done so well in the DAM market is that providing an effective DAM solution is a mix of consultancy (finding out what a client needs), software (providing the right solution) and ongoing customer service. The big players often do all this badly, at least at a reasonable price point. Smaller companies will continue to thrive if they can focus on doing these activities well.
How far off is all this?
Go back a few years and most developers building a DAM solution would be using ImageMagick and FFmpeg for image and video conversions. It was a special kind of fun having to deal with missing dependencies, failed conversions and CPU-hogging processes, not to mention the time-consuming (and very much unfun) task of ensuring compliance with format patents.
Nowadays this functionality is available from tried-and-tested, scalable cloud services, either as pay-as-you-go hosted services or open source code you can host yourself (admittedly these probably also use ImageMagick and FFmpeg, but wrapped as microservices their shortcomings are much easier to manage).
The same can be said for search, cloud storage, delivery via CDN, SSO, and so on — many of the moving parts of a DAM solution are already available as cloud services, and most existing DAM applications will use at least some of those already.
Cloud services and microservices are already here and living among us. The real question is, when will they take over?
Author: Martin Wilson, founder of Asset Bank
Share this Article: