Product Owners and Reactive Microservices

DZone 's Guide to

Product Owners and Reactive Microservices

Microservices architecture supports DevOps, and product owners can follow these recommendations to adjust their thinking to a DevOps environment.

· DevOps Zone ·
Free Resource

What Is a DevOps Product Owner?

A product owner is someone who is,

  1. Accountable for maximizing the value of a product,

  2. Incrementally managing and expressing business and functional expectations for the product, and

  3. Doing so by the means of a prioritized product backlog.

With DevOps, it has now become extremely important for product owners to use “Systems Thinking” (DevOps – Three Ways). They should look at the bigger picture and ensure that the importance of operability of a product is understood. A modern product backlog should describe the scalability, deployability, security, and performance, besides the functionality of a feature.


Recently there is a lot of buzz around microservices. I would say microservices support DevOps by enabling development and release of loosely coupled applications, but also the agile development idea of keeping things very small and iterative.

Microservices decompose an application into different smaller services to improve modularity and makes the application easier to understand, develop and test. It also parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently. It also allows the architecture of an individual service to emerge through continuous refactoring. Microservices-based architectures enable continuous delivery and deployment.

The Reactive Manifesto for a Product Owner

To get the most out of microservices-based systems, we should embrace the four principles outlined in the Reactive Manifesto.

Image title

Let us apply the Product owners lens on the Reactive Manifesto to include the Operability aspect in the Product Backlog

Responsive: A responsive system responds in a timely manner. Responsiveness is the cornerstone of usability to gain end-user confidence.

PO Lens: Cleary specifies the performance parameters for the feature or user story being developed. Include details about the logging, monitoring, or an alert mechanism for the piece of functionality to ensure consistent behavior and rapid error handling.

Resilient: The system stays responsive in the face of failure.

PO Lens: Think about the scalability of the product/service considering the responsiveness expected. Do we scale up or scale out (add or replicate)? How should the service react in event of failure or delay in response, should there be an alternate flow?

Elastic: The system stays responsive under varying workloads. Reactive Systems can react to changes in the input rate by increasing or decreasing the resources allocated to service these inputs.

PO Lens: Include Replication, Location and Access transparency wherever possible. The solution should not be affected if the system resources are replicated, scaled down or up to handle the varying load.

Message Driven: Reactive Systems rely on asynchronous message-passing to establish a boundary between components that ensures loose coupling and isolation.

PO Lens: Use asynchronous communication wherever applicable, as it fosters Elasticity and Resilience to achieve higher responsiveness. It supports parallel execution and effective error handling.

Image title

So, in summary, a DevOps Product Owner needs to:

  1. Embrace "System Thinking" and focus on the complete lifecycle from conceptualizing to maintenance of a new feature.

  2. Understand the "Operational Requirements."

  3. Ensure that the "OR’s" or the "NFR's" are seen as important as the "Functional and Business  Requirements" in the Product roadmap and champion their implementation.

devops ,microservices ,product owners ,agile ,reactive manifesto

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}