Why should product managers understand Microservices? "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs August 08 2022 False Guest Post, Microservices, Mind the Product Mind the Product Ltd 1224 Why should product managers understand Microservices? Product Management 4.896

Why should product managers understand Microservices?

BY ON

In my previous article, I talked about Amazon’s “Buy with Prime” option and how Microservices has played a key role in not only enabling “Buy with Prime” on partnering websites but also in creating “Amazon as-a-Service”.

In this article, I will talk about why should product managers understand Microservices. Further, I will also talk about how should an organization transition to Microservices and establish scrum/Pod teams based on Microservices.

Why should product managers understand Microservices?

To understand this, we will need to look at the opposing end of the Microservices-based architecture which is a monolith. Let us look at this example through the lens of an e-commerce company named “iShop”.  This company sells many items online and has seen immense growth over the last few years. iShop did not worry about best practices during growth and ended up building a Monolith as shown below:

Now, imagine being the product manager for the payments team in this eCommerce company in a monolithic architectural pattern and your team wants to work to launch a buy now pay later (BNPL) functionality. It is month 3 and your team code is ready. But due to the monolithic architecture, the release team will need to coordinate among many teams, and hundreds of developers, resolve conflicts among them, merge the code into a single version, and produce a master version that waits in the queue to be moved into production. It also adds a lot of overhead to the delivery pipeline. Once the code base is built and tested, the team finds an issue with the unrelated code of the offers & catalog team. The offers and catalog team takes a few weeks to correct this code. The release team will then need to rebuild and test this whole code base again. In summary, an unrelated issue of another team impacted your ability to launch BNPL. This is what the Monolith did; it created speed and agility issues to launch new product features. For organizations dependent on technology to drive growth, this created a huge bottleneck in launching new features.

Microservices can be used to solve the problems identified in a monolith. Microservices – is an architectural style that structures an application as a collection of services that are

  1. Highly maintainable and testable
  2. Loosely coupled
  3. Independently deployable
  4. Organized around business capabilities
  5. Owned by a small team

See below for how the service-oriented architecture enables a quick release of features in production. Imagine yourself as the PM of payments who would like to launch a BNPL functionality. You can do that without dependence on other unrelated teams.

If this architecture is set up well, it will enable product managers with the following benefits:

  1. Faster time to market – Teams are organized around a set of services such as Customer Support, Payments & Checkout. Customer Support can work and deploy its changes without having to worry about the work occurring in Payments
  2. True omnichannel experience – Build and use the same services for websites, mobile apps, and external UX concepts. To cite an example,  mobile apps,  and websites can invoke the same Payment service to initiate and complete payment (Read this article on how this can be achieved)
  3. Better and less complex code – Create a repository to manage the code based on services. This makes it easy to manage and deploy the code
  4. Easy deployment – It reduces the overhead to the delivery pipeline. Only the code base of the service impacted will need to be rebuilt, test cases re-run before pushing the service to the production fleet.
  5. Independence to choose technology stack – The enterprise does not have to choose a technology stack. Teams will have the independence to choose the technology of their choice. This works well because the integrations among various technologies are achieved using restful APIs

The above benefits outline the key reasons why product managers should understand Microservices especially when facing problems with the Monolith. Further, suppose you are already a product manager functioning in an API-first platform built on Microservices. In that case, you may have to lead and design the composition of new microservices to enable logical use cases.

How to compose Microservices?

When implemented right, Microservices can lead to amazing business benefits. The obvious next question that comes to mind is: How do I compose Microservices?

To answer this, assume you are the product head of iShop which has seen amazing growth, has a large, complex monolith application, and faces multiple issues noted above. In order to solve these issues, you plan to transition your organization around Microservices.

The benefits of Microservices are not guaranteed. In order to achieve the intended benefits, the product leader should carefully decompose the large, complex application into a set of logical services. This decomposition should occur in a way that new and changed requirements only affect a single service. How do you then decompose your application into services?

One easy way to decompose an application into services is to define services according to the business capabilities. A business capability is a concept from the business architecture modeling. This is something a business does to generate value.

To continue with the example of iShop’s eCommerce site, the business capabilities of this company can include:

  1. Membership and user management
  2. Offers and catalog
  3. Orders and inventory
  4. Payments and checkout
  5. Customer support

Below is a sample decomposition of iShop’s eCommerce website/app into various microservices/ capabilities. I further show how the customer support organization can be broken down into pods further.

These teams comprising product and engineering members should follow the below principles:

  1. The team should not comprise more than 6-10 people
  2. The team should own one OR more services
  3. The team owns one OR more services that should be autonomous. The teams should be able to develop and deploy their services with minimal collaboration with other teams
  4. The services owned by the teams should be cohesive. Each service should implement a set of strongly related functions
  5. Each service should be loosely coupled – The implementation can be changed without affecting the clients (i.e. the same services can be called any front-end client and will not need to change every time there is a change to a service)

The resulting structure gives the following benefits:

  1. Stability because value-generating business capabilities are relatively stable.
  2. Development and product organizations become cross-functional and are organized around delivering business value rather than technical features
  3. The teams become cohesive and loosely coupled

In spite of the benefits, in order to do this transition, the organizations will have to address the issue of how to identify business capabilities. Identifying business capabilities and hence services requires an understanding of the business. An organization’s business capabilities are identified by analyzing the organization’s purpose, structure, business processes, and areas of expertise. Bounded contexts are best identified using an iterative process. Good starting points for identifying business capabilities are:

  • organization structure – different groups within an organization might correspond to business capabilities or business capability groups.
  • high-level domain model – business capabilities often correspond to domain objects

