A Guide to Microservices Adoption

Whitepaper

For the Modern eCommerce Strategy

Business ContextIn 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 include 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.

The Guide to Microservices Adoption

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.

2

Key Microservices Principles:Microservices, or microservice architecture, is an approach to application development in which an application is split into modular components or services.

Loosely Coupled. Microservices architecture consists of a multitude of independent services. Each microservice relies on its own data model and is developed, deployed and operated independently.

Service-Oriented. 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.

Bound Context. 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.

3

The Guide to Microservices Adoption

Benefits of Microservices Architecture: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.

Business Agility. 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 .

Innovation. 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.

High Performance. 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.

High Availability. 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 high-availability and fault tolerance. This allows for businesses to reduce downtime minimizing revenue losses and ensuring superior customer experience.

4

The Guide to Microservices Adoption

Microservices Adoption Challenges:To fully realize the benefits from the application of microservices architectural style, enterprises need to overcome certain challenges related to microservices adoption.

Organization A full page of recommendations based on the categories a shopper has been browsing. Not just products they have already clicked on.

• Structure: Many organizations are designed around business and IT silos working in a “design, build, operate” model for new capabilities.

• Culture: A large number of small cross-functional teams owning individual microservices and operating independently requires a high level of trust across the organization

• Governance: While the teams are small and independent, the overall architecture must fulfill the business mission successfully. Requirements for each service needs to be governed effectively. Multiple technologies and frameworks can result in higher training costs and lower cross-team redundancy.

Architecture Microservices architecture has its own specific challenges which can escalate quickly with the growing number of microservices:

• Consumption: In a complex ecosystem with hundreds of services, a lot of decisions need to be made: how do consumers discover relevant services, when is the time to orchestrate and when to choreograph, how do teams implement patterns like back-end for front-end?

• Cross-cutting concerns: A large number of small cross-functional teams owning individual microservices and operating independently requires a high level of trust across the organization

• Master data management: Given that a microservices architecture encourages decentralized data management, this may result in data duplication and issues with eventual consistency.

Operations With tens and even hundreds of microservices deployed, operating them efficiently becomes a separate challenge:

• Testing: Microservices can be developed and tested separately, but they still need to be tested together with dependant microservices and, testing of a distributed system inherently requires more effort.

• Performance: The distributed nature of microservices leads to an increase in the number of API calls which can result in declining performance. Reporting can also be challenging for a microservices-based architecture due to data distribution.

• Cost: Since each microservice is run separately, it has its own infrastructure overhead which can result in skyrocketing infrastructure costs even for an idle solution. Multiple technologies can result in higher licensing costs and have a negative impact on TCO as well.

10

The Guide to Microservices Adoption

Leveraging Microservices for Enterprise Commerce ArchitectureOne 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 BuyThe 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.

The Guide to Microservices Adoption

Out-of-the-box vs CustomizationIf the enterprise has decided to buy the solution from one or more vendors, the next step is to set the expectations for the level of customization:

Out-of-the-box: Enterprises looking for an out-of-the-box commerce platform will opt for a best-of-suite solution or a solution consisting of a limited number of vendors. This will reduce integration cost and bring the new platform to market faster. In this scenario, the enterprise is less concerned about the underlying architecture as long as the purchasable components are independent.

Highly Customized: Fits larger enterprises that look for a best of breed solution tailored to their business needs. When combined with microservices architecture this approach can allow the creation of highly-customized solutions. To enable this, the commerce platform needs to allow extensive customization capabilities which is not always the case and depends on specific vendor. The downside of this is longer time-to-market and higher IT TCO.

3

The Guide to Microservices Adoption

Smaller vs LargerOne of the obvious questions during the evaluation of commerce microservices-based solutions is the granularity of microservices architecture. Like in many architecture-related decisions there are trade-offs:

Smaller microservices: Extremely granular architecture provides greater flexibility since enterprises can replace any single microservice with one from another vendor or with a custom-build. An example can be a “Promotions” capability consisting of multiple microservices such as loyalty, retention, campaigns, personalization and other. This flexibility comes at a cost. Implementation of cross-cutting requirements such as GDPR becomes extremely complex and microservices integration becomes expensive. Also, the benefits are limited by the fact that most enterprises will not buy a single microservice from a different vendor due to technological, management and commercial overheads.

Larger microservices: Larger microservices provide less flexibility, as essentially microservices is the smallest indivisible functional component. As an example, “Promotions” capability will be represented by a single microservice. This limits enterprise choice in purchasing capabilities down to a single microservice. On the other hand, this reduces architectural complexity and associated costs. Also, most of the purchasing decisions are done at a scale much larger than individual microservices.

The Guide to Microservices Adoption

Selecting the Right Commerce Architecture for your NeedsBy now we hope to have provided a balanced view on aspects of microservices architecture style and offered some insights on how to select the right commerce solution with the right architecture.

To ensure that a commerce solution helps organization achieve its business goals, it is necessary to look at the aspects mentioned above through the prism of a business case:

Business goals should be the starting point for any technology, architectural or vendor decisions. Transition to microservices architecture by itself won’t drive revenue growth or increase customer satisfaction. After the business goals and the strategy of how the organization can achieve them are defined, only then does it make sense to start designing architecture.

Business requirements fulfilment, not the technology choices, will drive project success. Once the existing and potential future functional and non-functional requirements are satisfied, any additional complexity becomes a liability and an unnecessary risk.

Organizational capabilities are extremely important. If an organization wants to deploy a solution consisting of 100s of microservices and customize them, it needs to be ready to do this. A proper governance model with multiple independent teams experienced with a DevOps approach needs to be in place. This may require reorganization, change of business processes and re-education of personnel.

12

If you need help delivering unified commerce experiences across all customer touchpoints, contact Elastic Path.

info@elasticpath.com | elasticpath.com

The Guide to Microservices Adoption