The InfoQ eMag / Issue #86 / July 2020

Service Mesh
Ultimate Guide

Service Service Mesh Exploring the

Mesh Implementations (Possible) Future of
Features and Products Service Meshes

FACILITATING THE SPREAD OF KNOWLEDGE AND INNOVATION IN PROFESSIONAL SOFTWARE DEVELOPMENT

 InfoQ @ InfoQ InfoQ InfoQ

Service Mesh
Ultimate Guide
IN THIS ISSUE

5 ­– The Service Mesh Pattern

6 ­– Service Mesh Features
7 ­– Service Mesh Architecture: Looking Under the Hood
8 ­– Use Cases
9 ­– Antipatterns
10 ­– Service Mesh Implementations and Products
10 ­– Service Mesh Comparisons: Which Service Mesh?
11 ­– History of the Service Mesh
12 ­– Exploring the (Possible) Future of Service Meshes
13 ­– FAQ
16 ­– Additional Resources
16 ­– Glossary

PRODUCTION EDITOR Ana Ciobotaru / COPY EDITORS Lawrence Nyveen & Susan Conant / DESIGN Dragos Balasoiu
GENERAL FEEDBACK feedback@infoq.com / ADVERTISING sales@infoq.com / EDITORIAL editors@infoq.com
 The InfoQ eMag / Issue #86/ July 2020
Key Takeaways
• A service mesh manages all ser- • As a service mesh is on the critical
vice-to-service communication path for every request being handled
within a distributed (potentially within the system, it can also provide
microservice-based) software sys- additional “observability,” such as
tem. It accomplishes this typically distributed tracing of a request, fre-
via the use of “sidecar” proxies that quency of HTTP error codes, global
are deployed alongside each service and service-to-service latency.
through which all traffic is transpar-
• There are clear benefits provided by
ently routed.
the use of a service mesh, but the
• Proxies used within a service mesh tradeoffs of added complexity and
are typically “application layer” the requirement of additional runtime
aware (operating at Layer 7 in the resources should be analyzed.
OSI networking stack). This means
• Service mesh technology is rapidly
that traffic routing decisions and the
becoming part of the (cloud native)
labeling of metrics can draw upon
application platform “plumbing.” The
data in HTTP headers or other appli-
interesting innovation within this
cation layer protocol metadata.
space is happening in relation to the
• A service mesh provides dynamic higher-level abstractions and the
service discovery and traffic man- human-focused control planes.
agement, including traffic shad-
• Popular service meshes include:
owing (duplicating) for testing, and
Linkerd, Istio, Consul, Kuma, and
traffic splitting for canary releasing,
Maesh. Supporting technologies
incremental rollout, and A/B type
within this space include: Layer
experimentation. 
7-aware proxies, such as Envoy,
• A service mesh also supports the HAProxy, NGINX, and MOSN; and
implementation and enforcement of service mesh orchestration, visual-
cross cutting requirements, such as ization, and understandability tool-
security (providing service identity ing, such as SuperGloo, Kiali, and
and TLS) and reliability (rate limiting, Dive.
circuit-breaking).

3
The InfoQ eMag / Issue #86 / July 2020

Around 2016, the term “service mesh” appeared

to spring from nowhere in the arenas of micros-
ervices, cloud computing, and DevOps in. How-
ever, as with many concepts within computing,
there is actually a long history of the associated
pattern and technology.

The arrival of the service mesh has largely been

due to a perfect storm within the IT landscape.
Developers began building distributed systems
Daniel Bryant
using a multi-language (polyglot) approach,
is leading change within organisations and needed dynamic service discovery. Opera-
and technology. His current technical
expertise focuses on ‘DevOps’ tooling, tions began using ephemeral infrastructure, and
cloud/container platforms and microservice wanted to gracefully handle the inevitable com-
implementations. Daniel ia a leader
within the London Java Community munication failures and enforce network policies.
(LJC), contributes to several open source
projects, writes for well-known technical
Platform teams began embracing container or-
websites such as InfoQ, DZone and Voxxed, chestration systems like Kubernetes, and wanted
and regularly presents at international
conferences such as QCon, JavaOne and to dynamically route traffic in and around the
Devoxx. system using modern API-driven network prox-
ies, such as Envoy.

