Cloud and infrastructure

Updated 5 min read

Service Mesh: When Network Rules Should Move Out of Every Service

Shared encryption and traffic policies need clear boundaries. What belongs in the mesh, what stays in applications, and how to judge the operating cost.

The company agrees to encrypt internal connections and put limits on calls to external services. Then ordinary delivery work begins: one team upgrades a library, another waits for its next release, and a third maintains a different language stack. A month later, the policy supposedly applies, but nobody can explain its actual coverage or exceptions.

A service mesh can move some of these responsibilities out of application code and into a managed communication layer. There is a concrete problem to solve: implementing and checking the same requirements repeatedly. Central management also makes it easier to distribute a mistake.

Shared rules do not require one server for every request

A mesh usually separates the components handling traffic from the components configuring them. The data plane consists of intermediaries that route connections, enforce policies and collect technical signals. The control plane distributes configuration and performs related management tasks.

That does not necessarily mean all traffic crosses one central appliance. Proxies may run alongside applications or at node level. Istio, for example, documents several data-plane arrangements. Available capabilities depend on the implementation and mode, not merely on calling the design a mesh.

The distinction matters during an outage. Losing management and losing the traffic path can have different consequences. Existing communication may continue while new configuration or new workloads cannot be prepared. Establish that behaviour for the actual platform, including certificate renewal, rather than treating the mesh as either completely healthy or completely unavailable.

A service certificate does not authorise an employee to read a contract

Mutual TLS, or mTLS, lets communicating parties authenticate their technical identities and protects data in transit. A policy may allow the requests service to call the documents service. That does not establish whether a particular employee may read a particular contract.

Document ownership, employee roles and permitted business changes still need application-level authorisation. The mesh can help validate credentials and enforce broader access policies, but it cannot infer rules that nobody has defined. Istio's security documentation separates transport authentication from access policies.

Coverage matters during adoption. Are any calls bypassing the protected path? What happens to applications not yet migrated? A transitional mode that accepts older connections may be necessary. Its existence is not evidence that mandatory encryption is already enforced everywhere.

A convenient retry policy can repeat the wrong action

A platform team may prefer one standard: wait briefly, then retry after failure. For fetching a reference list, that may help. For confirming equipment handover, a missing response means something else: the action might have completed even though its caller does not know.

A proxy cannot make that operation safe to repeat. The application owner must define idempotency, the overall time budget and which failures justify a retry. Application retries and mesh retries must not silently multiply. Changing communication policy without redeploying code does not remove the need to understand the operation.

Timeouts have a similar boundary. Stopping the wait for a response does not prove downstream work has stopped. The available controls are described in Istio traffic management; appropriate settings come from the workflow rather than one number imposed on every method.

A connection map does not explain the whole delay

A mesh can expose failures between services and the response times seen by its proxies. That is useful evidence when narrowing down an unhealthy dependency. But a slow response can include application processing, database waits and other internal work. A signal emitted by a network proxy does not prove the network is at fault.

Applications may still need to propagate tracing context to connect an incoming request with its outgoing calls. An automatically generated dependency map will not necessarily reconstruct the whole business process, particularly across queues. Network signals work better when connected to the state of the operation than when presented as another separate dashboard.

Agree on diagnostic ownership explicitly. The platform team should be able to explain delivery and applied policies; the product team should explain execution. During an incident, following that path must not require an argument about who now owns networking.

Treat policy changes as releases

A mistaken shared access rule can disconnect many applications. An overly permissive rule may remain unnoticed precisely because everything continues working. Policies need review, limited initial exposure and a way to identify the configuration actually active at each intermediary.

An accepted management command is not the same as a completed fleet-wide change. Configuration propagates while components restart or temporarily disappear. For an important policy, verify an allowed call, a prohibited call and the transition itself. Reverting the configuration must preserve the access restrictions the business still needs.

The mesh also brings maintenance costs: proxy resources, upgrades, certificate handling, diagnosis and protocol compatibility. Splitting control planes can contain some configuration failures, at the cost of more operations. The deployment-model guidance describes these choices.

Count the repeated work first

A credible adoption case identifies requirements that are genuinely expensive to implement consistently. Who renews certificates? How are access rules verified? How many teams must modify a networking library? An existing platform may already handle enough of that work without another layer.

A pilot should include one meaningful service relationship, a certificate change, a bad policy, a new workload and loss of management availability. Compare the engineering effort and customer consequences with the current arrangement. That gives the company evidence about whether it is buying consistent controls or creating another queue for a scarce specialist.