In summary, this article discusses why product managers should understand Microservices, and how to make a transition to Microservices to achieve its intended benefits.

Discover more great content on Mind the Product

In my previous article, I talked about Amazon’s “Buy with Prime” option and how Microservices has played a key role in not only enabling “Buy with Prime” on partnering websites but also in creating “Amazon as-a-Service”. In this article, I will talk about why should product managers understand Microservices. Further, I will also talk about how should an organization transition to Microservices and establish scrum/Pod teams based on Microservices.

Why should product managers understand Microservices?

To understand this, we will need to look at the opposing end of the Microservices-based architecture which is a monolith. Let us look at this example through the lens of an e-commerce company named “iShop”.  This company sells many items online and has seen immense growth over the last few years. iShop did not worry about best practices during growth and ended up building a Monolith as shown below: Now, imagine being the product manager for the payments team in this eCommerce company in a monolithic architectural pattern and your team wants to work to launch a buy now pay later (BNPL) functionality. It is month 3 and your team code is ready. But due to the monolithic architecture, the release team will need to coordinate among many teams, and hundreds of developers, resolve conflicts among them, merge the code into a single version, and produce a master version that waits in the queue to be moved into production. It also adds a lot of overhead to the delivery pipeline. Once the code base is built and tested, the team finds an issue with the unrelated code of the offers & catalog team. The offers and catalog team takes a few weeks to correct this code. The release team will then need to rebuild and test this whole code base again. In summary, an unrelated issue of another team impacted your ability to launch BNPL. This is what the Monolith did; it created speed and agility issues to launch new product features. For organizations dependent on technology to drive growth, this created a huge bottleneck in launching new features. Microservices can be used to solve the problems identified in a monolith. Microservices - is an architectural style that structures an application as a collection of services that are
  1. Highly maintainable and testable
  2. Loosely coupled
  3. Independently deployable
  4. Organized around business capabilities
  5. Owned by a small team
See below for how the service-oriented architecture enables a quick release of features in production. Imagine yourself as the PM of payments who would like to launch a BNPL functionality. You can do that without dependence on other unrelated teams. If this architecture is set up well, it will enable product managers with the following benefits:
  1. Faster time to market - Teams are organized around a set of services such as Customer Support, Payments & Checkout. Customer Support can work and deploy its changes without having to worry about the work occurring in Payments
  2. True omnichannel experience - Build and use the same services for websites, mobile apps, and external UX concepts. To cite an example,  mobile apps,  and websites can invoke the same Payment service to initiate and complete payment (Read this article on how this can be achieved)
  3. Better and less complex code - Create a repository to manage the code based on services. This makes it easy to manage and deploy the code
  4. Easy deployment - It reduces the overhead to the delivery pipeline. Only the code base of the service impacted will need to be rebuilt, test cases re-run before pushing the service to the production fleet.
  5. Independence to choose technology stack - The enterprise does not have to choose a technology stack. Teams will have the independence to choose the technology of their choice. This works well because the integrations among various technologies are achieved using restful APIs
The above benefits outline the key reasons why product managers should understand Microservices especially when facing problems with the Monolith. Further, suppose you are already a product manager functioning in an API-first platform built on Microservices. In that case, you may have to lead and design the composition of new microservices to enable logical use cases.

How to compose Microservices?

When implemented right, Microservices can lead to amazing business benefits. The obvious next question that comes to mind is: How do I compose Microservices? To answer this, assume you are the product head of iShop which has seen amazing growth, has a large, complex monolith application, and faces multiple issues noted above. In order to solve these issues, you plan to transition your organization around Microservices. The benefits of Microservices are not guaranteed. In order to achieve the intended benefits, the product leader should carefully decompose the large, complex application into a set of logical services. This decomposition should occur in a way that new and changed requirements only affect a single service. How do you then decompose your application into services? One easy way to decompose an application into services is to define services according to the business capabilities. A business capability is a concept from the business architecture modeling. This is something a business does to generate value. To continue with the example of iShop’s eCommerce site, the business capabilities of this company can include:
  1. Membership and user management
  2. Offers and catalog
  3. Orders and inventory
  4. Payments and checkout
  5. Customer support
Below is a sample decomposition of iShop’s eCommerce website/app into various microservices/ capabilities. I further show how the customer support organization can be broken down into pods further. These teams comprising product and engineering members should follow the below principles:
  1. The team should not comprise more than 6-10 people
  2. The team should own one OR more services
  3. The team owns one OR more services that should be autonomous. The teams should be able to develop and deploy their services with minimal collaboration with other teams
  4. The services owned by the teams should be cohesive. Each service should implement a set of strongly related functions
  5. Each service should be loosely coupled - The implementation can be changed without affecting the clients (i.e. the same services can be called any front-end client and will not need to change every time there is a change to a service)
The resulting structure gives the following benefits:
  1. Stability because value-generating business capabilities are relatively stable.
  2. Development and product organizations become cross-functional and are organized around delivering business value rather than technical features
  3. The teams become cohesive and loosely coupled
In spite of the benefits, in order to do this transition, the organizations will have to address the issue of how to identify business capabilities. Identifying business capabilities and hence services requires an understanding of the business. An organization’s business capabilities are identified by analyzing the organization’s purpose, structure, business processes, and areas of expertise. Bounded contexts are best identified using an iterative process. Good starting points for identifying business capabilities are:
  • organization structure - different groups within an organization might correspond to business capabilities or business capability groups.
  • high-level domain model - business capabilities often correspond to domain objects
In summary, this article discusses why product managers should understand Microservices, and how to make a transition to Microservices to achieve its intended benefits.

Discover more great content on Mind the Product

Leave a Reply

Your email address will not be published.