This eMag aims to answer pertinent questions

for software architects and technical leaders,
such as: what is a service mesh?, do I need a ser-
vice mesh?, and how do I evaluate the different
service mesh offerings?

4
 The InfoQ eMag / Issue #86/ July 2020
The Service
Mesh Pattern

The service mesh pattern is • Eliminating the need to com- Structure

focusing on managing all ser- pile into individual services The service mesh pattern primar-
vice-to-service communication a language-specific com- ily focuses on handling tradition-
within a distributed software munication library to handle ally what has been referred to as
system. service discovery, routings, "east-west" remote procedure
and application-level (Layer call (RPC)-based traffic: request/
Context 7) non-functional communi- response type communica-
The context for the pattern is cation requirements. tion that originates internally
twofold: First, that engineers within a datacenter and travels
• Externalizing service com-
have adopted the microservice service-to-service. This is in
munication configuration,
architecture pattern, and are contrast to an API gateway or
including network locations
building their applications by edge proxy, which is designed
of external services, security
composing multiple (ideally sin- to handle “north-south” traffic:
credentials, and quality of
gle-purpose and independently Communication that originates
service targets.
deployable) services together. externally and ingresses to an
Second, that the organization has • Providing passive and active endpoint or service within the
embraced cloud native platform monitoring of other services. datacenter.
technologies such as containers
• Decentralizing the enforce-
(e.g., Docker), orchestrators (e.g.,
ment of policy throughout a
Kubernetes), and proxies/gate-
distributed system.
ways (e.g., Envoy).
• Providing observability de-
Intent faults and standardizing the
The problems that the service collection of associated data.
mesh pattern attempts to solve - Enabling request logging
include:
- Configuring distributed
tracing
- Collecting metrics

5
The InfoQ eMag / Issue #86 / July 2020

Service Mesh Features

A service mesh implementation • Provides service release • Provides additional observ-

will typically offer one or more of control (e.g., canary releasing ability and monitoring, such
the following features: and traffic splitting) as top-line metrics (request
volume, success rates, and
• Offers per-request rout-
• Normalizes naming and adds latencies), support for dis-
ing (e.g., traffic shadowing,
logical routing, (e.g., maps the tributed tracing, and the
fault injection, and debug
code-level name “user-ser- ability to “tap” and inspect
re-routing)
vice” to the platform specific real-time service-to-service
location “AWS-us-east-1a/ • Adds baseline reliability, such communication
prod/users/v4”) as health checks, timeouts/
• Enables platform teams to
deadlines, circuit breaking,
• Provides traffic shaping and configure “sane defaults” to
and retry (budgets)
traffic shifting protect the system from bad
• Increases security, via trans- communication
• Maintains load balancing,
parent mutual Transport Lev-
typically with configurable
el Security (TLS) and policies
algorithms
such as Access Control Lists
(ACLs)

6
Service Mesh Architecture: Looking Under the Hood

The InfoQ eMag / Issue #86/ July 2020

A service mesh consists of two set of isolated stateless sidecar
high-level components: a data proxies—and turns them into a
plane and a control plane. Matt distributed system. The control
Klein, creator of the Envoy Proxy, plane doesn’t touch any packets/
has written an excellent deep- requests in the system, but in-
dive into the topic of “service stead, it allows a human operator
mesh data plane versus control to provide policy and configu-
plane.” ration for all of the running data
planes in the mesh. The control
Broadly speaking, the data plane also enables the data plane
plane “does the work” and is telemetry to be collected and
responsible for “conditional- centralized, ready for consump-
ly translating, forwarding, and tion by an operator; Red Hat has
observing every network packet been working on Kiali for just this
that flows to and from a [network use case.
endpoint].” In modern systems,
the data plane is typically im- The diagram below is taken from
plemented as a proxy, (such as the Istio architecture documen-
Envoy, HAProxy or MOSN), that tation, and although the technol-
is run out-of-process alongside ogies labeled are specific to Istio,
each service as a “sidecar.” the components are general to all
service mesh implementation.
Klein states that within a service
mesh, the data plane “touches
every packet/request in the sys-
tem, and is responsible for ser-
vice discovery, health checking,
routing, load balancing, authenti-
cation/authorization, and observ-
ability.” There is work underway
within the CNCF to create a Uni-
versal Data Plane API, based
on concepts from Klein’s earlier
blog post The Universal Data
Plane API. This proposal extends
the xDS API that has been de-
fined and implemented by Envoy
and is supported in other proxies
such as MOSN.

