11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

Licensed for Distribution

This research note is restricted to the personal use of Felix Freeman

([email protected]).

Reference Architecture Brief: Microservices

Architecture Delivery Platform
30 October 2023 - ID G00799282 - 31 min read

By Kevin Matheny

Initiatives: Application Architecture and Integration for Technical Professionals

To deliver microservices, application technical professionals need a platform that enables

building, deploying and operating microservice instances. It must provide capabilities for
service isolation, secure service communication, data persistence, life cycle management
and observability.

Architecture Brief
Microservices architecture (MSA) is a design and delivery paradigm for cloud-native distributed
applications that incorporates service-oriented architecture (SOA) and 12-factor app principles.
Organizations use MSA to improve development agility, increase deployment flexibility and
enable precise scalability to better meet business objectives.

The fewer barriers and handoffs there are between development and operations, the faster
product teams will be able to deliver changes. Accordingly, the delivery platform must span both
development and operations of microservices. Implementing MSA requires a delivery platform
that enables:

Independent service development — Product teams creating and updating microservices

need a platform that enables quick, reliable development, testing and deployment. These
developer-oriented capabilities need to be consistent with and linked to the production
environment into which services will be deployed.

Dynamic, cloud-native runtime execution — Microservice instances need an execution

environment in which to run. To enable loose coupling and a tight focus on service
capabilities, this platform should support dynamic scaling, support cloud-native architecture
patterns and provide shared capabilities for access control, networking, persistence, identity,
security and observability.

https://www.gartner.com/document/4889731 1/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

Service communications — Loosely coupled services require API gateways, service mesh
and/or event brokers to provide consistent interfaces for interservice communication and
execution of client/consumer processes.

Microservices platform operations — Operations teams responsible for the platform itself
need visibility into how services and the platform are performing to guide optimization of the
platform and ensure performance is meeting expectations. Microservices product teams
need production performance and usage data to aid in troubleshooting and bug fixes.

Continuous learning and improvement — Microservices product teams need information

about microservice performance and usage to inform enhancements and the creation of new
services.

For additional information on successful adoption of MSA, read Solution Path for Increasing
Application Agility Using Microservices Principles and How to Succeed With Microservices
Architecture for Cloud-Native Applications.

Architecture Use Cases

MSA is commonly used for the following:

Refactoring existing applications to enable rapid change. Moving from a monolithic or

coarse-grained architecture to a well-designed and supported distributed MSA can greatly
increase the development agility of an application.

Implementing domain-driven design (DDD). Although DDD does not require MSA,
organizations find that MSA principles are a good fit for implementing software architectures
that align services to domains and bounded contexts.

Replacing existing applications incrementally using a new architecture. Like refactoring,

gradual replacement of an application distributes the disruption of adopting new
technologies and architectures.

Customer-facing applications. Web and mobile applications operate in a technical, social

and economic environment that expects continual change to optimize experiences and add
new features. The change-friendliness of MSA is a good match for these applications, as is
the inherently headless nature of microservices.

Architecture Diagram
The primary benefit of MSA for most organizations is faster delivery of new and changed
application features to production. To enable this, microservices must be loosely coupled,
tightly focused on a single responsibility and owned by a single small, skilled and accountable
team. Capabilities such as access control, networking, data persistence, service discovery,
identity and security should be provided by a platform so that microservices can be focused on
implementing functionality.

https://www.gartner.com/document/4889731 2/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

The components shown in Figure 1 represent the capabilities needed to deliver and operate
MSA at scale. The figure uses colored arrows to show three workflows across the components:

Building and deploying microservices

Handling transaction requests from outside of the platform

Monitoring and observability of the components

The diagram is organized so that the life cycle flow of microservices is from left to right, and the
transaction flow is from top to bottom. Each of the major components is described below.

Figure 1. Reference Architecture: Microservices Architecture

Delivery Platform

This is an abstract reference architecture; you will need to customize it to the specific
technologies and circumstances of your organization and your product development teams.

https://www.gartner.com/document/4889731 3/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

An MSA delivery platform should be operated by a dedicated team that treats the platform itself
as a product and development teams as customers. Doing so removes the cognitive load of
configuring and managing platform components from service delivery teams focused on
delivering business value. See Adopt Platform Engineering to Improve the Developer Experience
for information on platform engineering.

Architecture Capabilities and Components

To deliver the promised increases in agility and flexibility, microservices must be tightly focused
on their specific responsibilities and loosely coupled to other services. Because microservices
change frequently, the product teams developing microservices must be responsible for their
operations as well.

The capabilities of a microservices delivery platform are:

API Gateway

Application Data Services

Application Service Monitoring and Observability

Developer Experience

Development Infrastructure

Event Broker Cluster/Service

Microservices Application Networking

Microservices Execution Environment

Web Threat Protection and Access Control

API Gateway

An API gateway applies access policies to control access to APIs and services. It provides a
decoupling mechanism between API consumers and service implementation.

An API gateway is typically implemented as a reverse proxy with an extensible request-

