Introduction: Business Context
In the digital world, the boundaries between industries are blurring which results in a disruption of previously mature markets including transportation, retail, consumer goods, and communications. As incumbents are adopting new business models to protect themselves, business and IT complexity is increasing. On top of this:
The number of touchpoints through which brands engage consumers is growing exponentially and now includes connected devices, chatbots, kiosks, virtual assistants and more.
To stay competitive, enterprises need to be able to tackle this increased complexity by fostering innovation and continuously providing new business value to their users. This often requires not only changes to the existing commerce platforms but the integration of new 3rd party and open source software components. All these changes need to be developed, tested and rolled out quickly if needed.
Enterprises across the globe are tackling these challenges by undergoing a digital transformation to change their business processes and IT systems. Unfortunately, their existing legacy commerce systems pose multiple challenges:
Tight Coupling: Many existing commerce platforms and home-grown solutions were designed to deliver a web-store experience exclusively and have limited ability to support other channels.
Absence of a Mature API Layer: Partially a result of tight coupling, many legacy platforms lack a proper API layer to enable quick touchpoint onboarding and business logic unification across channels.
Lack of Flexibility: With straightforward business models and limited sales channels, legacy platforms were designed to do a limited number of things well and usually struggle with supporting innovative products, services and business models.
Limited Scalability: Legacy platforms were designed for vertical scalability with expensive hardware. Small, medium and large companies need to be sure they can easily meet peak demand at reasonable costs.
As enterprises are looking to transform their IT systems, they need to find the right solution with the right set of functional capabilities backed by the right architecture. Microservices is an architecture style that promises to address the challenges and become the cornerstone of a digital enterprise.
This whitepaper provides an overview of microservices related benefits, challenges in the context of commerce and insight into how an enterprise should pick the right commerce solution.
Chapter 1: Key Microservices Principles
Microservices, or microservice architecture, is an approach to application development in which an application is split into modular components or services.
Microservices architecture consists of a multitude of independent services. Each microservice relies on its own data model and is developed, deployed and operated independently.
Microservices can provide direct business capabilities or serve as a proxy to a 3rd party service. Since no two microservices should be aware of each other, microservices orchestration is another possible task that is executed by microservices.
Each microservice is responsible for everything happening within its boundaries and does not interfere with what happens inside other microservices bounded context. The size of the microservice is defined during the design phase.
Chapter 2: Benefits of Microservices Adoption
The microservices architecture was pioneered by the internet companies who relied on its principles to develop in-house platforms. Today the growing popularity of microservices is driven by the promise of tangible benefits to both business and IT.
Microservices enable organization to split into a large number of cross-functional teams including business and IT. This allows each team to work on the relevant subset of overall solution functionality independently of other teams. This enables a DevOps approach in which development and operation teams are working closely together to enable continuous development, testing and deployment of applications. This allows an accelerated deployment of new functionality as separate microservices can be changed, tested and deployed independently.
Adoption of the DevOps approach allows for a reduced cost of failure and accelerated innovation, enabling business to quickly roll out new experiences and touchpoints to see what works and what does not. This low cost of failure fosters a culture of change and innovation.
Decoupling of microservices allows them to be scaled horizontally and independently based on individual load. Also, each microservice can be developed using the most optimal technology that fits its tasks which further optimizes performance. This also means a decrease in infrastructure costs.
One of the important aspects of microservices is failure isolation - if one microservice fails, it does not affect the other microservices. Mission critical microservices can be run in multiple instances to ensure highavailability and fault tolerance. This allows for businesses to reduce downtime minimizing revenue losses and ensuring superior customer experience.
Ready to Adopt a Microservices Approach?
Chat with an ecommerce expert to learn more about how your business could benefit from leveraging a microservices architecture and determine whether you should build in-house or buy.
Chapter 3: Leveraging Microservices for Enterprise Commerce Architecture
One of the common questions asked today is “Should an enterprise pursue microservices architecture or not?” and the answer is “It depends on the business context”. When building an enterprise architecture, it is important to remember that microservices are not a silver bullet for any problem but merely a vehicle to address business challenges and gain business benefits. There are several aspects to be taken into account when considering microservices for an enterprise architecture:
Build vs Buy
The starting point is the decision whether the enterprise will build their own commerce platform or buy one or more solutions:
Build: This is the route taken by microservices pioneers. In this case all the architectural and technology decisions will be made by the enterprise and will depend on available resources, skills, organization capabilities and business goals.
Buy: In this scenario the enterprise will be consuming software developed by a 3rd party (vendor) and possibly extending the solution. In this scenario, often the architecture is not exposed to the enterprise and it cannot get value from different architectural styles. All the architecture and technology decisions rest with the vendor and the enterprise can focus on business requirements and business benefits.
In some cases, a company can opt to purchase a platform and build on top of it. This situation is a mix of the two above and the specific approach depends on how much is expected to be bought and how much is expected to be developed.