A control plane “supervises the Istio architecture, demonstrating the how the control
work,” and takes all the individual plane and proxy data plane interact (courtesy of
instances of the data plane — a the Istio documentation)

7
The InfoQ eMag / Issue #86 / July 2020

Use Cases

There are a variety of use cases headers or other application layer (non idempotent) HTTP POST
that a service mesh can enable or protocol metadata. requests.
support.
Service-to-Service Observability of Traffic
Dynamic Service Discovery and Communication Reliability As a service mesh is on the
Routing A service mesh supports the critical path for every request
A service mesh provides dynam- implementation and enforce- being handled within the system,
ic service discovery and traffic ment of cross cutting reliability it can also provide additional
management, including traffic requirements, such as request “observability,” such as distribut-
shadowing (duplicating) for retries, timeouts, rate limiting, ed tracing of a request, frequency
testing, and traffic splitting for and circuit-breaking. A service of HTTP error codes, global and
canary releasing and A/B type mesh is often used to compen- service-to-service latency. Al-
experimentation. sate (or encapsulate) dealing though a much overused phrase
with the eight fallacies of dis- in the enterprise space, service
Proxies used within a service tributed computing. It should be meshes are often proposed as a
mesh are typically “application noted that a service mesh can method to capture all of the data
layer” aware (operating at Layer 7 only offer wire-level reliability necessary to implement a “sin-
in the OSI networking stack). This support (such as retrying an gle pane of glass” view of traffic
means that traffic routing deci- HTTP request), and ultimately flows within the entire system.
sions and the labeling of metrics the service should be respon-
can draw upon data in HTTP sible for any related business
impact such as avoiding multiple

8
Communication Security sometimes tempted to anoint easiest approach to manage, but

The InfoQ eMag / Issue #86/ July 2020

A service mesh also supports the new technologies with this label. as research from Accelerate and
implementation and enforcement A service mesh will not solve all the State of DevOps Report, this
of cross cutting security require- communication problems with is not the case. As a complete
ments, such as providing service microservices, container orches- rollout of a service mesh means
identity (via x509 certificates), trators like Kubernetes, or cloud that this technology is on the
enabling application-level ser- networking. A service mesh aims critical path for handling all end
vice/network segmentation (e.g. to facilitate service-to-service user requests, a big bang deploy-
«service A» can communicate (east-west) communication only, ment is highly risky.
with «service B», but not service and there is a clear operational
C») ensuring all communica- cost to deploying and running a
tion is encrypted (via TLS), and service mesh.
ensuring the presence of valid
user-level identity tokens or Enterprise Service Bus (ESB) 2.0
"passports.” During the pre-microservice ser-
vice-oriented architecture (SOA)
era the Enterprise Service Buses
(ESB) implemented a communi-
cation system between software
Antipatterns
components. Some fear that
many of the mistakes from the
It is often a sign of a maturing
ESB era will be repeated with the
technology when antipatterns of
use of a service mesh.
usage emerge. Service meshes
are no exception.
The centralized control of com-
munication offered via ESBs
Too Many Traffic Management
clearly had value. However, the
Layers (Turtles All the Way Down)
development of the technologies
This antipattern occurs when de-
was driven by vendors, which led
velopers do not coordinate with
to multiple problems, such as: a
the platform or operations team,
lack of interoperability between
and duplicate existing communi-
ESBs, bespoke extension of
cation handling logic in code that
industry standards (e.g., adding
is now being implemented via a
vendor-specific configuration to
service mesh. For example, an
WS-* compliant schema), and
application implementing a retry
high cost. ESB vendors also did
policy within the code in addition
nothing to discourage the in-
to a wire-level retries policy pro-
tegration and tight-coupling of
vided by the service mesh con-
business logic into the communi-
figuration. This antipattern can
cation bus.
lead to issues such as duplicated
transactions.
Big Bang Deployment
There is a temptation within IT at
Service Mesh Silver Bullet
large to believe that a big bang
There is no such thing as a “silver
approach to deployment is the
bullet” within IT, but vendors are