processing pipeline that allows API-centric policy definitions to be applied to inbound and
outbound requests. API gateways commonly support policies such as:

Access management (authentication and authorization)

Traffic management (quotas and rate limiting)

Request routing and caching

Request and response validation

https://www.gartner.com/document/4889731 4/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

Payload filtering or transformation

Basic security checks

As a concentration point for API access, an API gateway can also collect API usage logs and
metrics for use in analytics, observability and API security monitoring.

API gateways are most commonly associated with REST APIs, but some can support policy
enforcement for GraphQL APIs, WebSocket, gRPC, SOAP and other protocols.

Example Technologies

The following are technologies that provide API gateway functionality:

Akamai API Gateway

Apache APISIX

AWS Amazon API Gateway

Axway Amplify

Google Apigee

Google Cloud API Gateway

Gravitee.io

IBM API Connect

Kong Konnect

KrakenD

Mulesoft Universal API Management

Microsoft Azure API Management

Solo.io Gloo Gateway

Software AG webMethods API Gateway

Spring Cloud Gateway

TIBCO Cloud API Management

Tyk Gateway

WSO2 API Manager

https://www.gartner.com/document/4889731 5/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

Key Component Characteristics

An API gateway has the following characteristics:

It must operate as a proxy that intercepts traffic to and from an API and enforces policies. It
should provide an extensible mechanism to define and implement pre- and postprocessing
filters.

Policy definitions must be defined in external configuration to enable policy updates

independently of infrastructure or deployment changes.

The API gateway should provide a resilient and scalable deployment, commonly behind load-
balancing infrastructure.

The API gateway should enable developer-centric configuration and management, through
integration into DevOps pipelines. Choose tools that encourage productivity for developers
who are both API providers and API consumers.

The API gateway should be optimized for the intended use case. For example, some
gateways provide a broad set of advanced mediation capabilities for managing B2B partner-
and customer-facing APIs supporting a variety of (often legacy) protocols. Lightweight API
gateways provide adequate policy controls for exposing BFF APIs to modern web and mobile
applications or internally exposed APIs implemented using microservices architecture.

Related Architecture Research

Decision Point for Mediating API and Microservices Communication

Comparing Architectures for Hybrid and Multicloud API Management

How to Evaluate API Management Solutions

How to Successfully Implement API Management

How to Deliver Sustainable APIs

Specific MSA Delivery Platform Considerations

In an MSA delivery platform, API gateways are used as either an ingress gateway or a
microgateway.

An ingress gateway is deployed at the boundary of the application or a container

management system. This gateway controls access to the APIs that the application
exposes for use by other applications and services. This is the use case shown in Figure 1.

A microgateway, sometimes called a lightweight gateway, manages service-to-service

communications. This is useful when microservices are relatively coarse-grained and more
isolated from one another. A simple gateway model is preferable to the complexity of

https://www.gartner.com/document/4889731 6/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

service mesh. This capability may also be delivered by a service mesh or by the native
capabilities of a container management system.
Only a subset of the APIs offered by the microservices on the MSA delivery platform will be
exposed outside of the delivery platform. The gateway-managed APIs should avoid coupling
to specific microservices architecture structures, allowing service implementation
architecture to evolve independent of the interface used by client applications and processes.

Application Data Services

Applications rely on data services to store, retrieve and manipulate both reference and
transactional data. This data may be structured, semistructured or unstructured, and the
solutions include relational and nonrelational databases, in-memory caches, object storage, and
others.

One important factor to consider is the placement of the data. Slow connections or higher
latency for data access will degrade the performance of applications or services, which is partly
dependent on their physical and logical network separation.

Relational databases are the most common implementation choice for persisting transactional
data for applications and services. These databases are optimized for efficient data reads and
writes and provide the crucial properties of atomicity, consistency, isolation and durability
(ACID). This ensures dependable handling of multiple records or data items, enabling them to
be updated or inserted as a single unit of work.

Data caches are a common subcomponent of the data layer. Caching speeds up data retrieval
and improves application performance. Frequently accessed, stable data is a good candidate to
be cached. However, caching introduces challenges including cache invalidation, maintaining
cache consistency and ensuring that cached data remains up to date. Choosing what to cache
requires careful analysis of the application’s use cases, data update frequency and the potential
impact of serving stale data from the cache.

Example Technologies

Relational Database Management Systems:

Amazon Aurora

MariaDB Enterprise Server

Azure SQL Database

Oracle Autonomous Database

PostgreSQL

Distributed Transactional SQL Databases:

https://www.gartner.com/document/4889731 7/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

Cockroach Labs CockroachDB

Google Cloud Spanner

MariaDB Enterprise Server

NuoDB

YugabyteDB
Key-Value Data Stores:

Aerospike

Azure Cosmos DB

Azure Table storage

Amazon DynamoDB

Cloud Bigtable

Redis Enterprise

Document Data Stores:

Amazon DocumentDB (with MongoDB compatibility)

Azure Cosmos DB

Couchbase

Google Cloud Firestore

Progress MarkLogic Server

