Microservice Architecture (a.k.a. “Microservices”) is a method of developing software focused on building single-function modules. The term was coined in 2011 and the microservice approach quickly gained steam near the end of 2013:
The advancement of microservices was driven, in part, by tech giants like Netflix, Amazon, Twitter, Google, and Uber evangelizing its benefits.
What’s all the microservice buzz about?
Why is anyone interested in microservices? To answer that question we need to briefly explore the evolution of software architecture.
Monoliths
Not long ago, most software was “monolithic.” A monolithic design means the user interface and the data access code are combined into a single, self-contained program.
Monolithic software design comes with some downsides. Most notably, because of the self-contained, interdependent nature of monoliths, a failure anywhere in a program can cause the whole application to come crashing down. And, there are other issues:
- Reduced agility. The application’s codebase is released all at once. Developers need to code and deploy the entire stack. Rebuilding the whole application takes time and slows down the pace at which new features can be delivered.
- Complexity. Large applications become harder to understand and work with. There are side effects of changes that might not be obvious due to easy-to-overlook dependencies leading to “mysteries and magic” that can be difficult to untangle.
- Less scalability. Scaling becomes a matter of adding new instances to run the entire codebase rather than adding instances to scale individual pieces of the app that might be used more than others. Unequal usage of that application can lead to some resources being wasted and other resources straining the server.
Service-Oriented Architecture
To overcome these problems, a Service Oriented Architecture (SOA) was introduced and became popular in the early and mid-2000s. The SOA views an application as a collection of services running in parallel and connected by application programming interfaces (APIs). Each service is self-contained and represents a specific business activity with a desired outcome.
This approach helps solve many of the downsides inherent to monolithic software designs:
- Easy maintenance. Distinct services can be updated without affecting other services.
- Platform independence. You can create an application by combining services that use different solutions.
- Improved reliability. It is easier to locate the problem and debug a small service than it is with a monolith and a single service going down usually won’t take down the entire application.
- Scalability. Individual services can scale by adding server resources as demand increases.
The Microservice Architecture (MSA) is a variant of SOA. In fact, some people argue that MSA and SOA are not really different things at all, so the term “microservices” is superfluous. Nevertheless, the term seems to be here to stay.
What are microservices?
According to Jerry Andrews, when people talk about MSA they’re generally referring to software design that includes these characteristics:
- Services typically rely on other services to accomplish their goals
- Services are often containerized using a container tool such as Docker but they could also run in a virtual machine (VM)
- Asynchronous communication is handled via messaging or job queues and synchronous communication is handled via HTTP with JSON messages
- Instance management automation
- Auto-scaling components
There is some debate on the exact definition and some would argue with aspects of the defining characteristics repeated here.
SOA and MSA are also differentiated by how granular services are:
Source: Dzone
There are also differences in how individual services are conceptualized. SOAs view services through distinct lenses:
- Business services
- Enterprise services
- Application services
- Infrastructure services
In contrast, MSA views services purely as functional (without viewing them through the separate lenses SOA does). Microservices might be created for discrete functional services like:
- Authentication
- Email sending
- Account management
- Account creation
- Billing
- Messaging
Microservice architecture versus APIs
When learning about microservice architecture there is often some confusion on how it’s different than an API endpoint. The clearest way to express the difference between these two terms is to point out that an API is about communication and a microservice is about how the software is organized.
An API allows an app’s data to be accessed or instructs the app to perform a function. This communication can happen either internally (in the case of a private API) or externally (in the case of a public API). These functions could be:
- Making changes to data
- Pull data out of one app so it can be brought into another
- Telling the app to create a new user
- Triggering the app to send out an email
A microservice may leverage APIs to allow different services to interact but the term refers specifically to how an application is divided up.
If the difference between an API and MSA is still unclear, here’s a great video from IBM that explores the differences in more depth:
Benefits of Microservices
The self-contained nature of individual microservices introduces a variety of benefits:
- Simplicity. Microservice architectures are usually more simple so they can be easier to build and maintain.
- Autonomous cross-functional teams. Technical decisions can be made faster and by smaller groups.
- Flexibility in technology. Like the SOA approach, microservices allow a blend of solutions to work together.
- Flexibility in scalability. Microservices can scale independently so additional resources can be added exactly where they’re necessary.
- Code can be re-used. For example, here at Pagely we were able to use some Pagely-made microservices to power our new serverless hosting solution, NorthStack.
Source: Skelia
The downsides of microservices
While many companies are refactoring their monoliths in favor of a microservices approach, microservices aren’t always the right answer. It’s not the one true perfect way to design an application that everyone should always use. In many cases, the upsides of MSA outweigh the downsides, but sometimes not because:
- Microservices can introduce complexity. A monolith’s complexity comes from how challenging it can be to understand how different code interacts, MSA’s complexity comes from having more and more of the code split out into individual services. Five or six services aren’t difficult to manage, but twenty, thirty, or more can be!
- Microservices require changes to culture and process. Companies that adopt microservices will also need to adopt an agile coding approach and, often, create a DevOps team.
- Microservices can be costly. Network calls made by APIs aren’t free and add up. In addition, the labor costs of breaking up a monolith can create an otherwise unnecessary expense.
- Microservices may introduce security issues. Each inter-network communication path creates a new security risk that needs to be addressed and monitored.
Source: Tiempo Development
Moving from monolith to microservices
Many applications begin their lives as monoliths, but as they mature bottlenecks that should be split out into microservices become apparent. This refactoring process is known as “breaking up the monolith.” The two architecture approaches are not an “either-or” thing or a “right or wrong” thing— many popular apps are a monolith-microservices hybrid.
Starting from scratch: Monolithic versus Microservice architecture
While microservices offer distinct advantages over monoliths, building software from scratch as a monolith and then moving toward a microservice approach may sometimes make more sense:
- Developing an application as microservices will usually be slower (initially) than taking a monolith approach
- As the monolithic software matures and the big picture becomes more clear, the functions that should be split out into microservices will be more obvious.
- A well-designed monolith can easily be broken out into microservices later.
If development time is a non-issue, taking a microservices approach from the beginning avoids the effort and expense of later refactoring. You could weigh the pros and cons of absorbing the time costs of starting with microservices versus delaying those costs and beginning with a monolith. The right answer will depend on the priorities of the company and its project.
Useful and great to understand microservices. Thank you, Brian