Source: thenewstack.io
ZeroLB, a New Decentralized Pattern for Load BalancingCategory: Security, Kubernetes, Docker
The old monolithic and centralized load balancer, a technology largely stuck in the early 2000s, becomes deprecated in this new distributed world. The most common breed of load balancers being deployed across every application — centralized load balancers — are a legacy technology.
Remnants of a monolithic legacy way of doing things that did not adapt to modern best practices, centralized load balancers prevent users and organizations from effectively transitioning to the cloud native and container-based era.
Finally, centralized load balancers have limited features, including lack of set-up support for modern zero-trust security, tracing and metrics, and self-healing capabilities across applications.
In a typical decentralized application, centralized load balancers become a single point of failure for our services: By introducing a centralized load balancer, we also increase network performance by adding one extra hop in the network that we don’t typically need: In addition, when we decouple centralized load balancers for high availability, we typically need one load balancer per service which increases complexity in our architectures, further reducing the performance, and increasing our operational costs: When deploying on a public cloud, we may be tempted to utilize their native elastic load balancers, which will in turn increase costs quickly, since they are very expensive, Also, they are not portable across clouds and therefore cause a fragmented experience for developers or operators who are replicating these deployments across environments: All of these limitations while not extending the baseline connectivity functionality that modern service builders require such as self-healing routing, canary releases, observability, zero-trust security and more.
Remnants of a monolithic legacy way of doing things that did not adapt to modern best practices, centralized load balancers prevent users and organizations from effectively transitioning to the cloud native and container-based era.
Finally, centralized load balancers have limited features, including lack of set-up support for modern zero-trust security, tracing and metrics, and self-healing capabilities across applications.
In a typical decentralized application, centralized load balancers become a single point of failure for our services: By introducing a centralized load balancer, we also increase network performance by adding one extra hop in the network that we don’t typically need: In addition, when we decouple centralized load balancers for high availability, we typically need one load balancer per service which increases complexity in our architectures, further reducing the performance, and increasing our operational costs: When deploying on a public cloud, we may be tempted to utilize their native elastic load balancers, which will in turn increase costs quickly, since they are very expensive, Also, they are not portable across clouds and therefore cause a fragmented experience for developers or operators who are replicating these deployments across environments: All of these limitations while not extending the baseline connectivity functionality that modern service builders require such as self-healing routing, canary releases, observability, zero-trust security and more.
Related Articles
Community Partners
DevOps Careers