MongoDB

Oracle Autonomous JSON Database

RavenDB

Wide-Column Data Stores:

Apache Cassandra

Azure Table storage

DataStax Enterprise

Apache HBase
https://www.gartner.com/document/4889731 8/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

ScyllaDB
Graph Data Stores:

Amazon Neptune

Neo4j

TigerGraph DB

Object Stores:

Amazon Simple Storage Service (Amazon S3)

Azure Blob Storage

Google Cloud Storage

Transactional/Analytical (HTAP) Computing Technologies:

SAP S/4HANA Cloud

SingleStore

Volt Active Data

In-Memory Caches/Data Stores/Grids:

GridGain In-Memory Computing Platform

Hazelcast

IBM WebSphere eXtreme Scale

Memcached

Redis Enterprise

Key Characteristics

Application data services must:

Implement mechanisms for data replication, fault tolerance and automatic failover to ensure
continued operations.

Implement backup and recovery mechanisms to ensure that data can be restored in case of
system failures.

https://www.gartner.com/document/4889731 9/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

Provide data masking and data encryption strategies to protect sensitive data from being
exposed.

Should provide the ability to cache frequently used and/or immutable data to improve
application performance.

Related Research

Decision Point for Selecting the Right DBMS

Data Engineering Essentials, Patterns and Best Practices

Next-Generation SQL Engines

Specific MSA Delivery Platform Considerations

If you are using the database-per-service model for your microservices, your data services
need to be able to create unique database instances for each microservices.

Avoid using data integration patterns such as synchronization or replication because it

creates coupling and limits the agility of services.

Ensure that data access is only through interfaces provided by the service, and disallow
direct access to service data stores. This is another source of coupling.

For guidance on additional concerns, see Working With Data in Distributed and Microservices
Architectures.

Application Service Monitoring and Observability

Application service monitoring and observability is a collection of methods and mechanisms for
recognizing and resolving software issues such as bugs or performance problems. Monitoring
and observability are complementary disciplines. Monitoring is aimed at detecting known
existing or potential problems with application services and their supporting infrastructure.
Observability provides operations and development teams with the information needed to
diagnose and resolve problems.

To enable observability, development teams instrument application services to generate

actionable telemetry data. This data is collected, processed and consumed by an observability
solution that provides analysis and interrogation capabilities. Operations teams use these
capabilities to gain insight into application service performance and to support root cause
analysis. Observability is also important to the development life cycle; it can reveal the
performance impacts of changes to application service code or infrastructure. Infrastructure
monitoring data supports observability by providing visibility into the impact of infrastructure on
the health of a service.

https://www.gartner.com/document/4889731 10/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

Although both monitoring and observability generate telemetry, monitoring telemetry is

traditionally focused on metrics. In contrast, observability telemetry includes but is not limited
to distributed traces, logs and profiling in addition to metrics. Both monitoring and observability
benefit from ad hoc visualization capabilities across telemetry (e.g., service-level indicators
[SLIs]), calculated measurements (e.g., service-level objectives [SLOs]) and calculated business
metrics (e.g., service-level agreements [SLAs]). Monitoring and observability solutions typically
include visualization capabilities but may also be integrated with third-party visualization
solutions. Common reasons for this are a desire to provide enhanced functionality or to unify
dashboards across multiple telemetry sources.

Both monitoring and observability solutions generate events when they detect changes in the
state of an application or its infrastructure. Some of these events require human attention or
action; some will trigger automated actions; and some are simply informational. When these
events are sent to or picked up by an endpoint solution (e.g., artificial intelligence for IT
operations [AIOps], IT service management [ITSM]) or end user, it is referred to as alerting.

Example Technologies

The following are example technologies that enable monitoring and observability. The listed
technologies are not necessarily limited in function to the category in which they are listed. For
example, observability technologies can also provide instrumentation and visualization
capabilities.

Instrumentation:

bpftrace

OpenTelemetry

Prometheus

Grafana Pyroscope

Infrastructure Visibility:

collectd

Prometheus

Fluent Bit

Pixie

Observability Solution:

Dynatrace

Datadog
https://www.gartner.com/document/4889731 11/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

Honeycomb

New Relic

Splunk

Visualization:

Grafana Labs

Elasticsearch (Kibana)

Key Characteristics

Application service monitoring and observability solutions must:

Provide the ability to monitor ephemeral instances such as containers through infrastructure
visibility. Infrastructure visibility can leverage kernel instrumentation (i.e., eBPF) or the
scraping of HTTP endpoints to capture data from Kubernetes and containers.

Enable end-to-end tracing of transactions across service instances with distributed or

dynamic tracing. Distributed tracing is the end-to-end tracking of the complete path of a
request. Dynamic tracing captures application events as they move from one service to
another. The two types of tracing are different and provide different insights into application
problems. Distributed tracing is supported by code instrumentation and dynamic tracing is
supported by kernel instrumentation.

