Meandering Our Way Though the Microservice Architecture: Overview

Overview

Microservice architecture is all the rage these days. With a plethora of blog posts, books, lectures, and conferences on the topic; exploding over the past few years. With that said, I'm going to jump on the bandwagon with a post of my own. Drawing from my experience as the product owner for the first microservice built at my current employer and information that I heard while attending Code Freeze 2018: Microservice Architectures.

Microservice architecture is often seen as the conceptual antithesis of the monolith architecture.

In a monolith, all of the code to support an application is shipped as a single package. One god executable that is capable of performing all aspects of the application. To archive scale with a monolithic application, one simply deploys multiple copies to production. Via configuration, some copies can handle more of one responsibly that another, but every single node is fully capable of performing any function in the system.

In contrast, a microservice application is composed of dozens or hundreds of "small" services. Each performing a single specialized task/ owning own area of responsibility. To archive scale, each microservice could consist of several redundant nodes. There might be three login microservices running and only a single tax calculator service. With the number of nodes controlled by the current level of demand.

The thing that makes a microservice, "micro", is not strictly the size of the application. But rather the number of responsibilities assigned to it. A microservice should be responsible for one thing, and do that one thing well.

Benefits

Any software developer can enumerate all of the benefits of building small testable software packages. Almost all of those arguments apply directly as reasons to build a microservice.

Simple A Microservice should be responsible for a single function. Therefore, it should be straight forward to reason about the different responsibilities that function entails, and about the different methods of failure that could be encountered. You do not have to reason about the entire software ecosystem, you only have to worry about your immediate dependencies, your datastore, and the code that runs the specific service. Any other service that is more than one hop away can be ignored.

Testable The microservice architecture demands a high degree of automated test coverage.

Isolation A microservice is self-contained. It depends on its datastore, and an API version for other microservices. When you need to deploy an update to one service, none of the rest of the services needs to be restarted, or in most cases, even notified. Simply stand up the new instances, and then cut over traffic from the old cluster to the new cluster. There is no need to coordinate releasing updates from one service with all the rest of the services in the network.

Scale Up Only What is Needed As demand increases, simply launch more nodes to maintain a seamless experience for your users or the other services. As demand wanes, the number of nodes can be decreased to save on costs. If demand is only high for one portion of your overall application, only that one part needs to grow. The order processing nodes can grow in number to support a flash sale, while the tax calculation service cluster can remain small to save on costs.

Drawbacks

As with any architecture or design pattern, there are drawbacks. The microservice architecture is no exception.

Networks of Services Often a deployed application is supported by dozens or even hundreds of microservices. Debugging the source of a problem can be challenging.

Failure Management Services need to be built with more attention to failure. As a monolith, if the application is running, one can be almost certain required dependent services are running an available. In the world of a microservice, any one dependency could be offline, making you unable to complete the requested task at hand. The possible failure of each call outside your boundary should be taken into consideration and accounted for.

Monitoring Each service needs to be monitored. To ensure the application is performing as expected and is healthy. To auto grow or shrink the cluster in response to demand. In the case of an application with 50 microservices, there needs to be 50 monitoring solutions, 50 dashboards, and 50 alerting services to get the attention of devops should something go wrong.