If you’ve worked at a software company recently, you have probably heard the phrases “monolith to microservices” or “service oriented architecture.” If you’re a Product Manager without a technical background, this might be hard to wrap your head around. As someone who has experience with this architectural transition both as a software developer and as a Product Manager, my goal is to explain it so that you understand the business/user/roadmap implications. This post is going to be broken into 2 parts over 2 weeks: this week, I will explain what “monolith” and “microservices” mean. Next week, I will talk about why people are making the transition and how you can create a roadmap for it.

So, what is it? A monolithic architecture is where all the code lives in the same place and is run together as one application. A (micro)-services architecture is where the code is split into many independent pieces that talk to each other and can be developed and run separately. Neither is necessarily better than the other – they both have a balance of benefits and potential problems. Some benefits of a monolithic architecture are:

• It is easier for developers to try out their code, because they can build and run the whole app on their computer (assuming the monolith isn’t too big, which sometimes it can grow to be)
• It is more straightforward to build and run the app
• Debugging is easier and can be done in local development environments
• It is easy and fast to get data you need from other parts of the application

In this diagram, you can see that while all the code is living in the same large container, the different areas of code (domains) are well-defined and communicate in neat patterns.

Some potential drawbacks to a monolithic architecture are:

• The application can become very large and take a long time to build and run tests
• The code gets very complex and difficult to work with when you’re pulling in data from many other parts of the app without care (if you have ever tried to make a small change on one page, and had it cascade to an unexpected bug on an unexpected page, this is probably why)

In this diagram, you can see some antipatterns that can form: the domains are not well-defined, and don’t communicate with each other in set, expected, predictable ways. If you wanted to add a payment method, for example, would you add in “Checkout and User Profile Payment Info,” “User Profile,” both?

On the other hand, benefits of a services-oriented architecture include:

• Teams can make releases as frequently as they’d like without impacting other teams
• It is easy to make changes, because the codebase for a service is (hypothetically) kept small and simple
• It is easier to uphold boundaries between different parts of the code, since they don’t live in the same place, so you can be more confident that one change won’t cascade to unexpected changes elsewhere

When a monolith is structured well with strong domains, those domains can be split out into their own services.

Some potential drawbacks to a services-oriented architecture are:

• Different parts of your application now need to make network calls to each other, which is slower
• If you’re not careful, you can end up with a “distributed monolith,” where you have the same complicated dependencies but now over a network (even more complicated to try to debug and develop on)

The antipattern for services looks very similar to the antipattern for monoliths, just distributed over a network instead of encapsulated together.

Why might this be the direction your company is going? Going from a monolith to microservices is popular in companies that started with a single codebase but grew a lot, accrued a lot of technical debt, and now are feeling slowed down by that technical debt. The anti-patterns in a monolith are solved by the potential upsides of the services, so in theory that’s a good direction to go. In an ideal end state, you will be able to deliver new features and value to your end users at a greater velocity. 

Next week, I’ll talk about how you can work with your engineering team to create a roadmap for this work.