9
 Service Mesh Service Mesh Comparisons:
The InfoQ eMag / Issue #86 / July 2020

Implementations Which Service Mesh?

and Products
The service mesh space is extremely fast moving, and so any attempt
The following is a non-exhaus- to create a comparison is likely to quickly become out of date. How-
tive list of current service mesh ever, several comparisons do exist. Care should be taken to under-
implementations: stand the source’s bias (if any) and the date that the comparison was
made.
• Linkerd
• https://layer5.io/landscape
• Istio
• https://kubedex.com/istio-vs-linkerd-vs-linkerd2-vs-con-
• Consul sul/ (correct as of May 2019)
• Kuma • https://platform9.com/blog/kubernetes-service-mesh-a-com-
• Maesh parison-of-istio-linkerd-and-consul/ (up to date as of October
2019)
• AWS App Mesh
• https://servicemesh.es/ (last published February 2020)

InfoQ always recommends that service mesh adopters perform their

own due diligence and experimentation on each offering.

Service Mesh Tutorials

For engineers or architects looking to experiment with multiple

service meshes the following tutorials, playgrounds, and tools are
available:

• Layer 5 Meshery — a multi service mesh management plane.

• Solo’s SuperGloo — a service mesh orchestration platform

• KataCoda Istio tutorial

• Consul service mesh tutorial

• Linkerd tutorial

10
 The InfoQ eMag / Issue #86/ July 2020
History of the Service Mesh

InfoQ has been tracking the In late 2014, Netflix released Even service meshes that
topic that we now call service an entire suite of JVM-based util- emerged outside of the unicorns,
mesh since late 2013, when ities including Prana, a “sidecar” such as HashiCorp’s Consul,
Airbnb released SmartStack, process that allowed application took inspiration from the afore-
which offered an out-of-process services written in any language mentioned technology, often
service discovery mechanism to communicate via HTTP to aiming to implement the CoreOS
(using HAProxy) for the emerg- standalone instances of the li- coined concept of "GIFEE”; Goo-
ing “microservices” style archi- braries. In 2016, the NGINX team gle infrastructure for everyone
tecture. Many of the previously began talking about “The Fabric else.
labeled “unicorn” organizations Model,” which was very similar to
were working on similar technol- a service mesh, but required the For a deep-dive into the history
ogies before this date. From the use of their commercial NGINX of how the modern service mesh
early 2000s Google was devel- Plus product for implementation. concept evolved, Phil Calça-
oping its Stubby RPC framework do has written a comprehensive
that evolved into gRPC, and Other highlights from the his- article "Pattern: Service Mesh.”
the Google Frontend (GFE) and tory of the service mesh in-
Global Software Load Balanc- clude the releases of Istio in
er (GSLB), traits of which can May 2017, Linkerd 2.0 in July
be seen in Istio. In the earlier 2018, Consul Connect and Super-
2010s, Twitter began work on Gloo in November 2018, service
the Scala-powered Finagle from mesh interface (SMI) in May
which the Linkerd service mesh 2019, and Maesh and Kuma in
emerged. September 2019.

11
 Exploring the (Possible) Future of Service Meshes
The InfoQ eMag / Issue #86 / July 2020

