Microservices: A quick and simple definition

Get a basic overview of microservices and then go deeper with recommended resources.

By Mac Slocum
March 1, 2018
Paperclips lined up on table Paperclips lined up on table (source: PDPics via Pixabay)

Curious about microservices?

The following overview is for you. It covers some of the basics of microservices: what they are, how they work, and what you need to keep in mind before implementing them.

Learn faster. Dig deeper. See farther.

Join the O'Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.

Learn more

This information is curated from the expert microservices material available on our online learning platform.

The characteristics of microservices

Sam Newman provides a succinct definition of microservices in Building Microservices: “Microservices are small, autonomous services that work together.”

In Microservice Architecture, authors Mike Amundsen, Irakli Nadareishvili, Ronnie Mitra, and Matt McLarty add detail to the definition by outlining traits microservice applications share:

  • Small in size
  • Messaging enabled
  • Bounded by contexts
  • Autonomously developed
  • Independently deployable
  • Decentralized
  • Built and released with automated processes

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.)

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.

How Fastly Navigates Microservices Pitfalls — This case study covers the lessons learned from building, testing, and deploying a functional microservice architecture.

Post topics: Software Architecture
Post tags: Resources

Get the O’Reilly Radar Trends to Watch newsletter