Do you REALLY need Microservices?

Do I really need microservices?

Maybe? Probably not, but honestly, “It Depends™“. I’ll answer your question with a question of my own.

Why do you think you need to do microservices?

”I read about it on social media/trade magazines/some giant company.”

I call this Cargo-Cult-Driven-Development (CCDD) and it’s rarely a valid reason for such a tectonic shift in your architecture AND development practices. “If GoogFlix and MicroBook jumped off a bridge, would you do it too?"

"My development team says we need to stay current.”

This one is likely because of Resume-Driven-Development (RDD), which is ALMOST as bad a reason as CCDD, but it does show a hunger for growth among your team members, so maybe work with them and get creative. Find a way to explore the idea without derailing all the work you’re being paid to do.

”The app is slow and getting slower, and it’s hard to maintain.”

This might show a need for careful decomposition.

”I’m building a new app that needs to do some of the same things as my current app.”

This could justify splitting things out, but let’s not be hasty. Distributed Applications add some hefty challenges.

Challenges of Microservices:

1. Deployment Complexity:
   Instead of deploying one unit, you’re dealing with multiple pieces simultaneously. This requires automation and DevOps practices.
2. Need for CAREFUL Abstraction:
   You need to get your abstractions correct before pulling your codebase apart. This often requires an application architect.
3. Increased Cognitive Load:
   Microservices require improved observability, security considerations, and deployment strategies that you might not be used to.

What about an alternative? The Well-Factored Monolith:

Instead of jumping straight to microservices, consider a well-factored monolith.

This approach involves:

1. Compose your monolith as if it’s a distributed system
   Get good at those abstractions.
2. Define clear boundaries between components
   Get good at determining and enforcing domain boundaries.
3. Set up patterns for inter-component communication
   Add observability, improved validation, and APIs between your components now.

Start doing those things, and you’ll see these things emerge:

1. Ability to iterate on parts without affecting the whole system
   You’ll still need Big-Bang deployments, but the testing scope can be reduced.
2. Easier distribution of responsibilities among smaller teams
   When things are well defined and separated, different groupd can work in different parts of the application without merge conflicts.
3. Improved testability of individual components
   If only one part of the application changed, only the parts that are affected need to be tested.
4. Flexibility to extract services later if needed
   If your internal components are kept independent of each other, you can split them out and replace a concrete implementation with a service proxy pretty easily.

When to Consider Breaking the Monolith:

1. High levels of code churn within a component:
   If a part changes much more often than the rest, it might be a candidate for extraction.
2. Significant code duplication:
   Consolidate shared code, but be prepared for divergence over time.
3. Need for separate process spaces:
   Some activities might benefit from running in their own process, such as long-running tasks or those accessing limited resources.

Conclusion:

Microservices can offer benefits, but they come with significant challenges. Start with a thoughtful, resilient, and composable application architecture strategy. The well-factored monolith provides a solid foundation, allowing you to evolve your architecture as needed.

Remember, distributed systems bring their own complexities in troubleshooting, state management, and security. Ensure your team is prepared for these challenges before making the leap.

The bottom line: A poorly factored Monolithic Application WILL become a Giant Ball of Mud. A poorly factored Microservice Application devolves into the Painful Tangle of Barbed Wire. It’s all about the internal component design, and your team’s commitment to protecting that design.