Close

Microservices and microservices architecture

Learn the pros and cons of microservices and how they differ from monoliths.

Not very long ago, the preferred method of building software applications was a monolithic architecture, which was as a single, autonomous unit. This approach worked well for many developers until applications increased in complexity. When a modification to a small section of code is made in a monolithic system, it requires rebuilding the entire system, running tests on the entire system, and deploying an entirely new version of the application.

Then along came microservices, an approach that breaks down software systems into smaller units that are autonomously developed and deployed. The microservices architecture was driven by the DevOps movement that seeks to frequently deliver updates, like new features, bug fixes, and security improvements. It also became, in many instances, a path for businesses to rewrite legacy applications using modern programming languages and updates to a technology stack.

Microservices are a collection of small units that continuously deliver and deploy large, complex applications.

What are microservices?


A microservices architecture, also simply known as “microservices”, is an approach to building an application as a series of independently deployable services that are decentralized and autonomously developed. These services are loosely coupled, independently deployable, and easily maintainable. While a monolithic application is built as a single, indivisible unit, microservices break that unit down into a collection of independent units that contribute to the larger whole. Microservices are an integral part of DevOps, since they are the basis for continuous delivery practices that allow teams to adapt quickly to user requirements.

Microservices illustration

A microservice is a web service that is responsible for one piece of domain logic. Multiple microservices combine to create an application, with each providing a piece of functionality for a domain. Microservices interact with each other using APIs, like REST or gRPC, but don’t have knowledge of the internal workings of the other services. This harmonious interaction between microservices is a microservice architecture.

With a microservices architecture, developers can organize in smaller teams specializing in different services, with different stacks and decoupled deployments. For example, Jira is powered by multiple microservices, each providing specific capabilities, including searching issues, viewing issue details, comments, issue transitions, and more.

Characteristics of microservices


There is no formal definition of a microservices architecture, but there are some common patterns or characteristics that are important to know.

Autonomous components

The basic building block of a microservices architecture is a component, which can be a package of software, web service or resource, application, or a module that contains a series of related functions. Or, more simply explained by Martin Fowler: “software components are things that are independently replaceable and upgradeable.”

In a microservices architecture, each component can be developed, deployed, operated, changed, and redeployed without compromising the function of other services or an application’s integrity.

Components are used with other components to deliver a customer experience or business value. The most common are services and libraries but can encapsulate CLI tools, mobile apps, front-end modules, data pipelines, machine learning models, and many other concepts that can be applied within a microservices architecture.

Clean interfaces

Once individual components are established, they require a substantial amount of logic to communicate with each other through a communication mechanism like RPC, REST over HTTP, or an event-based system. These mechanisms may be synchronous or asynchronous methods and microservices may use a combination of both. 

The most important aspect is that each microservice should provide a clear, intuitive contract that describes how a consumer of that service can use it. This is typically done through an API published alongside the service.

You build it, you run it

The DevOps philosophy of “you build it, you run it” emphasized that you cannot change an architecture into microservices without thinking about how teams are structured. DevOps re-aligns incentives across functional roles — development, QA, release engineering, operations — into a single team with a shared goal of building high-quality software. DevOps practices like CI/CD, automated testing, and feature flags accelerate deployment and help maintain system stability and security. Plus, each team can build and deploy microservices that it owns without affecting other teams. 

The evolution of the cloud simplified the building, deploying, and operating of microservices. Infrastructure automation techniques like continuous integration, continuous delivery, and automated tests help teams.

Service-oriented architecture vs. microservices


Service-oriented architecture (SOA) and microservices are two types of web service architectures. Like microservices, an SOA comprises reusable, specialized components that work independently of each other. The distinction between the two architecture types is the bureaucratic classification of service types.

An SOA has four basic service types:

  • Business
  • Enterprise
  • Application
  • Infrastructure services


These types define the related domain-specific responsibility of the underlying services. Comparatively, microservices only have two service types: functional and infrastructure.

Both architectures share the same set of standards at different layers of an enterprise. The existence of a microservices architecture comes down to the success of an SOA pattern. Hence, a microservices architecture pattern is a subset of SOA. Here, the main focus is on the runtime autonomy of each service.

Benefits of microservices


Agile illustration

Agility

Since small, independent teams typically build out a service within microservices, it encourages teams to adopt agile practices. Teams are empowered to work independently and move quickly, which shortens development cycle times.

Weighing scale illustration

Flexible scaling

Since microservices are distributed by design and can be deployed in clusters, they enable dynamic horizontal scaling across service boundaries. If a microservice reaches its load capacity, new instances of that service can rapidly be deployed to the accompanying cluster to help relieve pressure.

Stacking blocks illustration

Frequent releases

One of the primary advantages of microservices is frequent and faster release cycles. As a key element of continuous integration and continuous delivery (CI/CD), microservices allow teams to experiment with new features and roll back if something doesn’t work. This makes it easier to update code and accelerates time-to-market for new features. 

Toolbox illustration

Technology flexibility

Microservice architectures don’t necessarily follow a set approach with one toolchain but allow teams the freedom to select the tools they desire.

Magnifying glass illustration

Focus on quality

The separation of business concerns into independent microservices means that the service team owning that service focuses on the completed quality deliverable.

Bullseye illustration

High reliability

By separating functionality, microservices reduce the risk of breaking an entire application or code base when releasing updates. It is easy to isolate and fix faults and bugs in individual services. You can deploy changes only for a specific service, without bringing down the entire application, which provides higher reliability.

