What is Considered a Single Microservice?
My name is Joe Martinez. I am a software engineer with an entrepreneurial background, and have been lately exploring microservice architecture for cloud-based solutions. This article is the first of several in which I will share with you some of my insights from my journey learning and mastering microservices from both a broad and deep perspective.
While I was first learning about microservices architecture, I started by looking for some basic definitions online. I was able to find many definitions of “microservices”, but the term was used synonymously with “microservice architecture”. The Wikipedia article has a pretty good basic definition which begins with:
Microservices is a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. In a microservices architecture, services should be fine-grained and the protocols should be lightweight.
This, along with other web articles, blog posts, and videos that I found, did a pretty good job of explaining what “microservices” are as an architectural style. I learned the most commonly accepted principles, the benefits, challenges, and pitfalls. However, none of them seemed to answer one basic question: What actually constitutes one single microservice?
Is a microservice:
A) A single function/method/HTTP endpoint?
B) A collection of CRUD (Create, Read, Update, Delete) operations on a single entity?
C) A reusable set of small functions that different parts of an organization can use?
D) A model for an entire department within a business organization?
E) A subset of related functions that said department may perform?
You may argue that we’re just arguing semantics. While this may be true, how we think about a term like “microservice” in the singular form can end up affecting how we architect our entire solution. I had several false starts while I started to design some simple microservice projects because I didn’t have a good grasp on what an individual microservice actually was.
Let’s explore the above definitions (A-E) in the context of a few commonly accepted principles of microservices and software architecture in general:
1) Multiple microservices should not share a single database. This is a very important principle upon which most authorities agree. Each microservice should own its own data. Shared databases introduce tight coupling between microservices, which is in direct conflict with autonomy, without which you really aren’t doing microservices. Now, let’s consider a Customer table in a database. You are probably going to have one function (an HTTP/REST endpoint if it’s exposed that way) to create a new customer, another to add profile details, another to change their email address, etc. Most likely, all of these operations need to touch the Customer table/database. If we were to consider each of these functions as individual microservices, they would be breaking the rule against database sharing. So, it looks like Definition A is not correct. I suppose you could technically get around this by designing a “microservice” with a single uber-endpoint that does several different things based on different JSON/XML payloads. But this would be ugly and not very consumer-friendly.
2) Microservices should be highly cohesive. Going back to our Customer example, we might reason that our Customer table is our entity, and we should create a microservice whose purpose is to perform the CRUD operations on this table (Definition B). In his book “Building Microservices” (O’Reilly), Sam Newman warns against this, referring to them as “Anemic CRUD-based services”. Besides your basic CRUD operations, there is likely specialized logic and additional processes that should occur when performing these operations. There are also probably a number of other operations that you will need to perform on a Customer entity beyond basic CRUD. In order to achieve a high level of cohesion, these should all be part of the same microservice. So, if you find yourself building a microservice that nothing more than a CRUD wrapper, it should probably be part of a more functional microservice instead.
3) Don’t Repeat Yourself (DRY principle). This principle is not microservices-specific, but a commonly cited principle of software development, formulated in the book The Pragmatic Programmer by Andy Hunt and Dave Thomas. DRY seeks to eliminate duplication of functionality by breaking out or extracting functions or methods that will be used in several places in your code. This can be applied to microservices, but you have to be careful. Traditionally, this would be done via shared libraries, and sharing libraries between microservices is generally discouraged, as they make it too easy to accidentally introduce tight coupling between services. On the other hand, there will be genuine cross-cutting concerns across your application, and do you really want to build emailing functionality, for example, into each individual microservice? One way to resolve this conflict is to use stable 3rd party libraries for these cross-cutting concerns, but there may be a genuine need for utility functions that are specific to your domain or aren’t available as 3rd party libraries. In this case, you can create these as their own microservices that can be consumed by your other microservices, as long as you are careful not to introduce coupling via exposing internal data, for example. So, Definition C becomes reasonable, but is only a minor part of the answer.
4) Domain-Driven Design (DDD) is an important concept in software engineering, formulated in the book Domain Driven Design by Eric Evans, where you define a “domain”, which is broken down into subdomains or “bounded contexts”. A complete discussion of DDD is outside the scope of this post, but in general terms, a “domain” is a “sphere of knowledge”. The book Building Microservices by Sam Newman has a good discussion of DDD in the microservices context. In Sam’s book, he gives an example where a domain could represent the concerns of an entire company, with the bounded contexts representing departments withing that company, such as finance and warehouse. So does one of these things correspond do a single microservice? Well, if you consider your domain as all the technological concerns of your business, then that would certainly be way too big to be considered a microservice. If you correspond a microservice to a department within a company (i.e. a warehouse microservice), that would be Definition D. Eric actually advocates for defining your microservices this way, at least when starting out, even though he admits that it is a bit monolithic. He then advocates eventually working toward more fine-grained microservices that represents smaller concerns, such as order fulfillment and inventory management by breaking them out later as your team gains more experience with the domain. This is more in line with Definition E.
You should also consider the complexity of your functionality and observe the Single Responsibility Principle when defining your microservice boundaries. If a single microservice is getting too big and trying to do too much, it is probably a good indicator that it should be be broken down into smaller microservices. How big is “too big” is subjective, and there are many opinions on the subject. You will get a better grasp on optimum granularity as you gain experience with microservices in general and also with specific business domains.
Summary
A good way to look at an individual microservice is as a collection of related functions or endpoints composing a bounded context within your business domain. Each microservice should be bound in such a way that it can own its own data and operate autonomously, communicating with other microservices via lightweight protocols only. The level of granularity can vary based on the complexity of the processes that you are modeling in your application. You can also have some general cross-cutting microservices to provide functionality required by multiple other microservices within your application, as long as you are careful not to use them to share internal data between services or otherwise introduce tight coupling.
I hope you found this article helpful in your own exploration into microservices. I would love to hear your opinions in the comments. Please share this article if you found it useful.
