Financial institutes, that are looking to capitalize on ecosystem-based opportunities, require robust systems and services addressing security, resiliency, scalability, and agility requirements. Modern cloud native architecture tries to address these concerns by leveraging API management, microservices, automation and cloud capabilities.

Financial institutes are increasingly implementing domain aligned microservices to improve scalability, business, and operational agility requirements. Microservices have become a key building block in financial institute ecosystem integration fabric.

However, inter service communication between microservices has many cross-cutting concerns such as service discovery, security, policy management and observability which need to be addressed. There are multiple approaches which have been evolving to address microservices architecture cross cutting concerns, starting from common libraries to various flavors of service mesh.

As the number of microservices in a financial institute increases, it is imperative to identify an optimal path for handling cross cutting concerns. Few evolving options are highlighted along with appropriate considerations.

Common Libraries:

To avoid duplication of code, initial financial institute implementations of microservices leveraged common libraries which encapsulated cross cutting features. However, these common libraries have dependencies on programming language.

Service Mesh with Sidecars:

A service mesh provides application networking functionality which includes service discovery, observability, traffic routing and security. Service mesh via sidecars approach provides this functionality via concept of control plane and a programmable data plane. Control plane helps in central management and policy configuration of the mesh. The runtime service to service communication would be routed through data plane sidecar proxies.

Few of the popular service mesh products include Istio, Linkerd, Consul and Kuma. Istio uses envoy based data plane and Linkerd uses its own custom micro proxy with targeted service mesh features as data plane.

However, there are few challenges with sidecar based service mesh approach.

While service mesh with sidecar approach provides clean separation of business logic and networking functionality as well as granular security, they do impose necessity of injecting a sidecar proxy into each Kubernetes application pod. Sidecar proxy need to be available first for network communication to happen. HTTP traffic processing by sidecars is computationally expensive. Thus, sidecar based approach tend to result in higher resource consumption, operational overhead and cost.

 Sidecarless Service Mesh:

While data plane involving sidecars is providing value, to mitigate its limitations, multiple industry entities are trying out various innovative options such as sidecarless data plane.

One such sidecarless service mesh option is Cilium service mesh which makes use of eBPF (Extended Berkeley Pocket Filter) and envoy proxy. Cilium is also a CNI (Container Networking Interface) which helps with networking, security and observability requirements of containers in a Kubernetes cluster by using eBPF functionality at kernel level.

eBPF facilitates custom programs to run inside kernel based on events. As eBPF deals with network pockets, it can help with observability, security, and networking metrics. The path of network pockets passing would be shorter with eBPF and result in lower latency as the path would not involve going through iptable rules. eBPF can also help in network layer encryption at node level.  eBPF verifier ensures that eBPF program is safe to run in a kernel.

More service mesh features are being added to Cilium and it uses eBPF for L4 connectivity concerns of service mesh and envoy proxy for layer 7 traffic management capabilities such as canary rollouts and retries. It works with many popular control planes in industry such as Istio.

In case of Istio, Istio ambient mesh is evolving as a data plane that is aligned to sidecarless approach. Istio ambient mesh addresses service to service communication by breaking it into secure layer 4 features and layer 7 policy and behavior.

Istio ambient mesh handles layer 4 connectivity concerns between two services via a shared agent called ztunnel, a secure overlay layer which runs as a pod in each node of the kubernetes cluster. Ztunnel takes care of layer 4 service authorization, security via mTLS, observability via TCP logs and traffic management of TCP.  

Istio ambient mesh layer 7 features are handled by waypoint proxy. Waypoint proxy, based on envoy, secures via rich layer7 authorization policies, assists in observability via http metrics and tracing as well as traffic management policies such as canary test and chaos test. Layer 7 processing happens in waypoint proxy, in separately scheduled pods as a shared namespace resource and they can be auto scaled.

Istio control plane caters to both sidecar and sidecarless ambient mesh data plane, thus providing optionality. While ambient mesh will be useful for many service mesh use cases, there are scenarios where sidecars will still be useful such as compliance and performance tuning.

 Impact on operations:

Financial institutes need to consider the number of microservices, skills of the team and various quality of service requirements to identify appropriate trade-offs for service mesh options. 

While handling cross-cutting concerns of microservices via common libraries approach provides ease of use, it has dependency on the programming languages and takes operational effort to keep pace with upgrades. Sidecar based approach helps in polyglot microservices scenario and fosters consistent configuration across large estate of microservices. It does involve higher resource consumption and operational overhead due to sidecars. Sidecarless option provides the benefit of L4 level processing at node level and L7 processing at namespace level for the traffic routing features. Sidecarless option has the potential for simplifying operational effort with scale, coupled with relatively less resource consumption.

With the increasing number of polyglot cloud native microservices in financial institute, operational scalability will progressively increase from common libraries approach to service mesh with sidecars approach and to service mesh with sidecarless approach.

Conclusion:

While service mesh implementations with common libraries and sidecar based approach are being adopted by major cloud native initiatives of financial institutes, sidecarless options are evolving fast to mitigate their shortcomings.

Thus, innovative financial institutes, while evolving their service integration approach, need to experiment with new eBPF based service mesh options to realize the optimal benefits of better operational efficiency, security and TCO (total cost of ownership). Implemented right, sidecarless service mesh with eBPF technology will help in positioning financial institute’s service infrastructure in a sustainable path.