As service mesh technology interoperability across different The Buoyant team is leading the
is still within the early adop- service mesh technologies in- charge with developing effective
tion phase, there is a lot of scope cluding Istio, Linkerd, and Consul human-centric control planes for
for future work. Broadly speaking, Connect. service mesh technology. They
there are four areas of particular have recently released Dive, a
interest: adding support for use The topic of integrating service SaaS-based “team control plane”
cases beyond RPC, standard- meshes with the platform fabric for platform teams operating Ku-
izing the interface and opera- can be further divided into two bernetes. Dive adds higher-level,
tions, pushing the service mesh sub-topics. human-focused, functionality on
further into the platform fabric, top of the Linkerd service mesh,
and building effective human First, there is work being con- and provides a service catalog,
control planes for service mesh ducted to reduce the networking an audit log of application releas-
technology. overhead introduced by a service es, a global service topology, and
mesh data plane. This includes more.
Kasun Indrasiri has explored the data plane development kit
"The Potential for Using a Service (DPDK), which is a userspace
Mesh for Event-Driven Messag- application that "bypasses the
ing,” in which he discussed two heavy layers of the Linux ker-
main emerging architectural nel networking stack and talks
patterns for implementing mes- directly to the network hard-
saging support within a service ware," and work by the Cilium
mesh: the protocol proxy sidecar, team that utilizes the extend-
and the HTTP bridge sidecar. ed Berkley Packet Filter (eBPF)
This is an active area of devel- functionality in the Linux kernel
opment within the service mesh for "very efficient networking,
community, with the work to- policy enforcement, and load
wards supporting Apache Kafka balancing functionality." Another
within Envoy attracting a fair team is mapping the concept of a
amount of attention. service mesh to L2/L3 payloads
with Network Service Mesh, as an
Christian Posta has previously attempt to “re-imagine network
written about attempts to stan- function virtualization (NFV) in a
dardize the usage of service cloud-native way.”
meshes in “Towards a Unified,
Standard API for Consolidating Second, there are multiple initia-
Service Meshes.” This arti- tives to integrate service meshes
cle also discusses the Service more tightly with public cloud
Mesh Interface (SMI) that was platforms, as seen in the intro-
recently announced by Micro- duction of AWS App Mesh, GCP
soft and partners at KubeCon Traffic Director, and Azure Ser-
EU. The SMI defines a set of vice Fabric Mesh.
common and portable APIs that
aims to provide developers with

12
The InfoQ eMag / Issue #86/ July 2020

13
FAQ
 What is a service mesh? If I am deploying microservices, Shouldn’t a service mesh be
The InfoQ eMag / Issue #86 / July 2020

A service mesh is a technology do I need a service mesh? part of Kubernetes or the “cloud
that manages all service-to-ser- Not necessarily. A service mesh native platform” that applications
vice, “east-west,” traffic within a adds operational complexity to are being deployed onto?
distributed (potentially microser- the technology stack, and there- Potentially. There is an argu-
vice-based) software system. It fore is typically only deployed if ment for maintaining separation
provides both business-focused the organization is having trouble of concerns within cloud na-
functional operations, such as scaling service-to-service com- tive platform components (e.g.,
routing, and nonfunctional sup- munication, or has a specific use Kubernetes is responsible for
port, for example, enforcing se- case to resolve. providing container orchestration
curity policies, quality of service, and a service mesh is responsi-
and rate limiting. It is typically Do I need a service mesh to ble for service-to-service com-
(although not exclusively) im- implement service discovery with munication). However, work is
plemented using sidecar proxies microservices? underway to push service mesh-
through which all services com- No. A service mesh provides one like functionality into modern
municate through. way of implementing service dis- Platform-as-a-Service (PaaS)
covery. Other solutions include offerings.
How does a service mesh differ language-specific libraries (such
from an API gateway? as Ribbon and Eureka, or Finagle) How do I implement, deploy, or
A service mesh manages all rollout a service mesh?
service-to-service, “east-west,” Does a service mesh add The best approach would be to
traffic within a distributed (po- overhead/latency to my service- analyse the various service mesh
tentially microservice-based) to-service communication? products (see above), and follow
software system. It provides Yes, a service mesh adds at least the implementation guidelines
both business-focused function- two extra network hops when a specific to the chosen mesh. In
al operations, such as routing, service is communicating with general, it is best to work with all
and nonfunctional support, for another service (the first is from stakeholders and incrementally
example, enforcing security pol- the proxy handling the source’s deploy any new technology into
icies, quality of service, and rate outbound connection, and the production.
limiting. second is from the proxy han-
dling the destination’s inbound Can I build my own service
An API gateway manages all connection). However, this addi- mesh?
ingress, “north-south,” traffic into tional network hop typically oc- Yes, but the more pertinent ques-
a cluster, and provides addition- curs over the localhost or loop- tion is should you? Is building a
al support for cross-functional back network interface, and adds service mesh a core competen-
communication requirements. It only a small amount of latency cy of your organization? Could
acts as the single entry point into (on the order of milliseconds). you be providing value to your
a system and enables multiple Experimenting with and under- customers in a more effective
APIs or services to act cohesively standing whether this is an issue way? Are you also committed
and provide a uniform experience for the target use case should be to maintaining your own mesh,
to the user. part of the analysis and evalua- patching it for security issues,
tion of a service mesh. and constantly updating it to take
advantage of new technologies?
With the range of open source

