7 Microservices Benefits and How They Impact Development

The microservices architecture has existed since the turn of the century, but it has only gained wider adoption in the last few years. As with many paradigm shifts, change requires an impetus. Why use microservices? This post will give an overview of key microservices benefits that have contributed to their popularity, as well as point out a few situations for which they are not well-suited.

Definition

What is a microservice? A service, put very simply, is some code that performs work. Micro purposely suggests small in size. The small size concept of a microservice is fundamental to the design. When I first began working with microservices in 2015, I struggled to determine “how small?” I realized I needed to understand how a microservices architecture was structured, how it should be implemented, and how it was intended to be used. I hope that sharing what I have learned will help you on your journey into microservices.

Characteristics

The following characteristics describe the fundamental building blocks of a microservices architecture which are necessary to meet the design goals and obtain its benefits. We’ll refer to these throughout the post. Each microservice should be: 

• Independently deployable - e.g., the front-end service can be deployed independently of the authentication service
• Highly observable - through logging, monitoring, tracing, etc, one can determine what the service is doing
• Loosely coupled - the service can perform its work without being overly dependent on how any other service is defined or implemented
• Decentralized - spread across many different “systems,” potentially across many different geographies
• Highly testable - developed from the beginning to be testable through automated test frameworks with high coverage rates
• Highly maintainable - well-structured, well-commented, easy to understand, easy to change, easy and fast to build, etc (small size helps with all of this)
• Fungible - easily replaced or reimplemented as requirements dictate
• Focused and specialized - similar to the Unix philosophy of “do one thing well”
• Contractual - having regimented, well-defined interfaces with deliberate life cycles

Monolithic architecture has existed for a long time and has proven successful. Why introduce another architecture? Let’s review differences between microservices and monolithic architectures.

A general rule of thumb is there is at least an order of magnitude more moving parts in a microservices-based application than a monolithic application. In addition, each microservice typically runs in a separate process, is potentially distributed across different systems, and is not necessarily dedicated to any particular application. Finally, each microservice will talk to other microservices to perform work, i.e., directly via REST API, over a message bus, or a number of other protocols, depending on implementation.

In contrast to microservices, a monolithic architecture-based application consists of fewer and larger parts, perhaps running as a single process (with no or very little process to process communication). A monolithic application is typically described as a discrete unit instead of the parts that make it up, with those parts dedicated to that application. Desktop and mobile applications are good examples we use every day.

One architecture doesn’t fit all situations, and this post will help you assess whether the benefits of a microservices architecture fits your needs.

Let’s go back to the characteristics stated at the beginning of this post. Why were these the design goals for a microservices architecture? Why are these characteristics needed?

The public cloud changed software forever. Delivering software via disc every couple of years became obsolete. Why bother installing software on your PC when you can rent the software in the cloud? Software as a Service was born, but running a 24x7 cloud-based service introduces a whole new set of considerations in stark contrast to periodically delivering a product on disc.

Economy of scale expects many customers to use the cloud-based service at the same time, all the time, all over the world. So not only does the service need to scale to meet demand, but customers using the service won’t tolerate downtime. Additionally, whether to meet customer needs or provide functionality before a competitor, delivering features and fixes quickly is key to success. Ensuring your microservice is container-ready and following these microservice best practices can help teams achieve these objectives.

This section will cover seven important microservices benefits and how they are made possible by the characteristics described at the beginning of the post.

1. Asymmetric Service Scaling
2. Zero Downtime
3. Intelligent Deployment
4. Innovation Through Polyglot Programming
5. Refactoring, Rewriting, and Decomposing
6. Separation of Logic and Responsibilities
7. Error Handling and Resiliency Design Patterns

1. Asymmetric Service Scaling

A company deploying software to their own intranet will have some known, upper bound on the maximum number of concurrent users. The software designed for that use case often has similar upper bounds on scalability. Conversely, a cloud-based service must scale to many users at many different companies using the software at the same time, perhaps orders of magnitude more users than a single intranet-based deployment.

One of several microservices advantages is that it is well-suited for massive scalability, as each microservice can scale independently. To achieve this goal, the service must be “independently deployable” and “decentralized” to meet demand. A “highly observable” service provides metrics which can be used to drive scaling operations.

In addition, as the services scale in and out based on demand, underlying host resources can also scale in and out, thereby utilizing those resources more efficiently. This is in stark contrast to a dedicated company intranet deployment where resources may sit idle during low demand.

2. Zero Downtime

A direct follow-on from above, another benefit to microservices being “independently deployable” is zero downtime. A new version of a microservice can be incrementally rolled out, coexist with the old version, and eventually replace the old version.

Of course the service must be written to support this use case. Being stateless helps, as well as being “highly testable,” so as to confirm the new service is operating without any regression before completely replacing the old service.

3. Intelligent Deployment

