How often do you have to patch, upgrade and test your platform, triggering system downtime? If you are operating a traditional noncloud platform, downtime will be a regular part of your routine. Maybe it has become such an accepted part of your IT regime you don’t even question the restrictions and operational time lost – it’s just become a part of life.
Now imagine a world in which your platform never needs downtime, but resides in a continual state of updatedness. Gone is the regular ebb and flow of upgrades, testing and patches and there’s no need for the seasonal pre-peak trading lockdown. If you can image this nirvana you have just had a glimpse what it’s like to migrate to a cloud-native platform. The cloud’s secret ingredient But where’s the catch and how is this seamless delivery of IT services possible, you may be asking. The secret ingredient for always-current, runanywhere cloud-native systems lies in their microservice architecture.
Microservice architecture is an increasingly popular way of building retail-specific and sector agnostic enterprise systems. Essentially, it’s a method of developing software applications as a suite of small, independently deployable, modular services, each of which runs a unique process and communicates through a well-defined, lightweight fabric mechanism to serve a business goal.
In a retail environment those goals could include enterprise order management, point of sale, inventory management, fulfilment, or customer intelligence, combining to give one view of the truth.
To fully understand the attraction of microservices it’s useful to compare them with the traditional method of doing things: the monolithic architectural style. Cloud versus monolith Traditionally, software was built as a single, autonomous unit. In a client-server model, the server-side application is a monolith that handles the HTTP requests, executes logic, and retrieves/updates the data in the underlying database.
The problem with monolithic architecture, is that all change cycles usually end up being tied to one another. A modification made to a small section of an application might require building and deploying an entirely new version.
If you need to scale specific functions of a monolithic application, you may have to scale the entire application instead of just the desired components.
That’s why rigorous and sometimes expensive testing regimes are required, and also why risk-averse retail sector organisations play it safe, locking down their code weeks, if not months, ahead of peak trading.
The kinds of restrictions associated with monolithic software can stifle agility, smother innovation and kill new business opportunities before they can be realised.
For example, retailers may be unable to add a hot new line to their inventory in the run-up to peak trading, while their agile, cloud-enabled competitors enjoy a critical advantage and corner the market.
Retailers working on a cloud platform could initiate everything from a simple workflow change in a mobile app, to wiring in an external promotions engine or API calls to a CRM application, quickly and easily.