What are microservices? Your next software architecture

Microservices break up monolithic code into easy-to-maintain chunks and are key to the devops philosophy

Credit: Thinkstock

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 microservicea 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 inter-tangled, 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.

Microservices communication

A catchphrase you’ll often hear used about microservices architectures is that they should feature “smart endpoints and dumb pipes.” In other words, microservices should aim to use basic and well-established communication methods rather than complex and tight integration. As noted, this is another thing that distinguishes microservices from SOA.

In general, communication between microservices should be asynchronous, in the sense that code threads aren’t blocked waiting for responses. (It’s still fine to use synchronous communications protocols such as HTTP, though asynchronous protocols such as AMQP (Advanced Message Queuing Protocol) are also common in microservices architectures.)

This kind of loose coupling makes a microservices architecture more flexible in the face of the failure of individual components or parts of the network, which is a key benefit.

Microservices, Java, and Spring Boot and Spring Cloud

Some of the first work in microservices arose in the Java community; MartiMartin Fowler Fowler was an early proponent. A 2012 Java conference in Poland featured one of the most important early presentations on the subject, entitled “Micro services - Java, the Unix Way."

It recommended applying the principles that guided the development of the first Unix applications in the 1970s (“Write programs that do one thing and do it well. Write programs to work together”) to Java development.

As a result of this history, there are plenty of Java frameworks that enable you to build microservices. One of the most popular is Spring Boot, which is specifically designed for microservices; Boot is extended by Spring Cloud, which as the name suggests, allows you to deploy those services to the cloud as well.

Pivotal Software, the developer of Spring, has a good tutorial on getting started with microservice development using these frameworks.

Microservices and containers: Docker, Kubernetes, and beyond

The underlying technology that has gone furthest towards getting microservices into the mainstream is containers. A container is similar to a VM instance, but instead of including an entire self-contained OS, a container is just an isolated user space that makes use of the host operating system’s kernel but otherwise keeps the code executing inside of it self-contained.

Read more on the next page...

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about AdvancedAmazonAWSDatamationGoogleMicrosoftPivotalPivotal SoftwareTechTarget

Show Comments
[]