Microservices architecture: how to gain business agility

Microservices are bringing scalability and flexibility to retailers' core systems. But what exactly are they? And why is investing in tech architecture so key to survival? We find out in this guide to microservices architecture.

What is a microservices architecture?  

A microservices architecture is where an application's functionality and data is structured as a collection of independent but loosely coupled business components or services. 

These self-contained services or components typically have a single purpose. They’re loosely coupled and talk to each other using a common language – usually application programming interfaces (APIs). 

A 3-minute guide to microservices with Inviqa CTO RIchard Jones

Being small, these individual applications can be developed and managed by different teams and scaled independently for a flexible software system that supports continuous delivery and deployment. 

They’re easy to maintain and replace with alternatives without disrupting the entire application (just as long as the API contract is maintained). And, because they can be written in different programming languages, you can pick a language that does the best job for the task at hand.

The traditional approach is to have applications that do many things within a single, monolithic platform, with all functionality sitting within the same codebase. This dramatically slows down releases, because the entire application must be re-tested if any single part of it is touched.

The monolithic approach has served organisations very well (including ourselves; we’ve been working with the likes of Magento and Drupal for more than ten years). 

But it does have its downsides, and the primary ones are scalability and complexity. Because if you want to scale even a small piece of functionality, you have to scale everything. 

What we mean by this is that a monolithic platform does not enable you to add scale to a specific component in a platform that needs the additional power (the pricing and tax component in an ecommerce platform, for example). Instead you have to scale-up the entire application by adding more server capacity.

And if you want to change any aspect of the code, there could be unexpected consequences elsewhere in the application. This leads to massive and long testing cycles.

When your systems are closely coupled, as is usually the case with monolithic applications, it can be labour-intensive and costly to make changes to your digital products and services.

But by decoupling your technology stack and adopting microservices, it’s simpler to make quick product changes, scale individual services in isolation, and support innovation.

Above: an example of a traditional (monolith) architecture

Above: An example of a microservices architecture

Can microservices be paired with monolithic platforms?  

Absolutely! At Inviqa, for example, we still work with traditional, ‘monolithic’ platforms, but we separate key functionality where there are very particular requirements around scale or complexity that merit a microservices architecture.

Say, for example, you have a system with a bottleneck that’s slowing down the application in another area – complex pricing, for example, or stock calculation. We can move this specific function to a microservice, which means you isolate this demand from the main application in a way that allows it to be scaled independently as required.

This approach gives businesses more flexibility and agility. It makes it possible to split out a function or replace a microservice without having to re-platform the entire business. 

And, as your approach to using microservices matures, you’re able to split your core platforms across multiple services. And those services in turn can be managed by smaller, dedicated teams with a more focussed knowledge.

Which retailers should consider this approach?  

A microservices architecture is ideal for retailers who are burdened with large, monolithic systems and urgently require flexible, scalable technology that allows them to keep pace with changing customer expectations and markets. 

It can be a great fit for organisations facing vendor lock-in but needing to be able to swap systems in and out to serve changing markets and customer demands. 

To explain this better, let’s consider why many retailers find themselves with such legacy systems in the first place.

Traditional ecommerce platform providers have typically focused their efforts on building as comprehensive a suite of features as possible, either into the core platform or as part of an ecosystem of complementary products and services. All the best-in-class features, under one roof, from one vendor.

Solutions such as Hybris (now SAP Commerce), ATG (now Oracle Commerce), and IBM Websphere gained significant traction with larger enterprises looking to engage their audiences online. 

And more recently they’ve been joined by other major players such as Salesforce and Adobe, who take a similar view: many services and features from a single supplier.

The approach can serve the industry well. For a particular type of business, going ‘all-in’ with a provider offers convenience, a certain degree of stability, and simplicity, with ‘one throat to choke’. It fosters a degree of dependence to the chosen provider (an advantage or disadvantage depending on your viewpoint and circumstances).

But with any large-scale, business-critical solution, it’s crucial to reduce technical debt by upgrading, enhancing, and evolving the system. In today’s brutal trading conditions, being able to adapt quickly is a matter of (commercial) life and death.

So organisations that are highly dependant on large, inflexible, monolithic solutions have a difficult choice to make: commit to a large, high-risk investment in migrating to an alternative solution, or carry on ‘as is’ and risk becoming a technological dinosaur.

Inaction or paralysis leaves a retailer open to disruption by faster, nimbler competitors who are free from technical debt or reliance on large, monolithic solutions.

But the huge costs and risks associated with moving to a new, contemporary solution are daunting.

Microservices can be hugely beneficial for retail organisations facing this dilemma. A microservices architecture allows them to build flexibility into their digital products and services and deliver changes quickly and in a sustainable way.

What are the business drivers for microservices?   

Historically, utilising a monolith solution was seen as investment in a ‘safe pair of hands’ – a single, well-established, and trusted partner whose immediate solutions and roadmap would be able to support the vast majority of your business initiatives, with the occasional need for bespoke development to mould it to exact requirements.

