Microservices Explained for Product Managers

One of the first tasks in the early days of starting out as a new product manager joining a team is to understand the architecture of the product you’re working on.

In my experience, many product folks often feel uncomfortable beyond a certain point in a new role asking basic questions about the architecture of the product they’re working on for fear of sounding unknowledgeable or exposing knowledge gaps.

Sure, it’s probably best to try to get answers on the basics of your architecture within the first few weeks of starting a new role, but there’s never a bad time to ask your engineers fundamental questions about your architecture to plug you knowledge gaps; you may feel a little silly not knowing everything but that’s OK. Product managers are not meant to know everything – and guess what? Engineers will likely respect you more for asking questions and taking an active interest in the codebase.

Introducing microservices

One of the first introductions product manager might get into the world of architectural design is the concept of microservices. But what exactly are they?

Microservices are an architectural pattern in which an application is built using a collection of small, independent ‘services’ that communicate with each other over APIs.  If you’re not familiar with REST APIs and how APIs communicate with each other check out this guide.

The idea behind using a microservice is that the code base is split up into distinct areas, each independently responsible for a specific function or business capability, and can be developed, tested, and deployed independently of the other services in the application. An insurance company, for example, might have a bunch of services that lead to a sale:

• Quoting service generates a quote for the customer
• Invoice service generates an invoice
• Comms service sends out annual premium statements to customers

One of the main advantages that advocates of microservices claimis that they allow for more modular and flexible development, as each microservice can be developed and managed independently. This in turn should make it easier to add new features and capabilities to an application, and to make changes to the application without affecting the other services.

There are also efficiency benefits to using microservices since each service can be independently scaled up or down based on specific needs. As you’d expect, this can help to improve the overall performance and reliability of the application, as well as to reduce costs by only scaling the services that require it.

For product managers, understanding the principles of microservices or service-oriented architecture can help inform decisions about how to design and build scalable and flexible products.

OK, this all sounds wonderful, but what exactly is a microservice? Let’s examine the components of a microservice more closely.

The anatomy of a microservice

Not all microservices are built the same, but you can expect a microservice to be a mix of the following pieces:

1. Code (front end or backend) and programming libraries
2. Database
3. API

These three distinct components will typically make up a micro service and services will interact with each other via APIs. The services will be exposed via an ‘endpoint’ which allows this communication to take place.

So when your engineers talk about the creation or maintenance of a new microservice, imagine these 3 parts working together. It’s also a good idea to actually see a real service in action so if you can, try asking an engineer to pick a single service and talk you through the various parts of what it does.

Practical examples

Product managers will work across many different domains in their careers but the architecture behind service oriented design will remain the same. Here’s a few practical examples of how microservices might manifest themselves in the real world, using real world product examples to bring them to life a bit more.

The microservices built in a cloud context will serve a completely different user need vs. ecommerce, but the underlying principles across different use cases and companies remains the same.

OK, this all sounds wonderful, but surely there are some downsides to using microservices, too right? Indeed.

Potential downsides of microservices

This famous viral clip explains the biggest potential downside of using microservices. Too much of a good thing can actually be a bad thing and some engineering teams will take service-oriented architecture to the extreme and end up building something so complex that nobody can understand what each service does any more.

Some of the potential downsides of using microservices include:

1. Complexity – microservices can be more complex to develop and maintain than a monolithic application because they require coordination between multiple services.
2. Debugging and troubleshooting – microservices can be more difficult to debug and troubleshoot because errors can be hard to track down when they span multiple services.
3. Latency and speed – the communication between microservices can add overhead and increase latency, which can impact the performance of the overall system.
4. Cost – microservices can be more expensive to operate because they require more infrastructure to support the individual services.

Overall, while microservices can offer many benefits, product teams should be mindful of the potential downsides too. From a product perspective, one of the most challenging aspects of working with microservices is when you work at a company that is burdened with tech debt and wants to transition from a monolithic architecture to microservices.

