Loadscale: A Little Agent For Scale

I just came aboard as a summer intern here at Rackspace, and immediately, I’m getting my hands dirty on some pretty cool projects.

The first of which is Loadscale, a little tool that has a simple function: ping an Autoscaling group’s load balancer and see if servers need to be added or removed from the load balancer. This little project was to run alongside the load balancer and Autoscaling (codename: otter) team’s projects.

A user can use Loadscale as a trigger for Autoscale. Currently, Autoscale can be triggered using Rackspace Monitoring, meaning that when Monitoring notices a spike in CPU, memory or any other metric, it calls on Autoscale to scale up or down. However, Loadscale works by asking the Load Balancer the current number of connections it has – if the Load Balancer has many connections, then the user probably wants to scale up. If there are too few connections, the user likely wants it to scale scale down.

It’s a relatively simple script that ideally would sit somewhere, ping a load balancer, get data, go to sleep for five minutes, and repeat. Based on the data it gets back from the load balancer, it tells the scaling group to scale up or down. It requires the input of the scaling group name, the load balancer name, and the specific scale up and scale down policies to execute.

The current version has a lot more room to grow. First, it should automatically get the load balancer from the Autoscaling group. But more importantly, it should automatically get the range of connections a server can have from server size and internal settings rather than the user having to set up MAX_CONN and MIN_CONN values in the settings file.  However, these are things that can be changed easily (…hopefully).

The biggest lesson though is what I learned from Loadscale’s design. This is the first time I had created a non-personal codebase. That meant I was accountable for having readable code, making tests, and having it be community accessible – all of which I didn’t account for until near completion. D’oh. When I was nearly done, I realized that I couldn’t test anything because all the logic was grouped together. So I couldn’t test individual pieces without having to hack the tests. I had to refactor, break up code and make it clean for the tests to execute. This process helped make the code actually readable too.

Me when I realized my poor design choices.

When all was said and finished, however, I still had a problem. Is this how you actually set up these projects? Am I writing my tests well enough? Is there some secret recipe in how to make these things look and work much better than what I had done? Hopefully, time will teach me that.

Me: “Am I doing this right?”

I have to hand it to Ken Wronkiewicz  (my manager, mentor and lead otter); he gave me a project that was relatively easy but also gave me a great introduction to what goes on with the codebases/projects here at Rackspace. On top of that, everyone on the otter team has been really nice in answering my questions and making sure I understand how the project comes together. I think I’m going to learn a lot this summer.

Rack Blogger is our catchall blog byline, subbed in when a Racker author moves on, or used when we publish a guest post. You can email Rack Blogger at blog@rackspace.com.


Please enter your comment!
Please enter your name here