14
and commercial service mesh Can the words “Istio” and

The InfoQ eMag / Issue #86/ July 2020

offerings that are now available, “service mesh” be used
it is most likely more effective to interchangeably?
use an existing solution. No. Istio is a type of service
mesh. Due to the popularity of
Which team owns the service Istio when the service mesh
mesh within a software delivery category was emerging, some
organization? sources were conflating Istio and
Typically the platform or op- service mesh. This issue of con-
erations team own the service flation is not unique to service
mesh, along with Kubernetes and mesh—the same challenge oc-
the continuous delivery pipeline curred with Docker and container
infrastructure. However, devel- technology.
opers will be configuring the
service mesh properties, and so Which service mesh should I
both teams should work closely use?
together. Many organizations are There is no single answer to this
following the lead from the cloud question. Engineers must under-
vanguard such as Netflix, Spoti- stand their current requirements,
fy, and Google, and are creating and the skills, resources, and
internal platform teams that pro- time available for their imple-
vide tooling and services to full mentation team. The service
cycle product-focused develop- mesh comparison links above
ment teams. will provide a good starting point
for exploration, but we strongly
Is Envoy a service mesh? recommend that organizations
No. Envoy is a cloud native proxy experiment with at least two
that was originally designed and meshes in order to understand
built by the Lyft team. Envoy is which products, technologies,
often used as the data plane with and workflows work best for
a service mesh. However, in order them.
to be considered a service mesh,
Envoy must be used in conjunc- Can I use a service mesh outside
tion with a control plane in order of Kubernetes?
for this collection of technologies Yes. Many service meshes allow
to become a service mesh. The the installation and management
control plane can be as simple as of data plane proxies and the as-
a centralized config file repos- sociated control plane on a vari-
itory and metric collector, or a ety of infrastructure. HashiCorp’s
comprehensive/complex as Istio. Consul is the most well known
example of this, and Istio is also
being used experimentally with
Cloud Foundry.

15
 Additional Resources
The InfoQ eMag / Issue #86 / July 2020

• InfoQ Service Mesh homepage

• The InfoQ eMag - Service Mesh: Past, Present, and Future

• The Service Mesh: What Every Software Engineer Needs to Know about the World’s Most Over-Hyped
Technology

• Service Mesh Comparison

• Service Meshes

Glossary
API gateway: Manages all ingress (north-south) traffic into a cluster, and provides additional. It acts as
the single entry point into a system and enables multiple APIs or services to act cohesively and provide a
uniform experience to the user.

Consul: A Go-based service mesh from HashiCorp.

Control plane: Takes all the individual instances of the data plane (proxies) and turns them into a distrib-
uted system that can be visualized and controlled by an operator.

Data plane: A proxy that conditionally translates, forwards, and observes every network packet that flows
to and from a service network endpoint.

