When to Use Microservices: Sam Newman and Martin Fowler Share Their Knowledge

by Jeremy H • May 3, 2021

Laptop screen displaying information about when to use microservices

What happens when two legendary microservices thought leaders, Martin Fowler and Sam Newman, meet to have a conversation about microservices development strategies? We gain a wealth of cutting-edge perspectives on microservices strategy in a short amount of time. Below, we discuss the app development perspectives that Sam Newman offered when Martin Fowler asked a seemingly simple question: “When should you use microservices?

Make Sure You Have a “Really Good Reason” for Implementing Microservices

When an app development use-case requires high levels of scaling and unprecedented development agility, the microservices architectural style can resolve the dependencies in monolithic apps that impede scaling and agility. However, as Martin Fowler points out in a recent conversation with Sam Newman, microservices leaders spend a lot of time talking about when you should not use microservices, but they don’t always say when you should consider using this app development strategy.

Newman addressed this point by saying that developers should only consider using microservices when they have a “really good reason” for doing so. He says that developers tend to focus too much on the latest tech tool (such as microservices) as an ideal that must be implemented without considering the reason for implementation. Instead, Newman recommends that developers focus on the result that the tech tool allows them to achieve. In this respect, Newman says that developers need to make sure they have a practical purpose for using a particular technology before paying the time and financial costs of implementation.

As Newman says: “A microservices architecture is a conscious choice you have made to implement something in that style because of some outcome you’re looking for. There is some benefit that you think a microservice architecture is going to give you. So my qualifying criteria is: What is the thing that a microservices architecture is going to give you?”

The Most Compelling “Things” That Microservices Offer

The most compelling “things” that microservices architectures can give you include:
1. Additional options for scaling up applications
2. Independent deployability
3. Help isolate the “blast radius” of service failures
4. Allows developers to “buy into” a new series of options and choices that app developers can make

According to Newman, microservices allow you to “buy into” a series of options, and we all want the additional options that microservices bring. However, he reminds us that we are literally “buying into” those options, i.e., there is a cost element, work element, and time element to microservices app development. Therefore, we need to make sure that the results we hope to receive from the microservices architecture are clearly going to be worth that cost.

Start With Small Changes and Keep the Single-Process Monolith as Your “Default”

Newman makes another point that developers often overlook. He says that developers define the microservices architecture as a “distributed” system, and therefore better than the monolithic design. However, Newman reminds us that monolithic architectures are -- actually -- distributed systems too: “If you think about a normal single process monolithic application, or if you’re reading data from a database on a separate computer, that is a distributed system. If you’re putting data from that process into a browser, that is a distributed system. It’s just a really simple one. So my default is absolutely to look at a really simple deployment topology -- a single process monolith -- and if I think a service-based architecture could be a good approach, I’m just going to try out one of the services as a microservice.”

Newman says that his default is a single-process monolithic application with a simple deployment topology. He says that this architecture sidesteps a lot of deployment complexity and other issues in the beginning. At the same time, he says that if you’re interested in trying microservice, you shouldn’t view it as a massively complicated undertaking -- and they shouldn’t try to do everything at once. He warns against becoming an organization that decides to do microservices and spends the six months rebuilding their entire system from the ground up. In contrast, Newman recommends that organizations simply try turning a single module from the monolith into a microservice and see how it works.

Newman adds, “Let’s make my system a little bit more distributed, just a little touch, and see what that does. Can I deal with it? Can I side-step the issues of ‘horribleness’ that come from distributed systems, and do I get some benefits out of it?”

Top 3 Reasons Why Organizations Should Leverage Microservices

With all of this in mind, Newman points out the following top three reasons why organizations should leverage a microservices architectural style:

(1) A Need to Independently Deploy New Functionality with Zero Downtime

Microservices are extremely useful when an organization needs to make a change to functionality -- and deploy that functionality in a way that the rest of the system doesn’t have to change. This allows a microservices architecture to deploy new functionality without any downtime. The need for zero downtime deployment would certainly apply to a SaaS-based business where the organization needs to keep its software products up and running at all times.

(2) A Need to Isolate Specific Data and Data Processing Through Data Partitioning

Many organizations, such as those in the healthcare and financial industries, need to protect PHI and PII information. They also have to adhere to specific data security and compliance standards (such as GDPR and SOC2). Implementing “the right to be forgotten” is another common concern. In a microservice architecture, you isolate the data and the processing that acts on that data, allowing you to achieve data partitioning. This makes it easy to delineate which services touch PII information and require greater oversight, governance, and auditing.

(3) A Need to Enable a High Degree of Team Autonomy

Sometimes organizations need to distribute responsibility into teams, where each team makes decisions and develops software autonomously. When teams need to work independently without close coordination, a microservices-based architecture offers a structure that pushes this kind of autonomy within the organization. According to Newman, a microservices architecture puts hard barriers in place that necessitate the formation of this kind of team autonomy.

Martin Fowler added to this perspective with the following point: “Organizationally, that is certainly when I talk about microservices to people, that’s the area that I tend to focus on more. That as team size increases, it’s exponentially harder to coordinate people […] So you need to set up barriers, and microservices kind of forces you into an awkward way of working -- which is actually what you need with a bigger team anyway.” For more reading on this topic, check out this DreamFactory post, where we outline the microservices journeys of Amazon, Netflix, Uber, and Etsy.

Reduce the Cost, Time Commitment, and Complexity of Implementing Microservices

One of the most important points that Sam Newman drives home in this discussion is the need to analyze the practicality of implementation before going completely down the rabbit hole to develop a full-fledged microservice-based system. In other words, breaking your monolith and developing and integrating microservices is an expensive and time-consuming undertaking, so it’s important that the benefits of microservices are worth the cost.

This “cost-benefit” element is a vital consideration that has impeded many small to medium sized organizations from being able to reap the numerous benefits of a microservices-based app architecture. In many cases, the enormous benefits of microservices app development were too expensive for smaller companies to afford. Fortunately, with advanced API management tools like DreamFactory, microservices development is easier and more affordable than ever for small to medium sized firms.

At DreamFactory, our API management and REST API generation solutions empower teams to completely eliminate a large amount of the developer time and massive financial expenditures associated with microservices. By helping developers bypass the time required to develop custom APIs and manage API connections between the different services that comprise a distributed architecture, DreamFactory is making microservices more practical and cost-effective for a wider range of users.

For more reading on microservices development, you might enjoy this recent blog post, which discusses how the latest API management solutions from DreamFactory are making it easier for businesses to start projects as microservices for certain use-cases.