Provide the ability to interrogate correlated telemetry (e.g., logs, metrics and traces) for deep
diagnostics. The generation of observability telemetry from modern frameworks includes
shared metadata (e.g., TraceId) that allows for observability solutions to simplify the task of
data correlation for root cause analysis.

Provide visualizations for enhancing the analysis of performance and health data. Ad hoc
visualization of telemetry data aids in the quick identification of changes in application health
and performance. In addition, the calculation of SLOs and SLAs can measure the business or
organizational impact of performance problems over time.

Related Research

Assessing OpenTelemetry’s Importance to Application Performance Monitoring

How to Monitor Containers and Kubernetes Workloads

Monitoring and Observability for Modern Infrastructure and Applications

Solution Path for Modern Infrastructure and Application Monitoring

https://www.gartner.com/document/4889731 12/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

Developer Experience

Developer experience refers to all aspects of interactions between developers and the tools,
platforms, processes and people they work with to develop and deliver software products and
services.

Creating a superior developer experience requires providing an environment in which developers

can do their best work with minimal friction and maximum flow. A great developer experience
empowers developers and raises developer satisfaction and software quality. It also enables
organizations to innovate faster and retain top talent.

Nontechnical aspects of developer experience include providing focus time to enable deep
engagement with work and allowing developers to contribute to the wider community.

Key technical components of developer experience include:

Code Repository — In addition to storing code, tests and documentation, code repositories
provide capabilities for branching, merging, version control, collaboration and governance.
Code repositories may be self-hosted or SaaS.

Developer Portal — Developer portals help streamline access to platform resources and
establish consistency across teams. Capabilities include visibility into build status,
deployments and pull requests. Developer portals also provide access to self-service
capabilities, removing delays from the development process.

Service Catalog — A service catalog is an authoritative source of information about the

application services deployed and operating in the environment. The scope of the
environment may be a platform instance, an entire company or anything in between. Service
catalogs provide metadata including dependencies, ownership, support channels, change
history and operational metrics.

Testing Tools — Testing tools are used for creating, maintaining, automating and executing
tests as well as managing test data and test plans. These tools must support functional,
nonfunctional, integration and performance testing at a minimum.

Example Technologies

Code Repository:

Apache Subversion

Git

GitHub

GitLab

https://www.gartner.com/document/4889731 13/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

Developer Portals and Service Catalogs:

Atlassian Compass

Spotify (Backstage)

configure8

Cortex

OpsLevel

Port

UPS (Roadie)

Testing Tools:

Apache JMeter

JUnit

NUnit

PyUnit

Postman

Pact

SmartBear (PactFlow)

SmartBear (SoapUI)

Key Characteristics

Developer experience components must:

Increase developer productivity by minimizing effort required for tasks not related to actual
software development.

Be integrated with other platform components to streamline key activities.

Ensure that information presented is current, accurate and consistent.

Be intuitive and easy to use.

Be well-suited to the needs of the development team or teams using them. Enforcing a single
solution across multiple teams with different needs will suboptimize some teams, reducing
productivity and lowering morale.

https://www.gartner.com/document/4889731 14/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

Related Research

Adopt Platform Engineering to Improve the Developer Experience

Use Platform Engineering to Scale and Accelerate DevOps Adoption

How to Orchestrate Automated Tests With Continuous Integration

Specific MSA Delivery Platform Considerations

The service catalog is a crucial tool for operations. Because of the high rate of change in
MSA, the risk of issues arising from service dependencies changing, failing or misbehaving is
also high. Keeping the service catalog’s metadata up to date is essential so that operations
teams can quickly diagnose, resolve and escalate issues in production.

Development teams need the ability to control access to the services they create.
Microservice APIs are not designed for reuse by default, because that widens their scope and
increases the work required to support them, which slows development.

Development Infrastructure

Development infrastructure is a collective term for the capabilities developers require to create,
test and deploy service or application code. Key components include:

Application Stacks — These stacks are combinations of technologies that are confirmed to
work together, comply with architectural guidance and deliver performance that meets
organizational standards. These provide developers with a known good starting point and
provide “paved paths” to delivering applications. Preconfirmed application stacks remove
friction, lower the chance of issues resulting from inconsistency, and eliminate delays for
review and approval of new products or tools.

Artifact Repository — This is a storage system that holds binary artifacts such as compiled
code or container images. This system enables artifacts to be built once and then reused,
lowering the risk of inconsistency between environments. To enable reuse of artifacts,
environment configuration must be external to the code.

Build Automation — Automating builds removes effort on repetitive tasks and lowers the
chance of human error. This should be incorporated into a continuous integration approach,
with builds happening on each commit of code.

Deployment Automation — Automating the deployment process removes the potential for
human error and speeds the deployment process. This should be accompanied by
infrastructure-as-code practices and the use of immutable instances in production to ensure
that production code remains in sync with code in the code repository.

Environment Management — Environment management encompasses tools and technology

that provide the ability for developers to create and manage resources in the development

https://www.gartner.com/document/4889731 15/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

environment without requiring outside assistance. This removes dependencies and delays in
the development process.

Example Technologies

Artifact Repository:

Amazon Web Services (AWS) CodeArtifact

Azure Artifacts

JFrog Artifactory

Sonatype Nexus Repository

Build Automation:

Apache Maven

AWS CodeBuild

Jenkins

JetBrains (TeamCity)

Microsoft Power Platform Build Tools

Deployment Automation:

Red Hat Ansible Automation Platform

Progress Chef

Jenkins

VMware (Saltstack)

Environment Management:

AWS CloudFormation

AWS Proton

Azure Resource Manager

Crossplane

Google Cloud Deployment Manager

https://www.gartner.com/document/4889731 16/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

HashiCorp Terraform

Quali

Key Characteristics

Development infrastructure must:

Function in all the environments needed by the organization’s software development life cycle
(SDLC).

Provide the ability to compile code, generate artifacts, run automated tests, and deploy code
and artifacts.

Provide integration points for automated testing, static security scanning and code quality
validation.

Implement environment configuration outside of application code.

Follow a prescribed sequence of environments (e.g., Dev->QA->UAT(Pre-Prod)->Prod) for all

deployments.

Integrate with the developer’s integrated development environment (IDE) to streamline the
developer experience.

Related Research

Keys to DevOps Success

Use Platform Engineering to Scale and Accelerate DevOps Adoption

To Automate Your Automation, Apply Agile and DevOps Practices to Infrastructure and
Operations

Automate the Application Delivery Value Stream

Specific MSA Delivery Platform Considerations

The runtime infrastructure of your development environment (and all preproduction

environments) should be as similar to production as is feasible. The fewer differences there
are between environments, the lower the chance of configuration or environmental issues
arising when deploying to production. Host your nonproduction environments on the same
cloud platform as your production environment, and use the same technologies to reduce
variation between environments.

Avoid creating full replicas of the services in your production environment whenever feasible.
Instead, focus on providing mock instances or stubs, particularly when you have interface
specifications, to reduce complexity and cost.

https://www.gartner.com/document/4889731 17/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

Event Broker Cluster/Service

An event broker is the core middleware component in event-driven architecture. It is responsible

for receiving published events from sources and delivering them (via topics and/or subscription
configuration) to subscribed event sinks. In an event-driven application architecture, reliability of
the application is dependent upon a reliable event broker deployment. Hence this component is
deployed as a resilient cluster of broker instances when self-managed or resilience is provided
by the service provider.

Event brokers come in many forms, but the three most common are:

Log-oriented brokers — This kind of broker processes topics as append-only logs.

Queue-oriented brokers — This kind of broker uses a queue-based architecture internally and
is typically capable of supporting queue-based communication patterns in addition to
publish-subscribe.

Subscription-oriented brokers — This kind of broker is typically a cloud-native service and

distributes events based on subscription rules.

Event brokers expose one or more APIs or protocols to allow client processes to publish events
and/or subscribe to receive them, and can include features to support resilient delivery,
message batching, message or batch acknowledgment, and event replay. Some brokers use
proprietary protocols, while others use open protocols that can be supported by multiple broker
implementations. The open protocols most commonly supported include Advanced Message
Queuing Protocol (AMQP) (version 0.9.1 or version 1.0), Message Queue Telemetry Transport
(MQTT) (version 3.1.1 or version 5.0) and Apache Kafka protocol. Webhooks and websockets
can also be used to support lightweight publish-subscribe communication in web-based
architectures.

Events published to the broker may be persisted to durable storage and/or distributed across
multiple broker nodes in the cluster to provide resilience and recoverability in the event of a
failure. The event broker may use an internal storage mechanism, or delegate some or all
message persistence to an external store to balance event throughput, latency, reliability and
cost of storage.

Authentication and authorization of client connections from event sources and sinks are
typically handled by the broker under the configuration and control of the EDA Operations
component. Most brokers support topic-level authorization to control access for publication of
events or creation of subscriptions. Some brokers, including most subscription-oriented
brokers, use an outbound “push-based” communication model to deliver events based on
subscription rules. This means that the broker must be authorized to connect to the subscribed
(sink) resource.

Example Technologies

https://www.gartner.com/document/4889731 18/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

Event broker cluster/service example technologies include:

Log-oriented brokers:

Apache Kafka

Azure Event Hubs

Amazon Kinesis

Queue-oriented brokers:

IBM MQ

Azure Service Bus

Apache ActiveMQ Artemis

Google Cloud Pub/Sub

RabbitMQ

Solace PubSub+ Platform

Subscription-oriented brokers:

Azure Event Grid

Amazon EventBridge

Google Cloud Eventarc

Key Characteristics

The event broker cluster/service component has the following characteristics:

It must support the publish-subscribe communication pattern to support minimally coupled

relationships between application services (broker clients).

It must be deployed in a resilient and recoverable configuration to meet application

requirements.

Event (message) durability, ordering and quality of service (QoS) must be consistent with
your intended application requirements.

Client connectivity is dictated by the protocol and API support of the event broker
cluster/service component. Options include both proprietary and open-network protocols.

https://www.gartner.com/document/4889731 19/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

