Unless you’ve been living under a rock in recent years, you’ve probably heard of microservices. For the other three of you, with a microservice architecture you build small, independent applications that work together to solve the larger business process or problem.

There’s a lot to like about microservices.  In the past three years or so that I’ve been working with the idea, I’ve learned a lot about how to make the pattern work well. It’s not perfect, but there are a lot of benefits to this architecture.

Maybe you’ve heard of microservices and dismissed it as just a fad. While there is always some hype around the next “big” thing, I think microservices are here to stay in some form or fashion.

On the other hand, perhaps you agree that microservices are the way to go, but you’ve had trouble articulating to management why your company should make the shift.

For me, there are three main reasons why you should make the shift to a microservice architecture:

Reduced Risk

If microservices did nothing else, this one thing alone would be worth the effort to switch over.

Microservices reduce risk.

Whether you’re talking business, investing, or software development, risk is a big deal. Financial folks are always looking at the risk profile of an investment to determine how to get the biggest return with the lowest chance of losing money.

All software has risk associated with it. Every time you add a new feature, there’s a chance that something else accidentally breaks. Each time a change is made to production systems, there is a non-zero probability that it will negatively impact the running systems. Even if nothing is changed and the software is running fine, there may be a slow memory leak or it stops performing well as the volume of data increases.

Microservices reduce the risk associated with nearly everything you do to production systems. Here are just a few of the ways that microservices do this:

• Smaller Scope. As the name implies, microservices are typically small. This means that a small piece can be upgraded or rebooted without taking down the entire system.
• Testable. Microservices are, typically, easier to test. Because it’s a separate application, the boundaries between services are better defined. This limits the boundaries of what needs to be tested, allowing the tests to be more robust. When services are easier to test, the probability of introducing a problem into the production environment goes down.
• Automated. As the number of microservices multiply, it becomes untenable to manage and deploy them manually. This means you will need to build automated tools to build and deploy new versions of your services. Introducing an automated process for deployment reduces the chance for human error, making deployments less risky.
• Reversible. If something goes wrong, the rollback plan is usually simple: revert to the previous version of the microservice, no big deal. In a monolithic system, reverting to the previous version is a solution of last resort, as it also reverts code completely unrelated to the problem area.

In business, calculated risks are necessary in order to get ahead. But deploying software should not be one of them. Microservices help mitigate that risk.

Independent

Another big microservice benefit is that they are built and run independently of each other. As long as you maintain the publicly facing contract, all is well.

This independence provides several advantages over a monolithic application. In particular, independent microservices are:

• Scalable. Ever had one particular page or API endpoint get slammed and take down the entire site? With microservices, if you see increased load on a particular service, you can scale out just that service with much fewer computing resources than would be needed for a typical monolithic application.
• Releasable. As mentioned earlier, it’s easier to release the service in a rolling fashion, so you never experience downtime. In addition, it’s easier to do “canary” deploys where you introduce one instance of the new service and then roll it out to the rest of the cluster when all looks good.
• Ownable. The size of the service means that a single, small development team can oversee and manage the lifecycle of the service. Aside from conversations about the public API, the team doesn’t need to consult with others about the design and implementation of the service. As a result, teams can move faster to deliver value to the end users of the system.
• Flexible. If the team decides that Mongo DB is a better data store than a relational database, fine. Want to scrap the whole thing and rewrite it using Spring Boot instead of Node.js? No problem. While there are reasons to standardize on common platforms, microservices give you the flexibility to solve individual problems with the technology that makes sense. A monolithic application, out of necessity, has to limit the technology choices available to avoid becoming too bloated.

In leadership, the best managers let those closest to the problem make the important decisions. A microservice architecture allows each microservice and the team that manages it to make the appropriate technology decisions.

Understandable

Finally, microservices are easier to understand. Because of their limited scope, developers don’t need to understand the entire system in order to be productive. Because each service is a separate application, it’s easier to define and enforce the domain boundaries between services. This separation of concerns is always better for the architecture, but it makes it easier to reason about each part of the system, independently from the other parts.

The size of the service also limits the number of technology choices to understand. In a monolithic application, you have to worry about all of the technology choices used by all of the pieces of the application. If nothing else, just to keep from bumping into each other or introducing the same technology twice. With its smaller scope, a microservice can make the technology choices that make sense, as long as it doesn’t impact the overall microservice ecosystem.

When the service is small enough that it is “no bigger than your head,” you don’t need a room full of whiteboards to visualize it. This means fewer unexpected behaviors, the ability to write better tests and ultimately reduced risk. (Yes, we’ve come full circle)

Microservices to the Rescue

Are microservices the answer to all software development ills? No. Microservices aren’t exactly a free lunch (I’ll address this in a future post), but they do solve a lot of problems related to risk, team independence and reduced complexity.

If your application has become too big and unwieldy, microservices may be the solution. Keep these microservice benefits in mind as you design and advocate for a better tomorrow.

Question: What are the benefits you see in a microservice architecture?