East-West traffic: Network traffic within a data center, network, or Kubernetes cluster. Traditional network
diagrams were drawn with the service-to-service (inter-data center) traffic flowing from left to right (east
to west) in the diagrams.

Envoy Proxy: An open-source edge and service proxy, designed for cloud-native applications. Envoy is
often used as the data plane within a service mesh implementation.

Ingress traffic: Network traffic that originates from outside the data center, network, or Kubernetes cluster.

Istio: C++ (data plane) and Go (control plane)-based service mesh that was originally created by Google
and IBM in partnership with the Envoy team from Lyft.

Kubernetes: A CNCF-hosted container orchestration and scheduling framework that originated from
Google.

Kuma: A Go-based service mesh from Kong.

16
Linkerd: A Rust (data plane) and Go (control plane) powered service mesh that was derived from an early

The InfoQ eMag / Issue #86/ July 2020

JVM-based communication framework at Twitter.

Maesh: A Go-based service mesh from Containous, the maintainers of the Traefik API gateway.

MOSN: A Go-based proxy from the Ant Financial team that implements the (Envoy) xDS APIs.

North-South traffic: Network traffic entering (or ingressing) into a data center, network, or Kubernetes
cluster. Traditional network diagrams were drawn with the ingress traffic entering the data center at the
top of the page and flowing down (north to south) into the network.

Proxy: A software system that acts as an intermediary between endpoint components.

Segmentation: Dividing a network or cluster into multiple sub-networks.

Service mesh: Manages all service-to-service (east-west) traffic within a distributed (potentially micros-
ervice-based) software system. It provides both functional operations, such as routing, and nonfunctional
support, for example, enforcing security policies, quality of service, and rate limiting.

Service Mesh Interface (SMI): A work-in-progress standard interface for service meshes deployed onto
Kubernetes.

Service mesh policy: A specification of how a collection of services/endpoints are allowed to communi-
cate with each other and other network endpoints.

Sidecar: A deployment pattern, in which an additional process, service, or container is deployed alongside
an existing service (think motorcycle sidecar).

Single pane of glass: A UI or management console that presents data from multiple sources in a unified
display.

Traffic shaping: Modifying the flow of traffic across a network, for example, rate limiting or load shedding.

Traffic shifting: Migrating traffic from one location to another.

17
InfoQ @ InfoQ InfoQ InfoQ

Curious about
previous issues?
The InfoQ eMag / Issue #81 / January 2020 The InfoQ eMag / Issue #79 / November 2019 The InfoQ eMag / Issue #77 / October 2019

Microservices: Taming Complex

.NET
Testing, Observing, Systems in Production
and Understanding

Core 3

@emilywithcurls
Tyler Treat on Navigating Interview with Using the .Net Core Template An Engineer’s Sustainable Operations Testing in
12 Microservices Obscuring
Microservice the .NET Scott Hunter on Engine to Create Custom Guide to a Good in Complex Systems with Production—Quality
Testing Techniques Complexity
Observability Ecosystem .NET Core 3.0 Templates and Projects Night’s Sleep Production Excellence Software, Faster

FACILITATING THE SPREAD OF KNOWLEDGE AND INNOVATION IN PROFESSIONAL SOFTWARE DEVELOPMENT FACILITATING THE SPREAD OF KNOWLEDGE AND INNOVATION IN PROFESSIONAL SOFTWARE DEVELOPMENT FACILITATING THE SPREAD OF KNOWLEDGE AND INNOVATION IN PROFESSIONAL SOFTWARE DEVELOPMENT

This eMag takes a deep In this eMag we explore To tame complexity and its
dive into the techniques and some more of the benefits effects, organizations need
culture changes required of .NET Core and how it can a structured, multi-pronged,
to successfully test, benefit not only traditional human-focused approach,
observe, and understand .NET developers, but all that: makes operations
microservices. technologists who need to work sustainable, centers
bring robust, performant decisions around customer
and economical solutions to experience, uses continuous
market. testing, and includes chaos
engineering and system
observability. In this eMag,
we cover all of these topics.