Event broker clusters/services for production workloads must support upgrade and patching
processes that maintain high availability and predictable performance.

Related Research

Choosing Event Brokers: The Foundation of Your Event-Driven Architecture

Select the Right Event Broker Technologies for Your Event-Driven Architecture Use Cases

Microservices Application Networking

Operating services in a loosely coupled fashion across a distributed environment creates the
need for a set of capabilities that provide internal communications and dependency
management between service instances.

The key components are:

Service discovery, which allows consumers to discover and connect to service endpoints at
runtime. Keeping this binding as late as possible decouples the life cycles of consumer and
provider services.

Service routing, which determines where to send network traffic based on configured rules
and the characteristics of incoming requests including the calling application and the
contents of the message. If your microservices platform extends across multiple clusters or
clouds, your service router will need to scale its capabilities accordingly.

Load balancing, which distributes inbound network traffic across a set of resources. This
capability guards against overloading instances and is essential when scaling up or down.
Load balancers can distribute requests using a variety of strategies, from “round robin,”
where requests are distributed sequentially, to complex models that take into account the
health and response time of microservice instances.

One way to implement these capabilities is to use a service mesh. This is a distributed
computing pattern, implemented as middleware, that optimizes and regulates communications
between application services. It provides proxy and lightweight mediation for service-to-service
communications, and supports functions such as authentication, authorization, encryption,
service discovery, request routing and communication traceability.

Example Technologies

Service Discovery:

Netflix Eureka

Kubernetes Service Discovery

HashiCorp Consul

https://www.gartner.com/document/4889731 20/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

Amazon VPC Lattice

Load Balancing:

F5 BIG-IP

AWS Network Load Balancer and AWS Application Load Balancer

Azure Load Balancer

Native capabilities of Kubernetes

API gateways

Service Routing:

Istio

Spring Cloud Gateway

VMware NSX Advanced Load Balancer

Zuul

Native capabilities of Kubernetes

API gateways

Service Mesh:

Anthos Service Mesh

AWS App Mesh

Istio

Linkerd

Hashicorp Consul

Kong Mesh

Red Hat OpenShift Service Mesh

Tetrate Service Bridge

Solo.io Gloo Mesh

Greymatter Application Networking Platform

https://www.gartner.com/document/4889731 21/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

Key Characteristics

Microservices application networking must:

Support dynamic routing patterns for resilience (e.g., circuit breaker and partitioning), change
management (e.g., canary and blue-green deployments, rolling deployments) and testing
(e.g., A/B testing).

Handle both “north-south” communications between the ingress gateway and service
instances and “east-west” service-to-service communications within or between internal
applications.

Provide a mechanism for service discovery that abstracts the location of other services,
enabling looser coupling.

If you are using a cloud-native application platform offering such as Azure Kubernetes
Service (AKS), Amazon Elastic Kubernetes Service (EKS), VMware Tanzu or Red Hat
OpenShift, the application networking capabilities you require may be available as
components of the platform.

Related Research

When to Use a Service Mesh in Cloud-Native Architectures

Decision Point for Mediating API and Microservices Communication

How to Architect Network Connectivity Across Multiple IaaS Cloud Providers and Regions

Microservices Execution Environment

An execution environment provides the compute capacity for running instances of microservice
code. This component provides elastic, self-service, programmable access to deploy and
manage the logical containers that host the code.

Key capabilities of a microservices execution environment include:

Microservice Instance Hosting — This is the core of the execution environment, the actual
runtime environment for microservice instances. These instances may run as applications,
containers or functions.

Microservices Orchestration — Because business outcomes are an emergent property of

executing processes that span multiple independent microservices, the execution platform
needs to provide the capability to coordinate and monitor the execution of processes that
include multiple service interactions.

Platform Automation — In addition to enabling autoscaling and self-healing capabilities for

the platform, automation tooling must support updates to platform components as well as

https://www.gartner.com/document/4889731 22/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

microservices instances. This is a required capability for the platform as a whole, not an
independent component.
Platform APIs — The capabilities of the platform should be available as APIs to support
integration with CI/CD pipelines and observability tools. This is a required capability for the
platform as a whole, not an independent component.

Example Technologies

Microservice Instance Hosting:

Containers:

Self-managed:

SUSE Rancher

Red Hat OpenShift Container Platform

VMware Tanzu Application Service

As a service:

Amazon Elastic Kubernetes Service (Amazon EKS)

Google Kubernetes Engine (GKE)

Azure Kubernetes Service (AKS)

Application PaaS:

AWS Elastic Beanstalk

Azure App Service

Google App Engine

Serverless functions:

AWS Lambda

Azure Functions

Google Cloud Functions

Microservices Orchestration:

AWS Step Functions

https://www.gartner.com/document/4889731 23/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

Azure Durable Functions

Cadence

Camunda Platform 8.0

Conductor

Orkes

Temporal

Zeebe

Key Characteristics

A microservices execution environment must:

Support the desired packaging model for your microservices, such as containers, binaries or
source bundles.

