Customers
Resources
analyst-report.svg

Analyst Reports

Navigating Key Metrics for Growth and Success

blog.svg

Blog

Source for Trends, Tips, and Timely Topics

docs.svg

Documentation

The Blueprint for Mastering Tools and Processes

sandbox.svg

Sandboxes

Explore interactive sandboxes for Avesha products

line
news.svg

News/Pubs

Bringing You the Top Stories as They Happen

videos.svg

Videos

Explore Our Library of Informative and Entertaining Clips

whitepapers.svg

Whitepapers

Exploring Critical Topics with Authoritative Research

roi.svg

ROI Calculator

Easily Track and Maximize Your Investment Returns

line
egs-marketing

Optimize Your AI with Elastic GPU Service (EGS)

Company
about-us.svg

About Us

Discover Our Mission and Core Values

careers.svg

Careers

Join Our Team and Shape the Future Together

events.svg

Events and Webinars

Connecting You to Trends, Tools, and Thought Leaders

support.svg

Support

Helping You Navigate Challenges with Ease

FAQ
Why Multi Cluster Header Image
Raj Nair

Raj Nair

Founder & CEO

24 March, 2022,

3 min read

Copied

link

Use cases:

Organizations undertaking modernization must support a hybrid deployment model where data and workloads often in different locations — near premises (data center or edge) and public cloud. There are several reasons for this, including (1) data provenance (2) data security (3) processing specialization (4) data compliance and (4) latency requirements for applications. In this context, multi-cluster zero trust networking becomes crucial to ensure that data security and compliance are maintained across different locations.

For compliance, data sometimes needs to be in a certain geography to meet regulations & security standards. Certain public clouds offer special advantages for processing specialization— like ads (Google), databases (Oracle), mail campaigns (Azure), bursting (AWS), resiliency (IBM Cloud) etc. Thus, to address these scenarios, workloads need to be able to be deployed in multiple cloud locations and not break basic assumptions around latency or security for inter-service communications. Hence, inter-service latency is an important consideration for deployments to preserve functionality of existing services and avoid costly and long application rewrite of projects. Multi-cluster zero trust networking plays a pivotal role in ensuring secure and compliant inter-service communications across distributed locations.

Challenges:

Current approaches to inter-service communication across locations are fraught with difficulties of firewall configuration and latency of API Gateways in each direction. Firewalls need to manage exceptions for all services in one large configuration that is a common entry point for all traffic for each location. Exceptions for each new service and location need to be specified separately in each of these locations resulting in a number of (mostly manual) updates that are each subject to risk of misconfiguration — “fat finger” problems.

Connectivity for each location, is the traditional North-South path that needs the communication between services to pass via API gateways for each direction, and firewalls resulting in greater latency because of the need to translate or encapsulate traditional protocols into http. A more direct & low latency connection for East-West connectivity is a better architecture but needs expensive (hard-to-find) devops and netops resources to manage IP address overlaps, create secure tunnels and configure service discovery and routing.

Solution:

Clearly, there is a need for a more automated solution that simplifies inter-service communication across locations. The answer is an “application slice” (available in Avesha’s KubeSlice product) which is a concept that offers automated, direct layer 3 pod-to-pod connectivity as an overlay of secure (zero-trust) tunnels with service discovery and routing, without the need to transverse API gateways or firewalls.  Also, each slice by default is isolated and exceptions need only to be made on a per-slice basis — this is easier to manage because a slice is defined to capture the needs of only one application or logically related group of (distributed) endpoints. The slice automation allows individual app developers to easily access these automations by a mere annotation in the application yaml — a great improvement over existing best practices by devops or netops for easy-to-configure, secure & low latency inter-service communications. This approach effectively embodies the principles of multi-cluster zero trust networking, ensuring secure and efficient communication across multiple clusters.

Useful KubeSlice links:

Explainer videos:

https://www.youtube.com/watch?v=lNtSi0_NagM

https://www.youtube.com/watch?v=n04wwW_4ziI

Try it for FREE:

https://community.aveshalabs.io/

https://avesha.io/documentation/kubeslice-overview/

Installation & How to video:

https://www.youtube.com/watch?v=cIR4nXZeZ18/

Related Articles

card image

Scaling RAG in Production with Elastic GPU Service (EGS)

card image

Optimizing GPU Allocation for Real-Time Inference with Avesha EGS

card image

#1 Myth or Mantra of spike scaling – "throw more resources at it."

card image

Do You Love Your Cloud Credits? Here's How You Can Get More…

card image

The APM Paradox: When Solution Becomes the Problem

card image

Migration should be 'gradual' and 'continuous'

card image

Hack your scaling and pay for a European Escape?

card image

Here Are 3 Ways You Can Slash Your Kubernetes Costs by 50%

card image

A completely new way for K8s Autoscaling: Why Predictive Pod Scaling with Smart Scaler and Karpenter is needed before plain VPA

Copyright © Avesha 2024. All rights reserved.

Terms and Conditions

Privacy Policy

twitter logo
linkedin logo
slack logo
youtube logo