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. Multiple microservices can be built concurrently, with many developers working on the same application at the same time, ultimately shortening the development cycle.
Multiple microservices communicate with each other to provide a response to an API or a web application.
Each service is independently created, tested, and deployed. Services are typically separate, self-contained processes that communicate with each other through network-based APIs.
You might be wondering if you need microservices in your current application. Microservices help to break large monolithic applications into smaller pieces and provide you with the following benefits: faster time to market, modularity, flexibility and scalability, resiliency, organizational alignment, and reduction in costs.
The benefits of microservices architecture
Faster time to market: The microservices 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 are typically deployed for redundancy and scalability.
Flexibility and Scalability: Monolithic applications require the entire system (and all of its functions) to scale simultaneously. With microservices, only the components or features that require extra performance need to be scaled. This is easily achieved by deploying more microservice instances, enabling better capacity planning and keeping a lid on software licensing costs.
Resiliency: With monolithic applications, 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 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.
Each microservice has its own isolated database
Each service also generally has its own database—that contains information pertaining 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 development approach in which an application is structured as a single, autonomous unit. With monolithic applications, 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 monolithic challenges with a highly modular approach. Applications are 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 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 microservices 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 microservices 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) fills 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, 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. Their 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, their rapidly growing engineering unit organizes its teams into small, autonomous “squads.” By re-architecting its platform to microservices, Hudl was able to align each squad to specific application functionality, and 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 microservices 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. 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. They’re a software architecture that involves splitting large applications into small pieces that communicate with each other. Each of these individual components can be built, deployed, and maintained by smaller groups of software engineers.
When it comes to deploying and managing large applications with thousands of microservices, 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 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.