Introducing Cycle's Native Load Balancer

Over the last few months, you may have noticed that many of our changelog releases mentioned the release of, and improvements to, Cycle’s native load balancer. While this load balancer still officially remains in beta status, we wanted to begin diving into the details around it a bit more thoroughly: What is it? Why did we build it? How can you use it?

If you’re unfamiliar with the concept behind load balancers, check out CloudFlare’s “What is Load Balancing?” blog to learn more.

From the start, the Cycle platform has been utilizing HAProxy, a time-tested open source load balancer, to route ingress traffic for Cycle environments. While HAProxy has worked well performance-wise, it was the only component of Cycle that wasn’t built in-house. This ‘loose’ integration with the platform, became more significant to us as our company, and client base, grew. With these concerns, it only became a matter of time before we knew we’d have to swap out HAProxy with our own native load balancer.

In July we began development of Cycle’s load balancer, and there were a number of requirements for what we set out to build:

• Equal or greater performance to HAProxy.
• Better metrics and increased observability that were accessible via the API and portal.
• Improved customization and configuration around traffic routing that aligned with patterns already built into the platform.

Alongside all of these requirements, we also wanted to maintain extensibility. Features like web application firewalling were top of mind, but, in the same vein, just the ability to add features to the load balancer that made sense for our platform without redesign or breaking versions.

One of the major benefits of Cycle being a vertically integrated platform is that every component of the platform has been purpose-built to address specific patterns. This differs from traditional open source tools that are designed to be highly customizable. Unfortunately, this flexibility can lead to their downfall as they become overly complex and, in many cases, less stable. Additionally, Cycle has a number of internal APIs, event buses, and other enhancements, which exponentially increases the value of in-house components.

Bringing everything together, the new load balancer delivers a number of significant improvements to our users. Previously, HAProxy would reconfigure a ‘soft reconfigure’ for every container / instance that was initialized. This reconfigure event introduced a performance hit, along with a short-lived ‘pause’ in traffic. For our users that are deploying tens of thousands of containers per day, this became a problem. Cycle’s native load balancer was built to allow reconfiguration events without any packet loss or performance degradation. Additionally, the load balancer collects metrics in a way that aligns with the rest of the platform. Users can now see a breakdown of requests, network latency between LBs and the underlying destination instances, and much more. From caching (similar to CloudFront by AWS) and proxying to custom routers and more, there’s too many features of the native LB to dive into in one article.

If you’d like to learn more about Cycle’s Native Load Balancer, please check out this walk through by our CEO and Founder, Jake Warner.

💡 Interested in trying the Cycle platform? Create your account today! Want to drop in and have a chat with the Cycle team? We'd love to have you join our public Cycle Slack community!