What is Microservices Architecture?

Understanding and embracing microservices and process automation are imperative to an enterprise’s competitive ability and continued success. This guide will focus specifically on microservices, defining what they are and exploring how they work. We’ll also talk about the role of the cloud in microservices, best practices when implementing a microservices architecture, and its relationship to process automation.

Microservices are a type of application architecture in which an application is composed of small, independent services that communicate over well-defined APIs. Each service is owned by a small, self-contained team responsible for the service’s design and implementation.

Using a microservices architecture allows teams to be more innovative and agile, developing and releasing new features more quickly.

Note: In this guide, we’ll use “microservices” and “microservices architecture” interchangeably because the term microservices is often used to describe microservices architecture.

Microservices Architecture vs. Monolithic Architecture

Microservices architecture and monolithic architecture are similar in that they are both capable of powering organizations and running applications, but they accomplish this differently.

In a microservices architecture, developers build independent components (or services), each intended to perform a single function. Communicating through an API, these microservices are built toward business capabilities. Because they are created and run independently, developers can easily change, update, and deploy microservices without touching other areas of the application.

By contrast, in a monolithic architecture, functionality within the application is tightly intertwined with all other processes. Everything runs as a single service — which means that the entire architecture must be updated when a change needs to be made. If one part of the monolithic architecture breaks, there’s a good chance the entire system will come to a halt, as all elements are tightly-coupled.

Download Our Additional Resource: Decoding Microservices Best Practices for Developers

SOA vs. Microservices Architecture

Service-oriented architecture or SOA is a software development approach that uses reusable software components. Each component (or service) contains the code and data integrations the application needs to execute a particular business function, like checking the validity of a customer’s credit card during the online checkout process. Because they can reuse services and components in other applications throughout the enterprise, SOA saves development teams significant amounts of time.

If you think SOA sounds a lot like microservices architecture, you’re correct. Both architectures comprise loosely-coupled, reusable services that often work independently. But there are several differences, as well:

• Intent: Reusability of components is the primary goal of SOA; for microservices, the mission is “built for replacement,” focusing on team organization and the exchangeability of individual components.
• Communication: SOA services have to use an enterprise service bus (ESB) to communicate, while microservices each have their own communication protocol.
• Interoperability: SOAs tend to use heterogeneous messaging protocols like AMQP and SOAP. Microservices use simpler, lightweight messaging protocols like JMS and HTTP/REST.
• Speed: SOAs frequently operate more slowly than microservices architectures because they focus on sharing resources versus duplicating them.

To understand how microservices work, it's best to use an example. Imagine that your team is fully empowered to own a microservice around SIM card provisioning. You can freely choose your tech stack (staying within the boundaries of your enterprise architecture) and your team deploys and operates that service itself.

This allows you to implement or change the service at your own discretion, without having to ask others to do anything for you or join a release train. This means your team can quickly deliver changes while increasing their motivation, as owning their service makes team members feel empowered.

A microservices architectural style, however, does have an impact on process automation. Automating one business process typically involves multiple microservices. And unlike SOA that requires an orchestration process “outside” of the services, microservices architecture doesn’t allow business logic outside of the microservices. Therefore, the collaboration between microservices is within the microservices themselves.

Microservices Architecture Example

Take for example a customer onboarding service. The microservice owns the business logic around onboarding. The team can decide to use a workflow engine and BPMN to automate that process, which then orchestrates other microservices. The decision is internal to the microservice and not visible from the outside.

Communication between the microservices is done via APIs, not through the BPM platform. Processes are part of the business logic of a microservice; no central workflow engine is needed.

Containers vs. Serverless Microservices

Containers and serverless microservices both allow developers to create applications in the cloud with less overhead than a virtual machine. But there are several differences:

• Cost: Containers are always running and billed continuously; serverless applications only run when called upon, so you are only charged for actual usage.
• Scalability: Container developers must predetermine the number of containers they need to run; serverless can automatically scale up and down in response to demand changes.
• Deployment speed: Containers need to be configured before deployment, after which they take a few seconds to deploy; serverless applications can be deployed in milliseconds.
• Maintenance: Developers are responsible for updating containers; serverless vendors are responsible for maintenance.

Common Microservices Architecture Patterns

API Gateways

An API gateway pattern is an integration pattern that serves as a single entry point between client apps and your microservices. It provides a buffer between the client’s needs and the system’s underlying services.