Provide the ability to elastically scale up or down in response to changing demand.

Provide the ability to control scaling behavior to limit costs.

Integrate with CI/CD pipelines for deployment.

Provide events with observability and monitoring tools.

Offer zero downtime for services during updates to platform infrastructure.

Related Research

Decision Point for Choosing a Runtime Platform for Cloud-Native Applications

Solution Path for Cloud-Native Infrastructure With Kubernetes

Designing and Operating DevOps Workflows to Deploy Containerized Applications With

Kubernetes

Choosing Microservices Orchestration Patterns and Technology

Web Threat Protection and Access Control

The web threat protection and access control capability provides authentication and
authorization, as well as security and protection, for the web-facing APIs of back-end services.
This includes managing access and authenticating users, which may include:

Applications and services calling the APIs on their own behalf.

https://www.gartner.com/document/4889731 24/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

End users, such as employees, partners, customers or developers, using applications and
services that call the APIs.

In addition to providing identity-related access control, this capability supports security-based

controls to help protect the back-end service environment from malicious attacks or accidental
misuse.

There are two core capabilities:

Access management: Access management tools provide access control — authentication

and authorization — for APIs and web-based applications. At minimum, this involves:

An identity provider (IdP) service, which supports authentication, federation and user
storage.

Token services that implement consent, enable authorization through scopes and
associated claims, and issue customizable JSON Web Tokens (JWTs) to web servers,
mobile apps, modern web apps, and services used to access APIs.

Web application and API protection (WAAP): WAAP solutions encompass a broad set of
protection capabilities and features for web-facing applications and services. These include:

Bot detection to detect unauthorized automation and attack.

Distributed denial of service (DDoS) protection to defend against brute-force saturation of

service capacity.

Web application firewall (WAF) to protect against web-technology-based attacks such as

malformed requests, script injection and cross-site request forgery (CSRF).

Example Technologies

The following are examples of types of technologies that may be used in the web API:

API access control (token services, identity federation, directories, externalized authorization
management [EAM], secrets management):

OAuth 2.0

OpenID Connect

JSON Web Token (JWT)

Open Policy Agent (OPA)

Security Assertion Markup Language (SAML)

Ping Identity
https://www.gartner.com/document/4889731 25/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

ForgeRock

IBM Security Verify

Okta

Microsoft Entra Verified ID

WAAP (API protection, bot mitigation, WAF, IAM integration and so on)

Imperva

Cloudflare

Akamai Technologies

Fastly

Amazon Web Services (AWS) Shield Advanced

Fortinet FortiWeb

F5

Microsoft Azure Front Door and Azure Web Application Firewall

Key Characteristics

The web access control component has the following characteristics:

It must provide the ability to secure authentication identities and issue secure tokens that can
be verified by other system components.

It should support management of claims-based authorization, such that claims and scopes
can be included in secure tokens for verification by other system components.

It should provide runtime protection from common attack patterns, including those described
by the Open Web Application Security Project (OWASP) Top Ten (for web applications) and
the OWASP API Security Top Ten.

It may provide API discovery capabilities to help security professionals and product teams
validate that only intentional APIs are accessible.

It may integrate with API gateways and other components to streamline authentication and
authorization processing, and to collect data to support other protection capabilities.

Related Architecture Research

Architect a Modern API Access Control Strategy

https://www.gartner.com/document/4889731 26/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

Protecting Web Applications and APIs From Exploits and Abuse

Guide to Application Security Concepts

Critical Capabilities for Cloud Web Application and API Protection

Magic Quadrant for Cloud Web Application and API Protection

Specific MSA Delivery Platform Considerations

Access control for microservices is focused on the boundary of the microservices delivery
platform.

Key Architecture Principles and Patterns

The delivery platform must support development teams as they apply the foundational
principles of MSA to service design and development: independence, loose coupling, high
cohesion, limited scope, communication only through APIs and data ownership. In addition, the
platform should use the following principles and patterns.

Principle: Automate Everything

Automation in software development is beneficial in many ways. It increases productivity,

enhances efficiency and reduces the risk of human error. It also provides traceability and
auditability. For MSA, automation is essential to maximize delivery throughput. There are three
types of automation that an MSA delivery platform must provide:

Build automation — A consistent and repeatable build process with embedded automated
testing.

Deployment automation — Agile releases of application code, including complex, staged

rollouts, such as blue/green and/or canary deployments.

Platform automation — Automating processes such as updating the platform and its
components, scaling services up and down, and adding or removing users.

For more information on automation, see Automate the Application Delivery Value Stream.

Pattern: API Mediation

MSA relies on separating the interface of a service from its implementation to achieve loose
coupling. API mediation separates API endpoints exposed by services from the applications
that call those endpoints using an API gateway. It also provides the ability to orchestrate,
compose, transform or filter API requests and responses.

Pattern: Externalized Configuration

https://www.gartner.com/document/4889731 27/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

Application configuration should be managed separately from microservice code to increase

