What are Microservices?
The term “microservices” refers to a software architecture approach that enables greater agility by breaking applications down into smaller components. These components are autonomous and typically aligned with a particular business or objective. The large, monolithic codebases that traditionally power enterprise applications make it difficult to move quickly. The monolithic approach also presents organizational alignment problems. By using the microservices approach, a large company can launch new products and services faster and align development teams with business objectives.
Characteristics of Microservices
Microservices are characterized by modular, autonomous services.
In a microservices architecture, applications are broken down into small, independent services. Services are typically focused on a specific, discrete objective or function and decoupled along business boundaries. Separating services by business boundaries allows teams to focus on the right goals and also ensures autonomy between services. Each service is developed, tested, and deployed independently, and services are usually separated as independent processes or software containers that communicate over a network via agreed APIs, although in some cases that network may be local to the machine. Multiple instances of the same microservice are typically deployed, providing redundancy and scalability.
Alignment to Business Objectives
When decomposing an application's architecture into microservices, the best practice is to align them with organizational boundaries. That alignment enables the team which is responsible for a function within the business to own the creation and management of the associated microservices – allowing them to work relatively independently and apply their business knowledge. Similarly, communication between microservices would align with inter-organizational communication paths.
Database per Service
Best practice is for each service to connect to its own database. The reasons are:
In a shared database environment, a catastrophic failure with the database infrastructure has the potential to affect multiple microservices and result in a substantial outage. Isolating database instances also isolates failure scenarios.
The development and operations team for a particular microservice can safely make changes to their database contents and configuration without risk of impacting other microservices.
Thus, it is recommended to decouple any shared databases so that each microservice has its own.
In cases where you need to share information between services, you should do that explicitly – when the data changes in one service, it should notify the other service so that it may update its database. You would typically use a messaging system such as Apache Kafka for this.
Benefits of Microservices
The microservices approach conveys many advantages, including a faster time to market, flexibility, resiliency, organizational alignment, and lower cost.
Faster Time To Market
Implementing a microservices architecture can enable organizations to get their applications to market faster. Changes to a monolithic application, even if small, require redeploying the whole application stack, introducing risk and complexity. In contrast, updates to a service can be committed, tested, and deployed immediately and changes to an individual service will not impact the rest of the system.
Flexibility and Scalability
The microservices approach also provides flexibility when scaling an application. Monolithic applications require that the entire system (and all of its features) scales simultaneously. With microservices, only the components or features that require extra performance need to be scaled. Services can be scaled by deploying more microservice instances, which enables more effective capacity planning and lower software licensing costs, thus lowering overall TCO.
With monolithic applications, the failure of a component can compromise the whole application. In microservices, each service is isolated to prevent cascading failures from bringing down the entire system. If all instances of an individual microservice failed, the overall service might degrade, but the other components could still provide valuable services.
Microservices enable technical groups to align to the organizational needs, and teams can be sized to match the required tasks. Typically microservices teams are smaller, cross-disciplinary (Ops, Dev, QA), and focused on a single component of the overall application. By providing ownership over individual services, rather than functional areas, microservices also serve to break down the silos between teams and improve collaboration. This approach is especially powerful for distributed and remote teams. (For example, teams in different locations can release and deploy features independently.)
Reduction in Cost
Microservices lower costs by improving hardware utilization and making development teams more efficient. Through the use of containers, applications and environments (design, test, staging, production, support) gain efficiencies while sharing the same infrastructure. For development teams, microservices reduce technical debt, by minimizing high-risk code refactoring. In a monolithic app, there is a significant time and resource cost associated with maintaining a large codebase. In contrast, by breaking the the application into API-accessible microservices, individual services can be managed independently and you can spend less time on maintaining and updating code.
Comparing Monolithic and Microservices Architectures
The table below summarizes some of the key differences between different architectural approaches.
|Application architecture||Single unit||Modular|
|Team organization||Functional expertise (e.g., UI, DBA, middleware)||Business unit|
|Change management||Full redeploy||Redeploy individual microservices|
Technologies that Enable Microservices
The emergence of technologies such as containers (Docker, LXC) and orchestration frameworks (Kubernetes, Mesos) mitigate many of the problems that prevented using microservice architectures in the past.
Containers are lightweight run-time environments that provide isolation and scalability with minimal impact to performance and capacity. Packaging is simplified because the same environment can simultaneously host development, support, test, and production versions of the application, so that going from dev to test to QA to production is easier. Containers work very well in a microservices environment as they isolate services to an individual container. Updating a service becomes a simple process to automate and manage, and changing one service will not impact other services, provided that you maintain APIs.
Docker is the most popular container technology in use today. Its simplicity and rich ecosystem makes it incredibly powerful and easy to use.
Docker containers are created from images which have been designed to provide a particular capability – whether that be, for example, just a base operating system, a web server, or a database. Docker images are constructed from layered filesystems so they can share common files, reducing disk usage and speeding up image download. This makes them much more efficient than virtual machines. Docker Hub provides thousands of official and community images, which can be extended or used as is, to quickly create a container that's running the software you want to use. All it takes to get MongoDB up and running is the command docker run --name my-mongodb -d mongo. Proprietary images can be made available within the enterprise using a local, private registry rather than Docker Hub.
When organizations start running containers at scale, many look to orchestration frameworks to help manage the increased complexity. Orchestration frameworks help deploy and manage containers, provision hosts, instantiate containers, handle failures, and provide automated scaling.
Kubernetes is one of the most capable and popular orchestration frameworks for Docker; its key features include:
Automated deployment and duplication of containers
Online scaling, adding or removing containers as requested
Load balancing over groups of containers
Rolling software upgrades of containers
High availability by recreating failed containers
Allowing communication between containers and with external systems by exposing network ports
Mesos is another widely used Docker orchestration framework, capable of scaling across tens of thousands of physical machines. Mesos has fewer built-in features than Kubernetes, leaving areas such as resiliency and load balancing to the application.
With serverless computing, the underlying infrastructure (physical and virtual hosts, virtual machines, containers), as well as the operating system, are abstracted away from the developer. Applications are run in stateless compute containers that are event triggered (e.g., a user uploads a photo, which triggers notifications to his/her followers). Developers create functions and depend on the infrastructure to allocate the proper resources to execute the function. If the load on the function grows, the infrastructure will create copies of the function and scale to meet demand. AWS Lambda, Google Cloud Functions, and Azure Functions are popular hosts for serverless computing.
Serverless architectures are a natural extension of microservices. Similar to microservices, serverless architecture applications are broken down into specific core components. While microservices may group similar functionality into one service, serverless applications delineate functionality into finer-grained components. Custom code is developed and executed as isolated, autonomous, granular functions that run in a stateless compute service.
As explained above, a typical characteristic of microservices is that each autonomous service maps to its own data store, rather than a shared database. This approach allows for greater flexibility in building each service and reduces the risk associated with a single, monolithic database.
MongoDB is a document database commonly used for microservices architectures because of its flexible data model, redundancy, and scalability. MongoDB’s dynamic schema is ideal for handling the requirements of microservices. When rolling out a new feature that changes the data model, there’s no need to update all of the existing records, something that can take weeks for a relational database.
With built-in redundancy through replica sets and automatic partitioning through sharding, MongoDB is well-suited to meet the distributed nature of microservices.
Containers and orchestration as a service
As seen, containers and orchestration can significantly simplify deploying microservices in a scalable, robust, and automated manner. However, implementing and managing the container/orchestration infrastructure introduces additional complexity – especially if that infrastructure needs to be scalable and highly available itself.
For that reason, many users choose to let a cloud provider take care of that, consuming it as a service. This is especially tempting if you are planning on running the containers in the public cloud anyway. The popular providers include:
Google Container Engine (Kubernetes and Docker containers)
Amazon EC2 Container Service (proprietary orchestration and Docker containers)
Microsoft Azure Container Service (Kubernetes and Docker containers)
Startups and enterprises have adopted microservices due to their ability to provide agility, modularity, and scalability while facilitating organizational alignment. Below are a few examples of companies that have implemented microservices with success.
The Internet and mobile technologies put power firmly in the hands of the customer. This is true nowhere more than in the world of price comparison services, allowing users to find the best deals with just a few clicks or swipes. comparethemarket.com has grown to become one of the UK’s leading providers, and one of the country’s best known household brands.
To stay ahead of the competition, comparethemarket transitioned its price comparison services from monolithic applications running against a SQL Server database, deployed in on-premise facilities, to a microservices environment with MongoDB databases, all deployed into the public cloud. With the adoption of continuous integration and delivery along with MongoDB Ops Manager, comparethemarket.com now releases services twice as quickly as they did on their legacy platform, pushing new features live daily.
HM Revenue & Customs
HM Revenue & Customs, the UK’s tax body, has been a leading agency in the government’s digital transformation program. Their Multichannel Digital Tax Platform (MDTP) gives access to digital tax products that allow British citizens and companies to manage their tax affairs. The MDTP is a Platform As A Service (PaaS) that hosts 100+ Scala/Play microservices that represent 20+ citizen and company tax products.
Hudl is a sports software startup that uses MongoDB as the database for its online video analysis platform. They built their original platform as a monolith, but as the codebase grew to over 3 million lines, it became harder to maintain. For example, it was taking 30 minutes to build and deploy updates. Also, their engineering organization was growing rapidly, with teams organized into small, autonomous “squads.” Re-architecting to microservices enabled them to align these squads to microservices dedicated to specific application functionality and deploy code faster.
To learn more about Hudl’s journey, watch VP of Engineering Jon Dokulil present on their experience moving from monolith to microservices.
UPS i-parcel is a global e-commerce and operations service that enables retailers with operations in the United States and the United Kingdom to sell across borders to online shoppers in their native language and currency. UPS i-parcel dynamically provides buyers with a summary of all landed costs, including duties and taxes, in the retailer’s shopping cart so there are no surprises when the order arrives.
Microservices are an essential part of UPS’s technology strategy. When UPS acquired i-parcel and the business grew, the team faced scaling issues with their monolithic architecture. Microservices enabled UPS i-parcel to align teams to specific products, creating a strong sense of accountability for developers. Microservices delivered many benefits to UPS i-parcel, such as faster development time and a fine-grained feedback loop for each service.
To learn more about UPS i-parcel’s journey, watch Vice President of Technology Yursil Kidwai present on their experience moving from monolith to microservices.