What are microservices? Your next software architecture

Nearly every computer system performs multiple tasks using shared resources, and one of the questions of computer programming is how closely the bits of code that perform those tasks should be tied to one another. An increasingly popular answer is the concept of a microservice—a small, discrete chunk of functionality that interacts with other microservices to create a larger system.

Although the basic idea of having such discrete components isn’t new, the way microservices are implemented makes them a natural foundation for both modern cloud-based applications. Microservices also dovetail with the devops philosophy, which encourages rapidly and continuously rolled out new functionality.

What are microservices?

The “micro” in microservices implies that these are small applications. That’s sometimes true, but a better way to think about them is that they should be only as big as needed to do one specific thing or solve a particular problem. That problem should be conceptual, not technical. As Microsoft puts it, “Microservices should be designed around business capabilities, not horizontal layers such as data access or messaging.” They communicate with other microservices and outside users via relatively stable APIs to create a larger application.

Thus, the internal functionality of an individual microservice can be tweaked or radically upgraded without affecting the rest of the system. This in turn ties into how devops shops seek to operate: If the specific functions of a larger application are segmented out into discrete, independently operating pieces of code, it’s easier to live the devops mantra of CI/CD (continuous integration and continuous delivery). Also, well-defined APIs makes microservices easy to automatically test.

Microservices architecture vs. monolithic architecture

You’ll often hear microservices talked about in terms of a “microservices architecture.” This phrase encompasses not just the microservices themselves, but components for management and service discovery, as well as an API gateway that handles communication between microservices and the outside world.

A “monolithic application” is the opposite of what microservices are. It’s a retronym for an application where all the code is in one large binary executable file. As TechTarget explains, a monolithic application is harder to scale and harder to improve. But because it’s built as a single cohesive application, it doesn’t require as much management as a microservices architecture.

Bounded concepts: How to define a microservice

Let’s back up for a moment to our earlier commandment that microservices should do one specific thing. That’s easy to say, but in practice, functionality is often intertangled, and drawing divisions is harder than it looks. Domain analysis and domain-driven design are the theoretical approaches that will help you tease apart your big-picture task into individual problems that a microservice can solve. In this process, outlined in an illuminating series of blog posts from Microsoft, you create an abstract model of your business domain, and in the process discover the bounded contexts, which group together functionality that interacts with the world in a specific way.

For instance, you might have one bounded context for shipping and another for accounts. A real-world physical object would have both a price and a place it needs to go, of course, but the bounded contexts represent specific ways in which your application thinks about and interacts with those objects. Each microservice should exist entirely within a single bounded context, though some bounded contexts might encompass more than one microservice.

Microservices vs. service-oriented architecture vs. Web services

At this point, if you’re an IT pro who’s been around the industry for a while, you might think a lot of this sounds familiar. The idea of small individual programs working together might remind you of both SOA (service-oriented architecture) and Web services, two buzzwords from the heady Web 2.0 days of the 2000s. While in one sense there is truly nothing new under the sun, there are important distinctions between these concepts and microservices. Datamation has a good breakdown of the differences, but here’s a short version:

• In a service-oriented architecture, individual components are relatively tightly coupled, often sharing assets such as storage, and they communicate through a piece of specialized software called an enterprise storage bus. Microservices are more independent, share fewer resources, and communicate via more lightweight protocols. It is worth noting that microservices arose out of the SOA milieu, and are sometimes considered a kind of SOA, or successor to the concept.
• A Web service is a publicly facing set of functionality that other applications can access via the Web; probably the most prevalent example is Google Maps, which a restaurant’s website could embed to provide directions for customers. This is a much looser connection than you’d see in a microservices architecture.