agility. Doing so enables changes to configuration without changing application code. It also
lets you promote the artifact from environment to environment, rather than rebuilding it each
time. This practice not only reduces the time required to deliver features, it also increases
confidence in your tests because the binary that you are deploying to production is the same
one that has passed testing in preproduction environments.

Pattern: Horizontal Scaling

The primary method of scaling in MSA is horizontal rather than vertical. When load increases,
adding more instances of a service is more straightforward than redeploying service instances
with more capacity. Using this pattern successfully requires that microservices are designed to
operate consistently regardless of the number of instances. This is much easier to do with
stateless microservices because any instance can handle a given request, so as instances are
added or removed, there is no loss of session data or discontinuity in user experience.

Pattern: Managed Service Communications

Keeping services independent of one another via loose coupling enables independent
deployment and technology choices. Services use logical addresses when they need to
communicate with each other. Managed service communications externalizes the routing and
policy management of this service-to-service communication, especially when services use
request/response communications. It can be implemented using service meshes, container
networking, gateways and proxies to varying degrees of sophistication.

Key Architecture Recommendations

Ensure that you have leadership support and that those leaders understand the scope of
work required before building a microservices delivery platform. Adopting microservices
architecture is a significant investment. The capabilities required for success, along with the
organizational and process changes that extend outside of your IT and software engineering
teams, require sustained funding and leadership commitment.

Determine whether your platform will be aligned to a single set of microservices making up
one application or a general-purpose application platform for multiple sets of microservices.
In general, platforms are shared to give economies of scale and drive consistency. However,
sufficiently large applications with significant needs for operational isolation or specific
features may warrant a dedicated instance of the platform.

Start your implementation of the platform by deciding on the execution environment that you
will target. This choice constrains many other decisions you will make, from the development
tooling you will require to your options for service telemetry. Kubernetes and containers are a
popular option but far from the only option.

Choose the technologies that you will use to implement the platform based on your
organization’s strategies, appetite for risk and current skill sets. Options include both

https://www.gartner.com/document/4889731 28/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

provider-managed and self-managed offerings. See Decision Point for Choosing a Runtime
Platform for Cloud-Native Applications for detailed guidance.
Use your existing technologies to implement the platform when doing so is feasible. The
fewer changes that product teams need to make to use the platform, the more likely they are
to do so.

Related Architecture Research

Comparing DevOps Architecture to Automate Infrastructure and Operations for Software
Development

Essential Patterns for Event-Driven and Streaming Architectures

Choosing Event Brokers: The Foundation of Your Event-Driven Architecture

Leading Teams to Success With Microservices Architecture

Recommended by Author

How to Succeed With Solution Path for Increasing

Microservices Architecture Application Agility Using
for Cloud-Native Microservices Principles
Applications RESEARCH · 14 September 2023

RESEARCH · 24 February 2023

Working With Data in

Distributed and
Microservices Architectures
RESEARCH · 3 April 2023

https://www.gartner.com/document/4889731 29/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

View More

Your Peers Also Viewed

Choosing Event Brokers: Reference Architecture

The Foundation of Your Brief: Agile Web Application
Event-Driven Architecture Architecture
RESEARCH · 6 June 2022 RESEARCH · 23 October 2023

A Technical Guide to Application Architecture and

Composable Application Integration for Technical
Architecture Professionals Primer for
RESEARCH · 1 December 2021 2023
RESEARCH · 7 February 2023

Decision Point for Choosing

a Mobile App Architecture
RESEARCH · 22 November 2022

https://www.gartner.com/document/4889731 30/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

Recommended Multimedia

VIDEO

Dev vs. Ops (How Trust Was Destroyed)

02:56

VIDEO

Case Study: Automating the Application Delivery Value Stream

07:30

VIDEO

Client Question Video: How Do I Implement Chatbots?

03:57

VIDEO

Video: Supporting a Multi-Chatbot Strategy

09:00

Supporting Initiatives
Application Architecture and Integration for Technical Professionals

Following

© 2023 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc.
and its affiliates. This publication may not be reproduced or distributed in any form without Gartner's prior
written permission. It consists of the opinions of Gartner's research organization, which should not be construed
as statements of fact. While the information contained in this publication has been obtained from sources
believed to be reliable, Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such
information. Although Gartner research may address legal and financial issues, Gartner does not provide legal
or investment advice and its research should not be construed or used as such. Your access and use of this
publication are governed by Gartner’s Usage Policy. Gartner prides itself on its reputation for independence and
objectivity. Its research is produced independently by its research organization without input or influence from
any third party. For further information, see "Guiding Principles on Independence and Objectivity." Gartner
research may not be used as input into or for the training or development of generative artificial intelligence,
machine learning, algorithms, software, or related technologies.

https://www.gartner.com/document/4889731 31/32
11/17/23, 1:54 PM Reference Architecture Brief: Microservices Architecture Delivery Platform

POLICIES PRIVACY POLICY TERMS OF USE OMBUDS Get The App

CONTACT US

© 2023 Gartner, Inc. and/or its affiliates. All rights reserved.

https://www.gartner.com/document/4889731 32/32