But when retailers are looking for every opportunity to stand out from the crowd and present a point of difference to their customer base, the adoption of microservices brings with it a host of commercial advantages which allow businesses to drive out competitive advantage.

A microservices-based approach provides agility enabling businesses to pivot and react to the changing demands of their customer base.

Pilots can be launched, assumptions tested, and insight gained quickly. And when demands and expectations shift, new services can be adopted or existing ones replaced without having to throw away or heavily customise the whole solution. 

Independent deployment sits at the core of a microservices approach and this typically results in faster, safer upgrades, and reduced down-time, and helps businesses to significantly improve their speed to market when it comes to launching new features or propositions.

Not all businesses will have the same appetite for risk. And likewise, how risk is seen will vary throughout an individual business. Thankfully though the use of microservices enables businesses to apply risk profiles at a granular (business function) level and accept greater levels of risk where they see fit. 

For example, when it comes to fraud prevention or CRM, a business may choose a solution with product maturity and a compelling track record, but select a ‘higher-risk’ industry-newcomer for its recommendations engine or CMS due to specific functionality that it can offer. 

In this way it’s possible to protect against start-ups and disruptors in a way in which those tied into monoliths simply cannot do. 

Microservices adoption makes it easier to select the best tool for the job rather than the one that happens to be available as part of a larger enterprise solution. 

In this way services that fit the team’s experience, methods of working, and ultimately their day-to-day and strategic needs can be chosen rather than being dictated by an approach to find ‘one tool to suit everyone’ where compromises are made.

What’s more, by empowering business functions to ‘own’ individual services through organisational alignment, businesses are able to create centres of excellence where there is a focus on creating best practice methods and driving product development and feature enhancement targeted at growth and efficiency initiatives.

How do you introduce a microservices architecture?  

The beauty of microservices is that they allow retailers to reduce the risk and scope of an ecommerce migration project by considering the total solution as a series of separate components. The business is able to tackle the legacy system one feature at a time instead of as a single, enormous, complex, and indivisible unit.

Just like any other ecommerce project, moving to a microservices architecture should be considered, first and foremost, in terms of value generated.

Your digital partner should work with you to ascribe commercial value to the features you wish to migrate or implement. And then these should then be prioritised to ensure maximum value for the given budget.

The existing, monolithic system should be approached as a series of services, each with its own commercial value. This helps us to start migrating features across, focusing on isolated areas that will deliver the most value.

Take the standard ecommerce basket function as an example. By introducing a microservices architecture such as commercetools it’s possible to decouple the native feature in question (the basket, in this case) from the monolithic application and instead allow the microservice to take responsibility for that function. 

Remember that migrating to a microservices architecture is a rolling, continuous project. You’re implementing one component or feature at a time, mothballing its legacy predecessor until there’s little or nothing left of the solution that went before.

Which cloud commerce tools support this approach?  

commercetools, and other cloud-based ecommerce software focused on APIs and microservices, offers the industry a genuinely new and effective alternative to the traditional ‘all-in-one’ ecommerce replatform, with all the risks that carries. 

At the most basic level of explanation, commercetools is a series of API endpoints that can be engaged in a variety of programming languages.

The benefits of this approach are clear:

• Smaller components can be introduced and scaled individually, as needed.
• Migration and development is truly iterative, making testing smaller and more manageable.
• Dependency on a single provider is reduced (however, greater governance is likely as there would be more partners / technologies included in the overall solution).
• The likes of commercetools and BigCommerce are language-agnostic, and so you can select the best solution for the job.
• Flexibility is ensured as there’s a lower degree of vendor ‘lock-in’ by spreading responsibility for the solution across a number of providers/services.

Final thoughts

Many retailers find themselves with legacy system that make it difficult to evolve the organisation alongside changing business, market, and customer demands. But starting again with a ‘re-platforming’ exercise can be costly, complex, and requires you to rewrite the elements of your legacy systems that do actually work.

A microservices architecture can be an ideal solution to this challenge by enabling retailers to bring flexibility and scalability to their core systems, ensuring that they’re capable of supporting any number of APIs and third-party systems.

And by enabling dedicated, skilled teams to form around specific services in a system, microservices are ultimately about making innovation a way of life – something that’s key to survival in today’s difficult retail climate.

About the authors 

Richard Jackson, managing director: retail at Inviqa

Richard has led major retail brands to commercial success. In his current role he manages Inviqa’s retail portfolio, enabling brands to meet complex business and customer needs with ecommerce platforms that drive sustained ROI.

Richard Jones, director at Inviqa

In his current role Richard enables leading media and entertainment brands to define their content strategies and develop enterprise-wide technology architectures that support business-wide transformation and innovation at scale.

Brett Lawrence, business consultancy director at Inviqa

Brett Lawrence has 20 years’ experience working with leading retail and entertainment companies. At Inviqa, Brett helps clients resolve complex business challenges, develop their strategies, expand their digital propositions, and ensure a positive return on investment.