Microservices should be small

Microservices are supposed to be small. But how small? Here are a few guidelines.

A strong factor in helping us answer ‘how small?’ is how well the service aligns to team structures. If the codebase is too big to be managed by a small team, looking to break it down is very sensible.

When it comes to how small is small enough ... think in these terms: the smaller the service, the more you maximize the benefits and downsides of microservice architecture. As you get smaller, the benefits around interdependence increase. But so too does some of the complexity that emerges from having more and more moving parts. As you get better at handling this complexity, you can strive for smaller and smaller services. (From Building Microservices)

Microservices are an alternative to monolithic systems

Large and centralized systems can present a host of challenges. A microservices architecture is an alternative style that aligns well with modern development practices.

Codebases grow as we write code to add new features. Over time, it can be difficult to know where a change needs to be made because the codebase is so large. Despite a drive for clear, modular monolithic codebases, all too often these arbitrary in-process boundaries break down. Code related to similar functions starts to become spread all over, making fixing bugs or implementations more difficult. ...

Microservices ... focus our service boundaries on business boundaries, making it obvious where code lives for a given piece of functionality. And by keeping this service focused on an explicit boundary, we avoid the temptation for it to grow too large, with all the associated difficulties this can introduce. (From Building Microservices, by Sam Newman)

Microservices are meant to be autonomous

Independence is an important aspect of microservices, so keep the following points in mind as you consider a microservices architecture.

[Microservices] need to be able to change independently of each other, and be deployed by themselves without requiring consumers to change. We need to think about what our services should expose, and what they should allow to be hidden. ...

The golden rule: can you make a change to a service and deploy it by itself without changing anything else? If the answer is ‘no,’ then many of the advantages [of microservices] will be hard for you to achieve. (From Building Microservices)

Microservices have trade-offs

Make sure you go into microservices with your eyes open. There are trade-offs you need to address.

In a microservice architecture, the services tend to get simpler, but the architecture tends to get more complex. That complexity is often managed with tooling, automation, and process.

Ultimately, you must come to terms with the fact that asserting control and management of a microservice system is more expensive than in other architectural styles. For many organizations, this cost is justified by a desire for increased system changeability. However, if you believe that the return doesn’t adequately outweigh the benefit, chances are this is not the best way to build software in your organization. (From Microservice Architecture)

Learn more about microservices

Ready to take the next step with microservices? Check out these resources.

Building Microservices — Get a holistic view of the topics that system architects and administrators must consider when building, managing, and evolving microservice architectures.

Microservice Architecture — Learn how to take advantage of the microservice architectural style for building systems, and learn from the experiences of others to adopt and execute this approach most successfully.

Production-Ready Microservices — Learn how to design microservices that are stable, reliable, scalable, fault tolerant, performant, monitored, documented, and prepared for any catastrophe.

Event-Driven Microservices — Software developers and architects turn to microservices to improve the agility and velocity of their development efforts. But is it the right approach? This video presents a balanced view of the benefits and drawbacks of microservices.

Mac Slocum is Director of Content Marketing at O'Reilly. He's been writing, editing, and producing web content in various forms since the mid '90s. He also dabbles in video interviews from time to time.

Faced with business and regulatory complexity, Scott Shaw found himself committing some of the software development acts he once condemned. He confesses those sins and explains why they’re sometimes necessary.