Kubernetes is an open source orchestration tool that automates container deployment, scaling, and management (see below for more discussion of microservices and containers). Using a service mesh-enabled Kubernetes platform, canary testing of coexisting versions of a microservice is easily achieved. Weightings, HTTP headers, or a number of other criteria can be used to shape or route traffic to slowly ramp up work to the new service in a controlled manner. Unwanted behavior can be detected before the old version is completely replaced. If tests fail, a rollback to the old version of the microservice restores expected behavior.

4. Innovation Through Polyglot Programming

Let’s say a team is joining a project to introduce a new feature that will be very attractive to end-users. This existing project is written mostly in Go, but the new team consists mostly of node.js programmers. "Loosely coupled" and “contractual” microservices provide the ideal environment for a polyglot programming model as teams can choose whichever language they prefer in order to produce the new feature quickly. Since speed to market can be a huge business differentiator, this is another key microservices benefit.

It can be debated whether mixing languages may have disadvantages. However, if a particular team is much more familiar with one language than another, it is also much more likely that they’ll write “highly maintainable” code in that familiar language.

Or maybe teams are just interested in trying new technology and are willing to experiment with a new language. If that experiment doesn’t work, no problem--microservices are “fungible” so just rewrite the microservice.

5. Refactoring, Rewriting, and Decomposing

In the aforementioned polyglot programming model, a legacy, monolithic application can be decomposed into microservices over time. This incremental progression enables the other benefits of microservices while the legacy application is still being phased out. 

See Analyzing Polyglot Microservices for a more in-depth look at polyglot programming in a microservices context.

6. Separation of Logic and Responsibilities

Very large projects are usually very complicated. No one team can know everything. Furthermore, for compliance or security purposes, teams may be purposely cordoned off from other areas of the project. A “loosely coupled,” “independently deployable,” “specialized,” and “contractual” microservice allows teams to focus their efforts on the business logic in their area of expertise or access.

7. Error Handling and Resiliency Design Patterns

It is a fact of life that failure is unpreventable, so if you fail, fail small. The circuit breaker pattern is often used to prevent systemic failure due to a root cause in an isolated component. As microservices communicate with each other to perform work, one way to introduce the circuit breaker pattern is to insert control points between the microservices. As an example, a service mesh-enabled Kubernetes platform provides built-in mechanisms to introduce circuit breakers and leverage the benefits of microservices.

Containers are the perfect vehicle for delivering microservices. Why? Keeping the Unix philosophy of “do one thing well” in mind, a container specializes in providing a compact, complete, portable, and immutable runtime environment for a process (in this case a microservice). All dependencies, libraries, and runnable code are bundled into a discrete, versioned package. Through abstractions that hide details of the target platform, a container can run on a variety of different systems enabling “decentralization,” which is one key quality of a microservice. A container should package just one microservice to ensure the microservice is “independently deployable,” “fungible,” and “loosely coupled.” Given the “focused and specialized” nature of a microservice, a large number of microservices is typical, and thus a large number of containers is also typical. 

Running many containers requires a container orchestration platform not only to manage the lifecycle and resource consumption of the containers, but also to introduce observability, resiliency patterns, and rapid deployment. A Kubernetes platform can help teams take advantage of all the benefits of a microservices architecture as part of a holistic container management strategy. 

It’s important to understand both pros and cons when considering if a microservices architecture is right for your organization. We discussed microservices advantages above. Here we’ll cover a few perceived problems with microservices.

Earlier we discussed the size of a microservice and how that shapes its scope. Taken to an extreme, a microservice can be too small. If a microservice is too small, it may spend most of its time communicating with other microservices, introducing latency and generally just thrashing. In turn, other microservices can be slowed by this thrashing as well, especially if using a message bus for inter-service communication as the bus will become saturated with messages (in this case a circuit breaker pattern can help, but is likely just a crutch so beware).

Microservices running in containers that are managed by a Kubernetes platform can be complicated to set up. A project must be large enough to justify the overhead required to manage the microservices, deployment automation, and infrastructure. Again, size can be arbitrary. If the team(s) working on the project feel they understand the entire scope of the project well enough, chances are a simpler, monolithic architecture may be better suited. However, if you anticipate a large, complex project with lots of uncertainty, the benefits of a microservices architecture may suit your purposes perfectly.

Finally, some teams find the loosely coupled nature of microservices to be an information barrier. If a microservice was implemented with insufficient observability, determining what it does can be complicated. Service meshes are great for introducing observability, but like all powerful tools, if used incorrectly, service meshes can introduce enormous complexity and unintuitive behavior.

Today’s accelerated rate of technology adoption necessitates a flexible platform that facilitates adoption of new ideas and concepts. Microservices enable rapid development in smaller, easier to manage units of change. While this architecture pattern won’t be right for every team, there are many microservices benefits that, when leveraged appropriately, can contribute to improved innovation, productivity, business logic scoping, resilience, and high scalability for your organization.