Microservices architecture is an approach to application development in which a large application is built as a suite of modular services. Each module supports a specific business goal and uses a simple, well-defined interface to communicate with other sets of services.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The microservices architecture is quickly becoming the default mechanism for building enterprise applications.
Software developer and author Martin Fowler is credited with promoting the idea of breaking down services in a service-oriented architecture into microservices. In a 2014 article, he stated:
"The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery."
Put another way, one could picture microservices in terms of Legos. Imagine 250 differently sized and shaped pieces. Altogether, the Legos can form one big structure. However, within that structure, there are hundreds of smaller parts. One part alone doesn't make much, but start building up each part and the possibility of what can be created is endless.
Microservices pros and cons
Among their advantages for software development, microservices:
- Are easily deployed.
- Require less production time.
- Can scale quickly.
- Can be reused among different projects.
- Work well with containers, such as Docker.
- Complement cloud activities.
However, there are also drawbacks with microservices, such as:
Microservices vs. monolithic architecture
Microservices came about to help solve the frustrations developers were having with large applications that require change cycles to be tied together. In a monolithic application, any small change or update required building and deploying an entirely new application. This inevitably means any application development entails a certain amount of planning, preparation, time and, potentially, money.
Microservices, on the other hand, require little of centralized management. Microservices applications are independently deployable and scalable. They enhance business capabilities with less planning and production than monoliths.
What about size?
The term microservices implies a small set of services, which begs the question of size. How large or small does an organization need to be for microservices to be successful? At the moment, there seems to be no limit in size in the number of services that can be deployed, so the term micro may be misleading.
Microservices architecture vs. SOA
SOA has been the standard development practice for nearly two decades. However, the resourcefulness of SOA is coming into question when working with cloud computing. With cloud, SOA lacks scalability and slows down with work request changes, limiting application development.
Some developers maintain that microservices are just a more granular approach to service-oriented architecture. Proponents of the SOA model consider microservices architecture as the natural evolution of SOA in order to accommodate cloud computing.
Others believe microservices are a more platform-agnostic approach to application development and, therefore, should have a unique name. This group could argue SOA lives on in the layers of microservices management.
How microservices work
In a microservices architecture, each service runs a unique process and usually manages its own database. This not only provides development teams with a more decentralized approach to building software, it also allows each service to be deployed, rebuilt, redeployed and managed independently.
Microservices leans toward business enhancements in order to improve the overall product, not just the project at hand. In monoliths, work is complete once the project is finished. In microservices, work is complete over the span of the lifetime of a product. Companies such as Amazon and Netflix employ this business model.
Microservices and containers
One issue developers have noticed with microservices is with accessibility and frequency. If the user accesses the microservices often, the response time and productivity slows in virtual machines. Containerization, using cloud-based virtualization to run and deploy applications without launching an entire VM for each application, allows microservices to move more quickly.
Using containers and microservices together enhances cloud capabilities. Microservices is scalable and reusable, while containers supply efficient resources. Both microservices and containers can work independently, but it has become clear that merging them has improved runtime frequency, cloud-hosting policies and cloud tools.
As cloud computing leads the direction of software development, microservices is set to play a large part in architectural design. There are still skeptics; however, the characteristics of a microservice will be an option for the unforeseen future.
Microservices architecture can alleviate some security issues that arise with monolithic applications. Microservices simplifies security monitoring because the various parts of an app are isolated. A security breach could happen in one section without affecting other areas of the project. Microservices provide resistance against distributed denial-of-service attacks when used with containers by minimizing an infrastructure takeover with too many server requests.
However, there are still challenges when securing microservices applications, including:
- More network areas are open to vulnerabilities.
- Less overall consistency between app updates allows for more security breaches.
- Not a lot of security tool options exist for microservices yet.
- There's a lack of control of third-party software.
Microservices developers have come up with strategies to alleviate security issues. To be proactive, use a security scanner, utilize access control limitations, secure internal networks -- including Docker environments -- and operate outside of silos, thus communicating with all parts of the operation.