3 Gotchas that Can Derail Your Microservices Success

We’ve covered in other posts lots of great benefits to Microservices, but in this post we’d like to address some “gotchas” we typically see come up during a retailer’s journey into microservices.

 In a microservice architecture, where an application is divided into small, independent, and loosely coupled services, each microservice is responsible for a specific business functionality. Microservices generally communicate with each other either by REST API or messaging like Kafka, which should allow development teams to develop, evolve and scale each microservice independently.

Microservices offer retailers the ability to quickly respond to changing consumer demands, and to add a level of agility to their OMS that has traditionally been difficult to achieve. But, if not done correctly, this approach can cause unintended consequences. Here at the top three issues we see as retailers move through the journey. In each area, we’ll provide some recommendations to avoid or mitigate these issues.  

1. Infrastructure Cost: In a fast-paced retail environment, it is tempting to add a new microservice for each requirement or feature. Because microservices are, by their very nature, polyglot, you can quickly find yourself with a host of different languages, frameworks and data stores in your tech stack. Data stores, in particular, can increase the cost of infrastructure resources as you have to manage backup, recovery and scalability.

Microservices can add a lot of operational complexity in other areas as well. Each microservices needs to be deployed, monitored and maintained independently. There are more services and data stores to manage. To make it all work, we may need an API gateway, messaging layer, container orchestration tools, build and deployment pipelines, different load testing tools, monitoring tools, and more. And as these microservices communicate with each other either directly by API calls or through a messaging layer, increased traffic can lead to higher network infrastructure cost as well.

The following best practices can help mitigate infrastructure costs from spiking:

• • Resist the temptation to keep adding new microservices to the architecture; ensure that there is a strong business case when adding new features

  • Limit the number of tech stacks, frameworks, languages, and other variables

  • Optimize infrastructure usage by using auto scale capability

  • Reduce or bring down components when not needed

  • Consider serverless for some of your components

2. Integration Complexity:  While all of these microservices need to communicate with each other, they have different data stores and are owned by different teams. As a result, each microservice is evolving independently, has a different roadmap and speed of development, and new data structures are constantly getting added or changed. This can lead to inconsistent data structure and formats across microservices. Changes in one microservices can break other services and bring the production system down.

How to mitigate integration complexity using best practices:

• • Using a schema registry can mitigate these challenges providing a centralized location for storing and managing data schemas, ensuring that all services are using the same data format; this approach also provides validation, version control on schemas and can help prevent errors. 

  • Microservices should be loosely coupled and designed to have minimum interaction points.

  • If there are too many interaction points between two microservices, you should consider merging them.

  • If one microservice fails to respond or becomes slow, it can bring down dependent microservices; to mitigate this risk, microservices should be designed to handle cascading failures including via circuit breaker patterns which are effective in solving cascading failures in a microservice architecture.

  • Building an integrated environment to test changes across microservices can help to detect these issues early on.

3. Dev Ops Maturity: Microservices architecture adds another layer of complexity because of multiple components involved. It can take longer to debug issues across microservices without proper tools for monitoring, logging and visibility.

DevOps maturity is very important in a microservices architecture so that the team is able to deploy, monitor, and debug issues efficiently. In addition, an integrated QA environment is crucial to testing functionality across microservices. Code quality checks, security vulnerabilities, and automation test cases are essential in this architecture.

Multiple microservices means multiple releases across the tech stack. If an organization doesn't have proper automation for testing, deployment, code quality checks, and monitoring, It can add significant delays in development. 

To ensure strong Dev Ops capabilities, your approach to deploying microservices should include: 

• • Automated CI/CD pipeline for micro services

  • The ability to create integrated environments and run automated test cases across microservices.

  • The ability to aggregate and search logs across microservices.

  • Using tools to monitor and alerts on infrastructure as well as microservices.

  • Infrastructure as Code (IaC)
    

Solving Today’s Omnichannel Fulfillment Challenges

Microservices are proving their worth as an effective approach to solving today’s omnichannel fulfillment challenges.  As retailers respond to new consumer behaviors and evaluate the best features to add to their OMS to remain competitive and meet customer needs cost-effectively, taking a smart approach to deploying and managing microservices is key. 

To reap the benefits in your organization, ensure that your teams are thinking through the challenges outlined here. At Nextuple our delivery and engineering groups can provide guidance on best practices to steer you down the path of success. Contact us to get started!