What Is a Microservices Architecture?

This blog post was adapted from our new book “Redis Microservices for Dummies” by Kyle Davis with Loris Cro. Here’s how to download the complete volume, or check out another excerpt on how Redis fits with a microservices architecture.

Reading the words “microservices architecture” might give you an intuitive idea of what the term means: small services in a computing architecture. That definition isn’t exactly wrong, but it’s also not completely correct. 

Microservices architectures are often referred to as a way to “break the monolith.” Sadly, this has nothing to do with 2001: A Space Odyssey, but rather the concept of breaking (or decomposing) a single, large program into pieces.

You may also like: What Are Microservices? An Introduction to Microservice Architecture

So the microservices architecture is all about creating small programs (microservices) from a whole. The result still needs to behave like a single entity at times, while at other times it needs to have the properties of many smaller programs.

A good metaphor might be the HVAC (heating, ventilation, and air conditioning) system in your home. This system might consist of a furnace, air conditioner, humidifier, thermostat, and fresh-air exchanger. Critically, you never go directly to the humidifier or furnace and flip a switch to turn it on. Rather, you adjust the thermostat, which then controls all of the component systems—you don’t need to know anything about the individual parts. Each individual system comes in a box from its manufacturer, and yet are all connected together to act as a single unit. You can swap out the gas furnace for an electric model and the operation stays the same for the end user.

In this metaphor, each HVAC component is a service, and the whole design of your HVAC system is your microservice architecture.

Of course, microservices architectures are far more dynamic and complex than HVAC systems. Cloud instances go up and down and new versions are deployed sometimes many times per day. A microservices architecture might have thousands (millions even!) of inputs and perform many extraordinarily complex activities that compose the entire functionality of your application

The Advantages of Microservices

Of course, including so many services introduces complexity, which is generally considered to be the primary foe of good software. But the alternative is worse. 

In a monolithic architecture, everything is contained in one large unit. In a monolith, when something breaks, as even the best software inevitably does, everything breaks. Even lean software projects, over time, tend to grow in complexity—adding more and more features and workarounds until you end up a hulking, unwieldy monster. Updates and releases become increasingly slow and painful. And when something breaks, as inevitably occurs with even the best software, everything breaks.

In a microservices architecture, an individual service concerns itself only with minimal responsibilities. If a single service develops a problem, it’s much easier to rewrite that single service than rewrite and merge-in a fix to the entire monolith. 

Plus, just as critical, problems tend to arise when you try to scale a monolith. One part of the monolith may be particularly resource intensive, but you typically can’t scale an individual part of the monolith—you have to create replicas of the whole system, which wastes resources. In extreme cases, monoliths aren’t built for replication, creating hard limits on scale.

Services are simply easier to build and manage. The microservices architecture isolates complexity, allowing smaller, more agile teams to create a service. You may have heard about the efficiencies of two-pizza teams, or teams small enough to be fed with just a couple of pizza pies. A microservices architecture lends itself to being built by a large number of two-pizza teams.

Finally, a microservices architecture is more flexible. Individual services can leverage a variety of platforms, languages, and tools, since these choices affect only a small team at one time. As long as the inputs and outputs aren’t affected, developers in these teams can move fast without breaking things.

Where to Use Microservices Architectures

While using a microservices architecture can bring big benefits in many situations, it isn’t right for every situation. Microservices architectures tend to do best in environments with: 

• A large code base. A small code base will probably derive less benefit from being split up into logical services.
• Enough developers to create teams devoted to individual services. Many advantages of microservices architectures are lost if the whole team works on one service at a time.
• An operational team able to support the many services in the architecture. Despite the long-term operational benefits of a microservices architecture, at the start it can seem like a lot more work to run many servers or instances than a single large one.
• Well-defined underlying business processes. Someone with a knowledge of the business should be able to look at an architecture diagram and see the mapping. On the flip side, if the business processes are ad hoc or poorly delineated, this messiness will be reflected in the architecture.

Read more about the microservices architecture and how Redis plays a critical role in our new e-book "Redis Microservices for Dummies."

Further Reading

Top 5+ Microservices Architecture and Design Best Practices

What Are Microservices?

Microservices Architecture: The Importance of Centralized Logging