Overview
Microservice Architecture is a software development style that has grown from recent trends. It’s a set of technology-agnostic patterns and principles meant to increase the speed and efficiency of developing and managing the software that scales.
“The microservice architectural style is an approach to developing a single application as a suite of small services, each running its own process and communicating with lightweight mechanisms”
– James Lewis and Martin Fowler
“A loosely coupled service oriented architecture with bounded contexts to make sure you break your problem into the right chunks”
– Adrian Cockcroft
The microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications. It also enables an organization to evolve its technology stack.
Definition
Microservices – also known as the microservice architecture – is an architectural style that structures an application as a collection of services that are
- Highly maintainable and testable
- Loosely coupled
- Independently deployable
- Organized around business capabilities
- Owned by a small team
| MICRO | “Does one thing” and does it well Bounded context as in a subdomain of the application e.g. user or inventory management module There’s no universal measure defying the ideal size of a microservice |
| SERVICE | Independently deployable component Invocable via message-based communication e.g. Apache Kafka |
Some of the design characteristics of microservice architecture include:
- Business Oriented
- Adaptable
- Autonomous
- Loosely Coupled
- Composable
Monolithic vs. Modular
Monolithic architecture is simply an all-in-one approach where the software is self-contained and tightly-coupled. The deployment model is simple as in adding an application instance. An example of a monolithic JavaScript (node.js) web framework would be Sails.js.
Modular is quite the opposite to monolithic i.e. it’s loosely coupled with minimum functionality and structure. Fundamentally it has a single responsibility i.e., “does one thing”. An example of a modular JavaScript (node.js) web framework would be Express.
Domain-Driven Design (DDD)
Domain-Driven Design (DDD) is a common framework that facilitates the development of highly modular and cohesive systems though bounded context.
DDD is a way of looking at software from top-down. The focus isn’t primarily on technology, but rather the business problem/ problem we’re trying to solve using software, the domain. Specifically, we approach that by trying to develop models of that domain to make the software conformed to that.
The typical software layers in DDD project are Application Layer e.g. a web app/ API, Domain Layer e.g. entity model, domain POCO entity classes and DDD pattern components including aggregators, etc., and Infrastructure Layer including data persistence infrastructure, use of ORMs, etc.
For more details with code samples please refer to Microsoft docs – Design a DDD-oriented microservice.
SOA vs. Microservices
The Service-Oriented Architecture (SOA) was a response to traditional monoliths, where application components are broken down into separate service modules that communicate with each other to meet specific business objectives. In general, SOA delivers four types of services i.e
- Functional services
- Enterprise services
- Application services
- Infrastructure services
| Microservice | SOA | |
| Architecture | Services that are functionally independent | Uses shared resources across services |
| Component Sharing | No | Yes |
| Granularity | Fine-grain | Larger |
| Data Storage | Independent by service | Shared among services |
| Size/ Scope | Smaller web apps | Larger scale integrations |
| Communication | REST API Preferably Asynchronous and Event-Driven | SOAP via EBS Typically Synchronous and Request Based |
| Coupling | Bondex context | Shared resources |
| Deployment | Quick and Easy | Less flexible, gating |
One of the most notable drawbacks of SOA is its reliance on SOAP, which only allows two responses, i.e., HTTP OK (200) or Internal Server Error (500). SOAP value comes from a strong contract/ strong documentation layer i.e. WSDL, however, that adds extra processing. The other most significant issue is the aggregation of services i.e., SOA Bus, where XML transformation and logic operations start adding to the bus itself, adding another layer of coupling.
Summary
Microservices aren’t a silver bullet to solve all your problems. Just like any other development style, there are pros and cons to using it. For instance, unlike with monolithic applications, microservices require an upfront investment in agile methodology and DevOps (CD/CI, and automated monitoring) culture to be successful in managing many moving components in an organized matter.
Are microservices right for your application? If it’s very large, complex, and in pressing need of being tamed, then they may be. But if it’s performing fine as it is, then microservices may be one bandwagon that you don’t need to jump on.