What do serverless architectures mean for CMS?
Serverless architectures is a buzzword that is becoming more and more common in 2016. It's actually simply a continuation of the more mature micro services megatrend that has been taking hold within corporations as well as smaller companies.
Having a serverless architecture does not mean that your web service will run completely without a back end service and all in the browser. Rather it means that you do not develop a single backend service your self to support your client applications. You will pick and match a number of individual publicly available services to form the feature set that best suits your needs.
For Content Management Systems (CMS) this can include services such as user storage, login handling, content syndication, media management and content distribution. In classical monolithic CMSes like Drupal and WordPress all of these features have been accumulated into the core product - as built in features or modules and plugins.
The current crop of market leaders have some advances, but at their core they are still the same product as before. Developers have created integrations to external services these products and have embraced deployment to the cloud with Docker. But with the mentality of checking all the feature boxes they're from a different world from Serverless architectures, where a single service should do a single thing - and do it well.
Serverless architectures are a relatively new technology, with AWS Lambda being the market leader. AWS Lambda only offers APIs where clients can send a request and expect a result. The biggest difference with monolithic CMSes is that instead of the CMS being the integration point, this is increasingly done within the browser using Angular 2, React, Vue or other rich front end technologies.
A CMS should increasingly be positioned as a content repository with an API, instead of bloating them with eCommerce features and other non-core functionality. This will lead to less lock-in in a certain CMS technology and more freedom of moving between services. With proprietary REST interfaces increasingly being replaced by GraphQL to implement decoupled CMS solutions. SharePoint, for example, already recommends extending functionality using in-browser technologies like their Office Fabric React components
In short the previous domination of single large CMS tools as the hub for all operations will likely fade away in moving to individual services that can be replaced. The age of the almighty CMS is over as the browser becomes the integration platform.