Microservices and me
Time to market is important to you, and you can see the benefit from releasing frequently without causing pain to your customers, but how do you do that with your e-commerce platform?
Most of the enterprise e-commerce solutions being used are based on 20 year old technology, their systems were written to process everything in one place with a large amount of interdependency. It is very hard to gain the kind of speed you need in today’s environment when you are shackled to one of these monoliths.
Microservices
Microservices are an architecture in which the application is composed of small, independent services. Each individually developed and deployed and exposed to the client through APIs. This solves the problem of the monolith, by breaking the business logic out of a single system, and into individual elements that only care about their own role.
By taking this approach, you no longer need to release the whole system to upgrade one piece of functionality. Developers working on a single service don’t have to worry that their code is going to break some unrelated part of the system and they can release that one service as many times as your deployment team can go.
But it doesn’t just stop there. Using microservices you can swap out one technology for another. You want to change payment provider, write a new service that talks to them and then swap it in when the time comes. No need to release the full stack, and your test team can focus on just the area that is changing.
My Monolith
But you have invested millions in your monolith. It may be slow, and difficult to change, but you haven’t the budget or the resources to throw it all away and start again. You want the cloud, and APIs, and all that jazz, so how do you get there?
Well the solution doesn’t have to be an all or nothing approach. You can start by taking areas of your system and building APIs that talk just to them. As time progresses, this code can be untwined from the rest of the monolith. Before you realise it, you have the makings of a microservice architecture, and then it’s only a very small step to switch out to that new PIM your developers want.
Choosing to develop an interim solution like this means that you haven’t lost those years of investment, and you also haven’t taken an expensive leap into the unknown. Your team’s learning curve is reduced and you don’t have to retrain your product owners on a new platform. Taking a 2-phase interim approach might be the quickest way to get to a microservices platform with the least pain and the highest ROI.
I totally second this viewpoint. This is something, I have been pushing in for one of my client, where they have eCommerce system running on traditional estate, hence have divided the part into browse and buy journeys. Whilst buy journey can remain on traditional commerce platform, browse can be decoupled, giving instant leverage on the part of journey (browse) which will see greater footprint, and in interim provide a facade on top of commerce platform to decouple the traditional platform in the direction of micro-services.
Couldn't agree more Greg. Using microservices and decoupling the front end gives the retailers so much more flexibility to get customer focused changes out rapidly.
Great article Rex. We believe that the commerce market is in an increasingly rapid state of change. Because of this, using specialists to do managed application services while concurrently separating presentation layer and other functions from a commerce shopping cart through a managed micro services layer enables a retailer to leverage their current investment while enabling a very agile approach to new technology and trends.