EventJoin us at AWS re:Invent 2024! Learn how to use MongoDB for AI use cases. Learn more >>Join us at AWS re:Invent 2024! Learn how to use MongoDB for AI use cases. >>

Microservice architecture, also known as “microservices,” is a cutting-edge, highly scalable approach to software development in which applications are decomposed into smaller, independent services that communicate over well-defined APIs. Each service is deployed independently and can be developed, tested, and scaled independently.

As a result, the failure or outage of one service does not affect the others, particularly those with strong dependencies — it ensures that part of the system still operates. For instance, if the "buying cart" service fails, the payment service will be unable to process transactions because it cannot retrieve the cart totals. Conversely, a less critical service like product rating might still allow customers to make purchases, even though the experience is somewhat degraded.

This architecture contrasts sharply with the traditional monolithic architecture, where all components and functionalities are tightly integrated into a single codebase.


Table of contents

Microservice architecture

By using a microservice architecture, a company can create new products and services faster and better orient development teams to focus on specific business goals. A microservices architecture can be organized around business capabilities, enabling teams to track toward and deliver on specific goals.

Microservices based on goals and capabilities such as these allow for concurrent builds, with many developers working on the same applications concurrently, ultimately shortening the development cycle for internal teams.

This organizational style enhances agility, as development teams can focus on individual services without impacting others. The services are often designed to be loosely coupled, which further aids in isolating issues and reducing interdependencies, with strong conformance to previously defined interfaces.

A diagram representing an application connecting to multiple microservices.

Multiple microservices communicate with each other to provide a response to an API or a web application.


Benefits of a microservices architecture

You might be wondering if you need microservices in your current application. A microservice architecture helps to break large monolithic applications into smaller pieces and provides you with the following benefits: faster time to market, modularity, flexibility and scalability, resiliency, organizational alignment, and reduction in costs.


A diagram summarizing the benefits of microservices architecture.

The benefits of microservice architecture

1. Faster time-to-market

The microservice method significantly reduces development time. Changes or updates to an individual service can be immediately applied, tested, and implemented, with no impact on the rest of the system. This is opposed to the older method of building “monolithic” applications, in which even small code changes require redeploying the entire software stack, which introduces risk and complexity.

  • Independent service deployment: Microservices allow for independent deployment of services, which means that development teams can work on different services concurrently, reducing the time required to roll out new features or updates.

  • Reduced development bottlenecks: By decomposing a monolithic application into microservices, teams can eliminate bottlenecks associated with large, intertwined codebases. This streamlined approach fosters quicker iterations and faster feedback loops.


2. Enhanced modularity

Services usually focus on a specific objective and are decoupled along business boundaries. This keeps teams focused on relevant goals and ensures autonomy between services. Typically, each service is housed in its own software container, and multiple instances of the same microservice architecture are deployed for redundancy and scalability.

  • Service-specific focus: Each microservice is dedicated to a specific business function, which simplifies the development process. Teams can focus on perfecting individual services without worrying about the entire application.

  • Improved code quality: Modular services promote clean, maintainable code. Smaller, well-defined services are easier to understand, test, and debug, leading to higher overall code quality.


3. Flexibility and scalability

Monolithic architecture for an application requires the entire system (and all of its functions) to scale simultaneously. With a microservice architecture, only the components or features that require extra performance need to be scaled. When designed properly, this is easily achieved by deploying more microservice instances, enabling better capacity planning and keeping a lid on software licensing costs.

  • Targeted scaling: With microservices, selective scaling is more efficient and cost-effective than scaling an entire monolithic application.

  • Technological flexibility: Different microservices can be built using different programming languages, frameworks, or data storage technologies that best suit their specific requirements. This flexibility allows for optimized performance and resource usage.


4. Resilience and fault tolerance

With a monolithic application, the failure of a single component can compromise the entire system. In microservices, each service is isolated to prevent cascading failures from bringing everything down. In the unlikely event that all instances of a microservice fail, its performance would degrade but other application components would continue to deliver value.

  • Isolated failures: Microservices isolate failures to individual services, ensuring that the rest of the application continues to function.

  • Graceful degradation: When a microservice fails, the system can degrade gracefully by limiting the impact to only the affected service. This approach maintains partial functionality and enhances overall system resilience.


5. Alignment with business goals

Microservices help make it easier for technical groups and other teams to be right-sized and well aligned with business needs and required tasks. Teams are typically small, interdisciplinary, and centered around a single component of the overall application. This cross-functional approach breaks down silos, improves collaboration, and is especially effective for distributed and remote teams.

  • Cross-functional teams: Teams responsible for specific services can work more closely with business stakeholders, improving collaboration and alignment.

  • Autonomous teams: Each team can operate independently (when adhering to an agreed, current interface), making decisions and deploying updates without waiting for other teams. This autonomy accelerates development and fosters innovation.


6. Cost-efficiency