Decomposition

There are two main ways that developers can apply decomposition:

Decomposition by domain: Developers define services that match the subdomains of domain-driven design, identifying the solution deployment space and the services needed. Each subdomain focuses on a specific aspect of the business, such as device communication or user management.

Decomposition by module: Developers define components based on modules or features, with different teams taking responsibility for each individual module.

Event Sourcing Pattern

An event sourcing pattern is an operational approach to handling data driven by an event sequence. All changes to an application’s state are recorded in the order in which they were applied, creating an audit log. Event sourcing is a highly scalable, decentralized change handling approach.

Service Discovery Pattern

There are two general types of service discovery patterns: client-side discovery and server-side discovery.

Client-side discovery pattern: Service clients search a registry using a load-balancing algorithm to find an appropriate available service. When services start up, their location is noted in the server registry and deleted when they shut down.

Server-side discovery pattern: The client-service consumer is not aware of the registry; instead, they make requests through a router. The router searches the registry and forwards requests to the right location. API gateways select the right endpoints for clients and remove the need for them to handle load balancing.

Aggregator Pattern

The aggregator pattern addresses how an application should aggregate the data each service returns and deliver the response to the consumer. It handles this in one of two ways:

• The API gateway partitions the request to multiple microservices and aggregates data to send to the consumer, or
• A composite microservice calls each required microservice individually, aggregating and transforming the data before returning it to the consumer

Database or Shared Data

There are two main database architecture approaches to microservices:

Database per service: Each microservice has its own database that is only accessible through that microservice’s API.

Shared database per service: While database per service is the preferred approach, a shared database can be used as a workable solution when migrating from a monolithic architecture to a microservices one.

How Do Microservices Communicate With Each Other?

There are two common messaging patterns used to facilitate microservice communication:

Synchronous communication: The caller waits for a response from the receiver using a protocol such as HTTP or gRPC.

Asynchronous message passing: This pattern doesn’t wait for a response; instead, one or multiple services process the messages asynchronously.

Benefits of Microservices

“Given multiple converging market pressures, organizations are accelerating the pace and increasing their investment toward transforming to become a truly digital enterprise.”

• Enhanced Productivity: Because they separate applications into smaller, independent components, applications are easier for developers to build and maintain.
• Increased Scalability: Development teams can determine the best language or technology for each microservice without worries about incompatibility.
• Improved Resiliency: Microservices make it easier for developers to pinpoint and fix the underlying cause of any performance issues.
• CI/CD: Microservices make it possible for cross-functional teams to troubleshoot, test, develop, update, and deploy services independently.
• Ease of Understanding: Microservices architecture is easier for developers to understand each service’s functionality.
• Better Support for DevOps: Microservices architecture lets organizations separate applications into smaller services, allowing delivery teams to individually tackle services.
• Faster Development Cycles: Because microservices have both a smaller codebase and a more narrow scope, developers can quickly deploy new features.
• Modularity: Microservice architecture offers better fault isolation. The failure of a single microservice does not mean the system’s failure.
• Scalability: Because microservices are individual, separate services, developers can scale critical services without scaling the entire application.

Cons of Microservices Architecture

• Testing Complications: Because microservices are individual, it’s challenging to perform global testing; developers must confirm each dependent service before testing.
• Information Barriers: The sheer volume of microservices can make it more difficult to share information across services.
• Increased Complexity: A distributed system with a large volume of microservices can increase the application’s level of complexity.
• Up-front Costs: If your enterprise is currently running a monolithic architecture, there will be up-front costs for your infrastructure (e.g., hosting, maintenance, security).

Who Needs Microservices?

Many times organizations wonder who needs microservices? Common scenarios include:

• You’re creating agile applications that require optimal innovation and speed of delivery
• You’re ready to embrace an approach that facilitates agility, scalability, and manageability
• You find your business needing to rewrite/rework legacy applications to stay up-to-date with business requirements
• You have individual, standalone modules that need to be reused

While microservices aren’t exclusive to a cloud environment, they are often used together. One of the main reasons for this is their inherent scalability.

Because microservices can be individually deployed and scaled, they maximize the benefit of cloud computing’s pay-only-for-what-you-use infrastructure — reducing costs across the board.

The flexibility of microservices can lead to complex tech stacks that present management challenges, but the vendor-managed cloud backend can help businesses reap the benefits of microservices without management headaches.

