Are you ready for microservices? Pt 1: Need, alternatives, and ability

As a development team, our goal is to deliver software that solves business problems. The business’ goal is to provide value to the customers as quickly as possible. “Monolith to microservices” is not a business goal. Business stakeholders don't care about architecture choices. They care if their customers are getting the optimum experience.

Microservices can have business advantages, but many times companies overlook the disadvantages and tradeoffs. They also underestimate the inefficiencies and problems that are not directly related to the microservices transformation, but which often hold a project like this back. Some of these problems—such as business domain complexities and DevOps inefficiencies—have always existed, but were less visible because of the monolith’s singular view. Moving towards microservices means you are multiplying everything by the number of microservices, so any of these lurking issues may multiply exponentially.  

This raises some critical questions that business leaders need to address at the start: Are you ready to take on a microservices transformation? What are you doing it for? How will you ever get there? These are questions we can help answer.

The readiness spectrum

To address the questions above, we can divide the thought process into four categories: Need, alternatives, ability, and preparedness. The first is the analysis of the need: Is there a legitimate need for microservices? Should you even take on a microservices project? The second part is considering whether there are alternative options that are cheaper and easier. The third part is about honestly assessing your ability to carry out the project: Is your organization poised for changes and able to take on new processes? The fourth part, which we’ll address in Part II, is about meeting certain preparedness criteria. Once we start answering questions in all of these categories, our chances are better of successfully converting big ball mud into a set of microservices.

To start, let’s take a look at how we determine need, alternatives, and ability.

Step 1: Do you need microservices?

The first thing to answer honestly for yourself is, do you actually need microservices? Do the benefits outweigh the tradeoffs in your particular case? Many struggling projects I’ve been involved in have issues in this space. They are not 100% clear on what the benefits are and their business goals are not tied to the outcome of the project. It’s critical to know what the actual need is instead of blindly following an industry trend. There are a couple of considerations we look at to determine your microservices needs.

Scale

We need to build a detailed picture of what your scale needs are to see if microservices are a fit. Some questions we can ask are: How many users do you have today? How many concurrently access the system? Do you have strong ebbs and flows in usage? Do you anticipate the user base to explode in the near future?

We also want to understand what happens to the existing monolith when scale is achieved. Building strong observability into the application is helpful in understanding how the current application behaves. It helps us determine the baseline for the future, build tangible targets, and track progress. It becomes beneficial to have robust data around “why are we going it?” responses such as “the website is slow.”

These data points help us define the need for microservices. If the user base is small and not going to increase significantly, a change in the architecture type could be unnecessary. The complexities of a microservices approach may make the new solution a lot harder to maintain than the existing one.

Size of the monolith and maintenance

One rule of thumb is to check if the application can be easily reasoned and maintained by a “two pizza team.” How long does it take for a group of 5-7 people to push a change through to production? If this sized team can make sustainable change frequently, there is less value in re-architecting something—the cost of change could be higher than the reward.

On the other hand, sometimes the cost of change is well worth it. I worked on a monolith that was growing at a rapid pace: Over 50 developers made changes to it daily. When I started, there were about 60 projects in the solution. Over two years, the number of projects ballooned to 150. It was hard to wrap my mind around a 60-project solution, you can only imagine trying to make a change to 150-odd project solutions. That added more time to the changes that the teams were supposed to make. It was a slow and buggy process for everyone, which made this monolith a good candidate to break into smaller services, maintained by smaller teams. The cost of change became justified here because smaller code bases are easier to understand and maintain.

Step 2: Are there easier alternatives to consider?

Sometimes a simple re-platforming into the cloud can be more fruitful than a full-blown architecture overhaul. Simple scaling in the cloud of the application may be far more manageable for your current team. Once we have good data collected around the existing application, we can easily test this out: Cloud technologies are set up for quick experimentation and feedback.

Other alternatives, like simple modifications to the existing monolith, may be enough to get by for now. One idea that we like to bring in is events. Microservices or not, events can make a massive difference in decoupling and making areas of the application more robust. However, they introduce an idea of eventual consistency. If we can make this modification instead of taking on a huge overhaul, that releases some pressure on the system.

Step 3: Can you make microservices a reality?

In our experience, the business domain directly impacts the ability to take on the microservices transformation project. Sometimes, the domain is a lot more complicated than classic examples of eCommerce systems you see. Oftentimes, we see a variable degree of understanding of the business domain within the organization. A classic symptom of this is unclear boundaries between the business concepts.

Complications, or just disagreements about business concepts, will come back to haunt you during a microservices project. These are the boundaries that serve as guidelines to create individual services. If they are not transparent or clean, it reflects in the services. These services become very chatty; they tend to be fragile and tightly coupled. Microservices may add more confusion in here. If you’re considering switching to microservices, there is some significant upfront work that needs to be done, in this case. That begins with clarifying the business domain with domain analysis—Microsoft has good guidelines for that process. Some other techniques include value stream mapping and event storming.

So, are you ready?

We need to set clear business objectives before thinking about solutions or technologies. We should understand the scale needs and should have clear data to support our decisions. The questions you can ask during this process include: Is re-platforming to the cloud falling short? Is the codebase too hard to understand? Will it help to break it up? Can we reason the business domain? Can we differentiate one business context from another? If you answered “yes” to these questions, it may be beneficial to pursue microservices. In the next post, we’ll take a look at the things you need to have in place to prepare for a successful microservices transformation.