Challenges of microservices


持续集成

持续集成是将代码更改自动集成到软件项目中的实践。它允许开发人员频繁地将代码更改合并到执行构建和测试的中央存储库中。这有助于 DevOps 团队更快速地修复缺陷、提高软件质量以及缩短验证和发布新软件更新所需的时间。

Lack of clear ownership

A microservices architecture adds confusion to who owns what. A DevOps team may run a combination of APIs, component libraries, monitoring tools, and Docker images for users to deploy an application. It’s important to have insight into information about components, including their owners, resources, and evolving relationships between other components. Precise communication and coordination is required between numerous teams so that everyone involved can easily find the required knowledge to understand a product.

Exponential infrastructure costs

Each new microservice added to production deployment comes with its own cost of test suite, deployment playbooks, hosting infrastructure, monitoring tools, and more.

Added organizational overhead

An added level of communication and collaboration is needed to coordinate updates and interfaces between microservice architecture teams.

Debugging

It can be challenging to debug an application that contains multiple microservices, each with its own set of logs. A single business process can run across multiple machines at different times, which further compounds debugging.

Incident response

It’s important to have microservice incident response intelligence that includes information such as who is using the microservice, where the microservice was deployed, how the microservice was deployed, and who to contact when things go wrong.

Microservices and DevOps: Two peas in a pod


Given the increase in complexity and dependencies of microservices, the DevOps practices of deployment, monitoring, and lifecycle automation are seen as integral to microservices architectures. That’s why microservices are often considered the first step to embracing a DevOps culture, which enables:

  • Automation
  • Improved scalability
  • Manageability
  • Agility
  • Faster delivery and deployment
     

Key technologies and tools for a microservices architecture


Containers, Docker, and Kubernetes

A container is simply the packaging of an application and all its dependencies, which allows it to be deployed easily and consistently. Because containers don’t have the overhead of their own operating system, they are smaller and lighter-weight than traditional virtual machines. They can spin up and down more quickly, making them a perfect match for the smaller services found within microservices architectures.

With the proliferation of services and containers, orchestrating and managing large groups of containers is essential. Docker is a popular containerization platform and runtime that helps developers build, deploy and run containers. However, running and managing containers at scale is a challenge with Docker alone. Kubernetes and other solutions like Docker Swarm, Mesos, HashiCorp Nomad, and more help to address containerization at scale. 

Containerization and the deployment of containers is a new pattern of distributed infrastructure. Docker and Kubernetes package a service into a complete container that can be rapidly deployed and discarded. These infrastructure tools are complementary to the microservices architecture. Microservices can be containerized, easily deployed, and managed using a container management system.

API gateways

The individual services in a microservices architecture communicate with each other through well-defined APIs. An API gateway acts as a reverse proxy by accepting API calls, collecting the servicers to fulfill them, and returning results. API gateways provide an abstraction serving a single API endpoint, even though APIs are serviced by multiple microservices. API gateways can also consolidate concerns like rate limiting, monitoring, authentication, authorization, and routing to the appropriate microservice.

Messaging and event streaming

Due to the distributed nature of microservices, teams need a means of sharing state changes and other events. Messaging systems communicate between microservices, allowing some microservices to process events as part of their primary interface. For example, changes to Confluence pages results in an event that triggers a reindex for search and notifications to those watching the page.

Logging and monitoring

Microservices make it difficult to identify an issue and resolve it across multiple services. It’s important to have observability tools for logging, monitoring, and tracing. This helps with understanding how microservices behave, identifying potential problems, troubleshooting issues, and debugging failures.

Continuous integration/continuous delivery

One of the primary advantages of microservices is frequent and faster release cycles. As a key element of CI/CD, microservices allow teams to experiment with new features and roll back if something doesn’t work. This makes it easier to update code and accelerates time to market for new features.

Developer portal

As distributed architectures increase in complexity, development teams can benefit from a tool that consolidates information about engineering output and team collaboration in one place. For example, Atlassian Compass was designed to help tame microservice sprawl by providing data and insights across DevOps toolchains.

Future of microservices


Containerization and the deployment of containers is now a common pattern of distributed infrastructure. Tools like Docker and Kubernetes package up a service into a complete container, which can be rapidly deployed and discarded. These new infrastructure tools are complementary to the microservices architecture, since microservices can be containerized, easily deployed, and managed using a container management system.

The adoption of microservices should be seen as a journey rather than the immediate goal for a team.

It can be helpful to start small in order to understand the technical requirements of a distributed system and scale individual components. Then gradually extract more services as you gain experience and knowledge.

开始使用 DevOps。

开始使用 DevOps 的最简方法就是识别小型价值流(例如:小型支持应用或服务),然后开始尝试一些 DevOps 实践。与软件开发一样,与一小群利益相关者一起转换单个数据流比尝试在组织内一次性过渡至全新的工作方式要容易得多。

Atlassian 提供了 Open DevOps 解决方案,该解决方案利用 Atlassian 和其他第三方工具来提供端到端 DevOps 流程。以 Jira 为支柱,团队可以使用 Atlassian 产品或将自己喜欢的产品整合到开放式工具链中。Atlassian 生态系统提供一系列可靠的集成和加载项,从而允许团队根据自己的需求自定义工具链。

请务必查阅我们的 DevOps 教程,了解自动化测试安全性可观察性功能标记持续交付的相关信息。

Devops 研讨会示意图