Let’s explore some ways you might able to do it.

How to transition from monolithic architecture to microservices

Transitioning from a monolithic architecture to a microservices architecture is difficult. It typically involves several key steps:

1. Identify business capabilities – service oriented architecture takes a business-centric view of your application. Before you can build services, you need to identify which business operations each service might perform.  Identify the core business capabilities of your application and divide them into independent services. This typically involves breaking down the monolithic codebase into smaller, self-contained units of functionality.
2. Develop and test – Develop and test each service independently, using continuous integration/continuous deployment (CI/CD) processes.
3. Implement communication mechanisms – Implement effective communication and coordination mechanisms between the different services, such as APIs.
4. Deploy the services – Deploy and manage the services using containers and orchestration platforms, such as Kubernetes, to ensure that they are scalable, resilient, and easy to update.
5. Monitor post launch – Monitor and measure the performance of the individual services and the overall system, and continuously iterate and improve the design of the microservices.

It is important to note that transitioning to microservices can be a complex and time-consuming process, and it may require significant investments in development, infrastructure, and tooling.

Ideally, moving towards a new architectural pattern should be an iterative process where you move each part of your existing architecture piece by piece. But this isn’t always possible. From a product perspective, if your team is undergoing an architectural transition, planning the transition is critical to avoid any potential disruption to the existing application and to maximize the benefits of the new architecture.

What product managers should know about microservices – key takeaways

So that’s a brief overview of what microservices are, but as always in product management the question we really want to know the answer to is ‘how much do I really need to know as a product manager?’.

Well, there’s two things to consider here. First, why should product managers care about architecture more generally and second, why should product managers care about microservices specifically.

Why PMs should care about architecture in general

It’s certainly possible to be a product manager without knowing much about your architecture, but it’s definitely not advisable. Understanding your product’s architecture is helpful in a number of ways:

1. Security – having a birdseye view of your applications help you and your team identify potential security risks. One of the most common ways products are left vulnerable to attacks these days is through endpoint exposure. Again, if you’re not familiar with what endpoints are then check out our API guide for more details. But essentially, an endpoint is a URL where requests are made. And if those endpoints aren’t secured, this could expose your product to malicious attacks. Understanding your architecture will help you gain a sense of the security risks your product might face.
2. Scalability – poor architectural decisions will inevitably impact your ability to scale. If you know that a new feature is going to be used by millions of customers, it’s incumbent upon the product and engineering teams to understand how architectural decisions might impact the product’s ability to scale.
3. Tech debt – every product manager’s favorite topic: tech debt. Tech debt is often the result of architectural decision making that accrues over time. It’s an inevitable part of building products as team members churn and new decision makers come on board. But if there’s one principle that all teams can adhere to even when team members come and go it’s this: build to change, don’t build to last. Strong tech leads will anticipate change and build solutions in ways that anticipate change further down the line. Service oriented architecture embodies this principle since it anticipates further changes and allows new, interoperable services to be introduced in the future.

What PMs should know about microservices

Product managers don’t need to be experts by any means, but it’s probably good to understand the following concepts:

1. Microservices are a software architecture design pattern that involves breaking down a large, monolithic application into smaller, independent services that communicate with each other.
2. Monolithic architecture means the code base isn’t separated into independent, smaller services, but rather is combined into one, single application.
3. Microservices can offer many benefits, such as improved scalability, flexibility, and fault tolerance. However, they can also be more complex to develop and maintain than a monolithic application.
4. Product managers should carefully consider the trade-offs and potential challenges of using microservices before deciding to adopt this architecture for their product.
5. Don’t underestimate the work – Product managers should also be prepared to invest in the necessary infrastructure and tools to support a microservices architecture, such as containers and orchestration platforms. If you have a dedicated devops team they will lead the way on this.

Overall, product managers should have a good understanding of microservices and how they can impact the development and maintenance of a product in order to make informed decisions about their use.