Microservices lower costs by utilizing infrastructure and development teams more efficiently. Maintaining the large codebase of a monolithic application consumes significant time and resources. In contrast, the services within a microservices-built system can each be managed independently, greatly reducing the time spent on maintaining and updating code.

  • Optimized resource usage: Microservices can optimize the use of computing resources by scaling only the necessary services. This targeted approach reduces infrastructure costs compared to monolithic applications that require scaling the entire system. Microservices utilize a variety of programming languages, so it’s easy to select the one that offers the best performance and maintenance costs for your specific use case.

  • Reduced maintenance costs: Maintaining smaller, independent services is less complex and time-consuming than managing a large monolithic codebase. (But keep in mind, there is a threshold at which organizations see additional costs related to design, orchestration, and communications.) This reduction in complexity lowers maintenance costs and frees up resources for new development.

How do microservices work?

In a microservice architecture, services are typically isolated within containers, which are lightweight, separate run-time environments that are scalable with minimal impact on performance and capacity. Packaging is simplified and resources conserved, because a single environment simultaneously hosts development, support, test, and production versions of the application. An API gateway, then, can connect to multiple microservices at once.

A diagram of an API gateway connected to multiple microservices.

Each microservice has its own isolated database


Each service also generally has its own database — containing information that pertains to that specific microservice — to minimize the impact of failures. If a single database was shared, an outage would affect multiple microservices and result in substantial downtime. Isolating database instances also enables changes to database contents and configuration to be made without impacting other microservices.

Core principles of microservices

Microservices architecture revolves around a few core principles that dictate how services are designed, developed, and deployed. Understanding these principles is key to effectively implementing and leveraging the benefits of microservices:


Independent deployability

Each microservice can be developed, tested, and deployed independently of others. This autonomy allows for faster release cycles and reduces the risk associated with deploying changes.


Service encapsulation

Microservices encapsulate specific business functions or capabilities, ensuring that each service has a single responsibility. This encapsulation aligns with the principle of separation of concerns, making the system easier to understand and maintain.


Loose coupling

Microservices are loosely coupled, meaning they interact with each other through well-defined interfaces and protocols, typically using HTTP/REST or messaging queues. This decoupling ensures that changes in one service do not ripple through and affect others.


Business capability orientation

Services are organized around business capabilities, ensuring that each service corresponds to a distinct business domain. This organization enhances agility and ensures that technical development aligns closely with business needs.


Polyglot persistence

Each microservice can use its own database and data storage technology, chosen to best suit its specific requirements. This approach, known as polyglot persistence, allows for greater flexibility and optimization.

Technical components of microservices


Containers and orchestration

Microservices often run within containers, which provide lightweight, portable, and consistent runtime environments. Tools like Docker enable developers to package microservices with all their dependencies, ensuring that they run reliably in any environment.

Container orchestration platforms like Kubernetes manage the deployment, scaling, and operation of containerized applications. Kubernetes provides features like automatic scaling, self-healing, and rolling updates, which are essential for maintaining a resilient microservices architecture.


API gateway

An API gateway serves as a single entry point for all client requests to the microservices. It handles request routing, composition, and protocol translation. The API gateway can also manage cross-cutting concerns such as authentication, authorization, rate limiting, and caching, simplifying the client-side interaction with the microservices.


Service discovery

Service discovery mechanisms allow microservices to find and communicate with each other dynamically. In a microservices architecture, services often change their location due to scaling or failure recovery. Service discovery tools like Consul or Eureka track the available service instances and provide their addresses to clients and other services.


Communication patterns

Microservices communicate using a variety of protocols and patterns. Synchronous communication typically involves HTTP/REST or gRPC, while asynchronous communication uses messaging systems like RabbitMQ, Apache Kafka, or AWS SQS. Choosing the right communication pattern is crucial for achieving the desired performance and reliability characteristics.


Database per service

In general, each microservice usually manages its own database. This isolation minimizes dependencies and allows services to be developed, deployed, and scaled independently. It also supports different data storage technologies tailored to the specific needs of each service, enabling the use of relational databases, NoSQL databases, or even in-memory data stores as required.


Event-driven architecture

In an event-driven architecture, microservices communicate through events. An event is a change in state or an occurrence of interest. When a microservice processes a request, it can publish events to a message broker, which other services subscribe to and react to. This pattern decouples the producers and consumers of events, enhancing scalability and flexibility.

Operational aspects of microservices


Continuous integration and continuous delivery (CI/CD)

Implementing CI/CD pipelines is essential for maintaining the agility and reliability of microservices. CI/CD practices automate the building, testing, and deployment of microservices, ensuring that changes are integrated smoothly and delivered quickly.


Monitoring and logging

Effective monitoring and logging are crucial for managing microservices. Distributed systems introduce complexity, making it essential to have comprehensive observability tools. Monitoring solutions like Prometheus and Grafana provide real-time insights into service performance and health, while logging tools like the ELK Stack (Elasticsearch, Logstash, Kibana) help trace and debug issues across services.


Security

Securing a microservices architecture involves multiple layers of security measures. API gateways enforce authentication and authorization, while service-to-service communication is secured using protocols like TLS. Additionally, implementing a zero-trust security model ensures that all interactions are verified and authorized, regardless of their origin.


Fault tolerance and resilience

