Microservice architecture, also known as just “microservices,” is an approach to building software in which applications are separated into components called services, which are loosely coupled but function autonomously. Services are usually deployed independently so that a failure or outage of one does not affect the others. They are typically closely aligned with a particular business function or objective.
By using the microservice architecture, a company can create new products and services faster and better orient development teams toward specific business goals. A microservices architecture can be organized around business capabilities, enabling teams to track towards 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 microservices applications at the same time, ultimately shortening the development cycle for internal teams.
Multiple microservices communicate with each other to provide a response to an API or a web application.
Each service is created and tested on its own, and independently deployable. This means that multiple services are typically separate, self-contained processes. Each microservice then communicates with the others through network-based APIs.
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.
The benefits of microservice architecture
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.
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. Each service is housed in its own software container, and multiple instances of the same microservice architecture are typically deployed for redundancy and scalability.
Resiliency: 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.
Organizational alignment: Microservices ensure that technical groups and other teams are 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.
Reductions in cost: 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.
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.
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.
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.
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. 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.
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.
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).
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.
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.
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.