Nearly every computer system performs multiple tasks using shared resources. One of the perennial questions of computer programming is how closely or loosely the bits of code that perform those tasks should be coupled. One answer is the microservices architecture, which consists of discrete chunks of functionality that interact with other discrete chunks to create a larger system. Each chunk is a microservice.
Although the idea of connected components isn’t new, microservices have gained popularity as a natural foundation for cloud-based applications. Microservices architecture also dovetails with the devops philosophy, which encourages rolling out new functionality rapidly and continuously.
This article introduces you to microservices, including the pros and cons of migrating to a microservices architecture.
What are microservices?
The “micro” in microservices implies small applications. That is 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 to solve a particular problem. That problem should be conceptual, not technical. The documentation for Microsoft Azure explains it well: “Microservices should be designed around business capabilities, not horizontal layers such as data access or messaging.”
Microservices communicate with other microservices and outside users via relatively stable APIs to create larger applications. Thus, the internal functionality of an individual microservice can be tweaked or radically upgraded without affecting the rest of the system. Segmenting the specific functions of a larger application into discrete, independently operating pieces of code makes it easier to create the CI/CD (continuous integration and continuous delivery) pipelines at the heart of devops. Well-defined APIs also make microservices easier to test automatically.
What is a microservices architecture?
You’ll often hear microservices talked about in terms of a microservices architecture. This phrase encompasses not just the microservices themselves but the infrastructure required to support them, including:
- Automated components for service management and discovery, as well as failover and resilience. (We'll discuss some of the more popular platforms for these purposes momentarily.)
- A simple method for routing communications between services.
- An API gateway that handles communication between microservices and the outside world.
The overall goal is an architecture that is resistant to failure and can evolve to meet changing needs without requiring a complete overhaul.
Microservices vs. monolithic architecture
Before we had microservices, we had just one style of architecture, and that was monolithic. The so-called monolithic architecture is a retronym for an application where all the code is in one large binary executable file.
Monolithic architecture has its place. While a monolithic application is generally harder to scale and harder to improve than microservices, it also doesn’t require as much management. Monolithic applications are also simpler when it comes to data storage. Individual components in a microservices architecture are generally responsible for persisting their own data, so each microservice requires its own database. A monolithic application uses just one database for all its data operations.
What do we mean by 'microservice'?
Let’s back up for a moment to my earlier statement that microservices should do one specific thing. That’s easy to say, but drawing those functional divisions is harder than it looks. Domain analysis and domain-driven design are the theoretical approaches that will help you tease apart big-picture tasks into individual problems that a microservice can solve. An illuminating series of blog posts from Microsoft describes this process. A first step is creating an abstract model of your business domain, which you can use to discover the bounded contexts that group functionality.
Consider a shipping application as an example. A real-world physical object would have both a price and a destination, so you might have one bounded context for accounts and another for shipping. Each microservice you create should exist entirely within one bounded context, though some bounded contexts might encompass more than one microservice.
Microservices vs. SOA and web services
If you’ve been around for a while, the idea of small individual programs working together might remind you of both SOA (service-oriented architecture) and web services. These are two buzzwords from the heady days of web 2.0 in the early 2000s. While in one sense there is truly nothing new under the sun, there are important distinctions between the three approaches:
- SOA vs. microservices: 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. Microservices are sometimes considered a kind of SOA, or successor to the SOA concept.
- Web services vs. microservices: A web service is a public-facing set of functionality that other applications can access via the web; probably the most prevalent example is Google Maps, which some shops embed in their website to provide directions for customers. Unlike microservices, web services do not necessarily connect to other services. They are more loosely connected than you’d see in a microservices architecture.
How microservices communicate
Something you’ll often hear about microservices architectures is that they should feature smart endpoints and dumb pipes. In other words, microservices should aim to use fairly simple and well-established communication methods.
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.) This kind of loose coupling makes a microservices architecture more flexible in case individual components or parts of the network fail.
Pros and cons of microservices
Now that you have a sense of the microservices architecture, let's sum up some of its main benefits:
- Fast development lifecycle: In a microservices architecture, individual service components each have their own development and update lifecycle, with a relatively small team of developers in charge of it. This means the application as a whole can be advanced incrementally, feature by feature, instead of making users wait for a "big bang" update. This style of development is what makes devops and CI/CD possible.
- Service isolation: The idea of separation of concerns is a foundational computer science design principle. Having individual microservices encapsulate a distinct and coherent set of functionality should make those services easier to maintain and reason about. On a more practical level, having services isolated from one another makes it possible to build different parts of the same application using different languages, which can be helpful in specialized situations. It also makes it easier to isolate and diagnose faults.
- Scalability: If you need to scale up some aspect of your application, a microservices architecture allows you to do so without pulling the entire codebase into the process. Service orchestration platforms (more on these in a moment) can take care of this scaling for you, deploying multiple instances of a service as needed or moving it to higher-performing hardware.
- Re-use: A service you build for one application may be useful for future applications; building up a library of such services can accelerate the development of new products.
- Third-party service integration: Because microservices communicate through standardized APIs, you can integrate services developed elsewhere—either commercial or open source—into your application.
There are also challenges associated with microservices:
- Architectural complexity: A distributed microservices architecture has a lot of moving parts. Automated orchestration platforms like Kubernetes can abstract some of the management toil away. On the downside, those platforms often have steep learning curves.
- Performance bottlenecks: An API-based communications system is flexible and easy to develop, but it's not as speedy as interprocess communication within a single monolithic binary. An orchestration platform is a heavy-duty piece of infrastructure in its own right. For applications, the tradeoffs in development ease are well worth it, but the extra strain on computing resources can take a toll.
- Concerns aren't always easy to separate: While an ideal microservices system consists of perfectly discrete microservices, in the real world things aren't so neat—especially if you don't have the time or resources to perfectly design your application before you start building it. In practice, you might end up implementing similar functionality in multiple services, with separate teams duplicating efforts in parallel. Some business transactions may end up spanning multiple services, which will require multiple development teams to coordinate with one another.
- Security concerns: To a malicious hacker, a monolithic binary is a black box whose inner workings are difficult to understand and attack. A microservices architecture provides a greater attack surface; for instance, API calls can be intercepted and modified in transit.
- Culture shift: While CI/CD and devops are considered de rigueur by many in the industry, there are still plenty of shops that don't operate in accordance with those practices. A move to microservices will entail a big organizations shift for these shops and developers—perhaps for the better, but definitely disruptive in the short term.
Microservices design patterns
No matter what language you use to develop microservices, you’ll face issues that other developers have encountered before. Design patterns are formalized, abstract solutions to recurring problems in computer science, and a number of them are specifically for microservices. Devopedia has a great list, which includes:
- Service Registry: For connecting clients to available instances of microservices.
- Circuit Breaker: To prevent failed services from being called repeatedly.
- Fallback: For providing an alternative to a failed service.
- Sidecar: For providing an auxiliary service to the main container, such as for logging, synchronizing services, or monitoring.
- Adapter: To standardize or normalize the interface between the main container and the external world.
- Ambassador: To connect the main container to the outside world, such as for proxying localhost connections to outside connections.
Microservices with Docker and Kubernetes
The underlying technology that has gone furthest toward getting microservices into the mainstream is containers. A container is similar to a virtual machine (VM) instance; however, while a VM includes an entire self-contained operating system, a container is just an isolated user space that makes use of the host OS’s kernel but otherwise keeps the code executing inside of it self-contained. Containers are much smaller than VMs; they can be deployed quickly and easily, either locally or in the cloud, and can be spun up or down to match demand and available resources.
The appeal of containers for microservices should be obvious: Each individual microservice can run in its own container, which cuts the overhead of managing services significantly. Most container implementations have complementary orchestration tools that automate the deployment, management, scaling, networking, and availability of container-based applications. It’s the combination of small, easy-to-build microservices and easy-to-deploy containers that makes the devops philosophy possible.
There are several implementations of the container concept, but by far the most popular is Docker, which is generally paired with Kubernetes as an orchestration platform.
Container-based systems are intrinsically polyglot: Any programming language that the operating system supports can run in a container, which gives programmers flexibility. Indeed, a big advantage of microservices is that each service can be written in whatever language makes the most sense—in fact, a service could be completely rebuilt in a new language without affecting the system as a whole, as long as its APIs remained stable. This might be more appealing than a platform like Spring Cloud, which is based in Java. (Note, though, that this isn't necessarily an either/or choice, as Spring Cloud can be integrated with Kubernetes.)
Microservices with AWS and Azure
The advantages of using containers is that they can be easily deployed to the cloud, where flexible compute resources are available so you can maximize your application’s efficiency. As you might imagine, the major public cloud vendors are all eager for you to use their platforms to run your microservices-based apps. For more information, check out the resources from the three major cloud vendors, Amazon, Microsoft, and Google.
Should I migrate to microservices?
It is worth considering what it will take to move your own codebase to a microservices architecture. In many ways, migrating existing functionality can be trickier than building a new microservices-based application from scratch. On the upside, thanks to the nature of microservices, you don't have to do it all at once. You can build individual services that take on part of your old monolithic application's functionality while leaving the rest of it intact.
For more about the nitty-gritty of such a migration, including best practices, check out InfoWorld's guide, How to get started with event-driven microservices. And good luck on your journey!