Microservices architectures must be designed for fault tolerance and resilience. Techniques such as circuit breakers, retries, and timeouts help manage failures gracefully. Service meshes like Istio can provide advanced traffic management, security, and observability features to enhance the resilience of microservices.


Data management and consistency

Ensuring data consistency in a microservices architecture can be challenging. Strategies like eventual consistency, where data is allowed to be temporarily inconsistent across transactional boundaries and converges to a consistent state over time, are often employed. Techniques like event sourcing and CQRS (Command Query Responsibility Segregation) can also help manage data consistency across services.

What are microservices used for?

Microservices are an alternative to the traditional monolithic architecture development approach in which an entire application is structured as a single, autonomous unit.

With a monolithic application, changes are slow and cumbersome to execute: Modifying even a small section of code can require building and deploying an entirely new version of the software. Likewise, scaling specific application functions entails having to scale the entire application.

Microservices solve these inherent challenges of monolithic architecture with a highly modular approach. The entire application is instead structured as a suite of small services, each running in its own process and independently deployable.

The microservice architecture has grown in popularity in recent years as enterprises evolve toward Agile methodology and the DevOps model, both of which emphasize smooth and close collaboration between teams of developers and IT operations. Microservices and DevOps philosophy work hand-in-hand to enable faster, more efficient creation and delivery of applications and software services.

Is MongoDB compatible with microservices?

With its flexible schema and capabilities for redundancy, automation, and scalability, MongoDB (and MongoDB Atlas, its managed services version) is very well suited for microservice architecture. Additionally, implementing DDD and its aggregation pattern, which is very useful in microservices, is much easier with MongoDB than with a SQL database. Together, MongoDB Atlas and microservices can help organizations better align their teams, innovate faster, and meet today's demanding development and delivery challenges, such as:

  • Redundancy: Because microservice architecture is distributed, there are more potential failure points, so microservices need to be designed for redundancy. MongoDB Atlas readily meets this requirement with built-in redundancy through MongoDB replica sets.

  • Monitoring and automation: As the number of services in an application grows, an automated management process is required to cope with the increasing complexity. MongoDB Ops Manager (also available as the hosted Cloud Manager service) fits the bill here, with visualizations, custom dashboards, and automated alerting. Ops Manager tracks 100-plus key database and system health metrics.

  • Scalability: As with any IT environment, microservices must be scalable to accommodate higher demand. MongoDB Atlas meets the need for dynamic scaling with no loss in performance, through automatic partitioning and database distribution across nodes. What's more, MongoDB Atlas is designed to scale-out on commodity hardware with auto-sharding, for easy database distribution across geographic regions with minimal manual setup.

What's an example of a microservice?

Sports software startup Hudl uses MongoDB as the database for its online video analysis platform. Its original system was built as a monolith, but as the codebase grew to over three million lines, it became harder and harder to maintain — to the point where updates were taking 30 minutes to create and deploy.

In addition, its rapidly growing engineering unit organizes its teams into small, autonomous “squads.” By re-architecting its platform to microservices, Hudl was able to align these teams, or "squads," to specific application functionalities. In this way, each small team can deploy and update code faster.

FAQs

Is an API an example of microservices?

An application program interface (API) is a set of routines, protocols, and tools that allow applications — in this context, services within a microservice architecture — to talk to each other. So the answer is no: APIs are not microservices. Think of them as messengers that deliver requests and responses, rather than microservices, which allow each part of the application (components) to function autonomously. APIs are also used in programming the components of graphical user interfaces (GUIs). However, keep in mind that microservices must conform to a well-established (REST or otherwise) API to provide their "work" to the rest of the application.

Are microservices RESTful?

Microservices are architectural components, whereas REST (Representational State Transfer) is an HTTP-based web service for communication between applications. Restful APIs enable microservices to work together while keeping them decoupled. While RESTful APIs aren’t strictly required for microservices, they do make it easy to build microservices that are loosely coupled. Other types of APIs like gRPC can be used, or just use event-driven functionality.

Are microservices a technology?

Microservices themselves are not a technology. Microservices are a software architecture that involves splitting large applications into small pieces that communicate with each other. Then, these individual services can be deployed, built, and maintained by smaller groups of software engineers.

What language is used in a microservices architecture?

One reason to use microservices is that any language can be used on individual microservices. To build microservices, a common communication protocol could be used for each component. As long as this is in place, the microservices can be programmed in different languages.

What are the disadvantages of microservices architectures?

When it comes to deploying and managing large applications with thousands of microservices architectures, understanding the application as a whole and ensuring proper communication across all the components can be challenging. Thankfully, tools such as Kubernetes make this much easier.

Another disadvantage of using microservices lies in data consistency. As multiple databases can be used, some redundancy might be needed. Ensuring consistency across all the sources might require some architectural changes when building microservices.

Can microservices have a UI?

Generally, the microservices handle backend logic and data, and they don’t have a UI. However, some microservices will contain the UI or parts of the UI for the application. Recently, there has been an emergence of frameworks to help split large UIs into smaller components. This new pattern is called micro front end and aims at bringing the benefits of building microservices to application front ends.