Implementation involves two primary areas: migrating from monolithic infrastructure and determining whether to use commands or events for inter-service communication — orchestration vs. choreography.

Migrating from Monolithic to Microservices

Once you’ve decided to migrate, a methodical approach is the only reliable path forward.

Monolith decomposition involves the three C’s:

• Capture: Identify the functionality you want to move to a microservice.
• Communication: Insert a proxy to intercept calls and divert them to the new microservice.
• Capabilities: Piece by piece, start shifting functionality from the original monolith to the new microservices.

However, simply implementing microservices just replaces a monolith with microservices but doesn’t solve all business problems on its own. As more microservices become involved in single business processes, serious drawbacks appear if not carefully managed. End-to-end business process orchestration and monitoring can become incredibly difficult, greatly limiting scalability and eliminating the benefits of microservices.

Careful journey mapping during your monolith decomposition and while building out your newly established microservices architecture is crucial.

Microservices Orchestration vs. Choreography

Smart microservices-based architecture design will incorporate both commands and events. Choreography and orchestration each have different benefits and drawbacks, and intelligent businesses incorporate both styles.

Event-Driven Communication / Choreography

When an event occurs in the system — for example, when an order is placed — microservices emit events without knowing which other microservices will react to them. Microservices receive notifications when event topics they’ve subscribed to are fired, without knowing where the event originated.

Pros: Enables microservice independence and developer team autonomy.

Cons: Event chains are not explicitly defined anywhere, making monitoring and troubleshooting nearly impossible.

Command-Driven Communication / Orchestration

When an event occurs — for example, when an order is placed — one microservice tells another to perform a specific action. One microservice controls the activity flow, what happens, and when.

Pros: The sending microservice knows exactly which microservices will receive its commands. Receiving microservices cannot ignore commands, but can accept or reject them.

Cons: Service independence is reduced; the sending microservice must know the receiving microservice exists and is operating, and must wait for a response.

Best Practices for Microservices Architecture

Following best practices will help you make the most of your microservices investment:

Create a Separate Build for Each Microservice

Always create a separate build for each microservice so you can pull component files at the appropriate requisition levels. While different microservices may pull some of the same files at different revision levels, this ensures that introducing a new microservice won’t be complicated and won’t affect the broader system.

Use Workflow Engines to Manage Microservices

Microservices give development teams unparalleled agility, enabling them to deliver updates without constantly rebuilding and relaunching the entire application. However, managing multiple microservices that communicate to complete a process requires attention to maximize your investment.

Camunda and its workflow engine gives you complete visibility into your microservices, enabling effective business process management and reporting. Some businesses implement decentralized workflow engines across their microservices, enhancing team autonomy even further.

Workflow engine benefits for managing microservices include:

• Allows an instance to persist through states — beneficial in longer-running processes such as multi-step payment processes that span days or weeks
• Makes it simpler to discover, understand, and modify a business process
• Coordinates and correlates messages across processes, deciding on next steps
• Compensates for problems, undoing steps already completed
• Tracks time and automatically takes action or switches paths when messages aren’t received in time
• Allows you to specify what should happen on error paths
• Reports real-time status of all process instances

Deploy in Containers

Deploying thousands of microservices can be cumbersome without containerization. Containers require a single deployment tool for multiple microservices, and containers know how to run a microservice inherently.

Get Your Team Onboard

Moving from monolithic to microservices is a tedious and time-consuming process that spans business units. While the increased ease-of-use and business agility are worth it, the process can be difficult. Collaborating with stakeholders across your organization ensures buy-in and keeps users informed throughout the transition.

Design Microservices to be Loosely Coupled

Microservices architectures need services to be as loosely coupled as possible. Loosely coupled services have minimal dependencies on other services while demonstrating high cohesion and doing their function well.

Monitor, Monitor, Monitor

Continuously monitoring the performance of your microservices and the availability of your resources is crucial — avoid a “set it and forget it” approach. Ongoing monitoring allows you to identify compromised resources quickly, enhancing security.

Leverage Domain-Driven Design

This design philosophy maintains that the language and structure of code should match the larger business domain, prioritizing domain logic and a focus on the core domain. This creates collaborative design processes that allow technical and domain experts to communicate and iterate on models that address problems across the business.

Use RESTful APIs

APIs are a requirement of microservices architecture communication. RESTful APIs for microservice interfaces are based on open networking principles, making them optimal models.