A overhead, long-exposure image of a busy motorway.
Tuesday, November 2, 2021
Written by:
Digital Boutique

Why microservices architecture is the future of ecommerce

4 minutes
Read
MORGAN HIPP

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

Magento recently announced its move to a microservices architecture. What does that mean? And how will it affect the world of ecommerce?

What are microservices?

In a microservices architecture, each service is developed as an individual entity that communicates with other services in the system through API calls.

Why do we need microservices?

Microservices were created to handle the increasing complexity of digital applications.

Before microservices came monolith: single systems in which all services are combined. A change anywhere in the codebase has the power to impact, or even break, the entire system. As a result, every update requires rigorous testing and the deployment of the complete application.

The monolith approach works well for simple, newly launched applications. But as applications grow in size and complexity over time, they become cumbersome and difficult to manage.

Enter microservices.

Why is Magento launching accessible microservices ?

Magento’s recent announcement means that instead of accessing a full ecommerce platform like Magento, retailers will be able to combine individual ecommerce microservices to create a platform entirely configured to their needs. This brings many benefits:

Rapid development

Each service team in a microservices architecture can plan, sprint and deploy on their own timescales, without any delays from dependencies.

Extendability

You don’t have to consider how new services will impact the system as a whole. Just connect it to the existing microservices architecture.

Service-specific teams and fast bug fixes

In a microservices structure, developers only work on their individual service – a limited codebase in which they can understand every intricate detail. This deep understanding results in a better product and makes bugs easier to find and resolve.

Scalability

A microservices architecture automatically scales relevant services to cope with peaks and scales down once the need has passed. This is particularly beneficial in ecommerce, which needs to handle sudden peaks for promotions or events.

While scaling for peaks is possible in a monolith system, it’s less efficient – your only option is to manually scale the entire system. 

Smooth third-party integrations

Compatibility, conflicts and complex integrations are irrelevant in a microservices system; third-party applications are treated as independent microservices like any other. This frees you up to choose best-in-class solutions every time.

Multi-platform systems

Because microservices are largely independent of each other, you can build each one on a different platform and in a different programming language. This means every service can be built in an optimal way, regardless of any technical decisions that have gone before.

Reliability

If one microservice fails, the rest remain fully operational. 

"Why do we have such granularity? We want to minimise the risk of change. For example, if we want to change the way contactless payments work, we're not affecting the chip and PIN system."

Suhail Patel, Senior engineer at Monzo, which operates 1,600 microservices.

The drawbacks

The growing microservices movement is focused on the many benefits of this kind of system. That’s not to say there aren’t also downsides:

Complex infrastructure

The systems needed to keep microservices working in harmony are intricate. Rolling out the necessary systems and processes to get them up and running can be costly and version control is challenging. 

Limited performance

Microservices rely on API calls to send and receive information. These are continually active and can slow overall performance.

Network latency

In a monolith system, calls to other processes or functions are completed in just nanoseconds. For microservices, this latency is multiplied by a factor of 1,000,000.

Potential for duplicate effort

Developing services that are largely independent of one another leaves scope for unintentional overlap. This has to be carefully managed to limit inefficiencies.

What does this mean for retailers?

In the short term, Adobe’s accessible microservices structure will only be relevant for enterprise-level organisations with complex needs and high turnover. For these, the significant investment needed to implement a microservices architecture will be offset by the benefits.

Microservices will not initially be affordable to smaller organisations. But as Adobe moves into microservices, the open source community has announced that it will keep the Magento platform alive. We don’t yet know what a community-led Magento 3 will look like but the group has stated its intention that “all companies who want to remain on the monolith platform will be able to do so.”

We may later see aggregators enter the market, which will widen access to the microservices approach by running systems on behalf of smaller organisations on a subscription model.

As ever, our advice to retailers is to consider all the platforms available and identify which will best serve your customers and business objectives. 

Want to learn how you could move and benefit from a microservices architecture?

Get in touch

Development
Ecommerce news

Related Blogs