One of the largest challenges facing technical leaders in business is keeping a high velocity of change in order to adapt to the future customer needs; let alone keeping up.
Before microservices became easier to implement, deploy, and scale, you might look at an investment in a platform to have a finite lifespan. A platform would be purchased, customized, and deployed across a business with the view to maintain and extend over the coming business cycles in order to be superseded by a new platform to be migrated to in the future. This migration will usually take up the better part of one or two years, from requirement planning through to execution, at which point the platform ends up relatively stationary with difficulties eventually due to technical debt and features which are superseded in other places. This cycle has repeated for a long time and is mainly due to having the approach of tying up as much as possible within the same platform. Moving to a new platform is always a huge step and complex.
Traditional Monolithic Platform Challenges
There are many well-trodden challenges with this setup, mostly around when time comes to re-platform the process, which is expensive, disruptive to the business, and the end-user. It provides a distraction at a time when the old platform can be seen as good enough. See all the challenges that Magento has in migrating customers off Magento 1 to Magento 2, with push back from retailers who see the existing platform as good enough—a full migration is not desirable at all.
Another large challenge is the amount of technical debt the business will be saddled up with overtime. The monolithic platforms will, at one stage, be running optimally with all the various integrated elements being used. Over time, however, the platform will get extended, functions will be migrated to another better platform— for example a CMS. However, the original functionality is still there in the legacy monolithic platform.
Adding testing into a monolithic platform comes with its own challenges and will inevitably add to the time to get new features and experiences to market
All this leads over time to slower development and longer time to go live for future work. Teams end up with items that might not talk to each other correctly, features which when extended break other features. In these cases, I have seen focus switch to better test coverage as teams look to improve quality. Usually at the call of why do so many issues end up regressing other features. Adding testing into a monolithic platform comes with its own challenges and will inevitably add to the time to get new features and experiences to market.
With microservices and a headless setup, the leaders of the pack are able to wrestle back reins to get an increase in velocity as each microservice can be independently built, scaled, tested, and deployed. Teams can form around competency with the correct tool for each job to be used.
There is also no more compromise for a business or tech leader. If you see a market-leading CMS which has a better fit for your business, then you use it. You want a new PIM, then great, use it and integrate it with the rest of the stack. As each service is isolated from each other, making changes to one, will not necessarily affect the others.
At Adore Beauty, we spent six months taking out elements piece by piece, re-implementing them with a microservices approach while keeping the items which were performing well. For example, Solr is a crazy fast way to retrieve data for our product page, this was exposed by an API microservice we built and our Vue JS website can now render product pages in split seconds all while being scalable and secure with no loss of functionality to customers.
What is Headless Specifically?
Being headless, the presentation layer—the website for example—is separated from the data via an API layer. The API will pull information from varying sources and present it to the presentation layer. The added benefit for this is that getting data out of silos and fully integrated is simple. If you want to present content managed articles with embedded products all together, this is, in fact, simple and straightforward. The API has access to both, stitches them together—either when the content is written or at the point of request, like in an instance where pulling the top products from a category that is being written about.
Along with the extra functionality and flexibility, the largest benefit for Adore Beauty as a retailer is speed. Our modern Vue JS in the front end simply consumes API calls (or a JAM Stack to be more technical) is lightning quick compared with our previous site.
So yes, you can have it all but it takes a complete shift in thinking as well as adding new skills such as DevOps to the mix, however, it is absolutely worth it in the long run.