AWS autoscaling groups for a fixed number of instances

AWS autoscaling groups are a way to scale capacity up and down when it is needed. However, autoscaling groups are a great way to just keep a fixed number of instances alive. Let's say we have an app that we always want two instances of running. If one of them dies, it would nice to automatically restart it. To do this, simply create an autoscaling group with a fixed size:

"myautoscalinggroup" : {
   "Type" : "AWS::AutoScaling::AutoScalingGroup",
   "Properties" : {
      "DesiredCapacity" : 2,
      "MinSize" : 2,
      "MaxSize" : 2,
   }

Now Amazon does the heavy lifting for us, and we'll always have a pool of two instances.

JavaScript console object

Many of us have used the JavaScript console object for logging

console.log("some debug message");

But for a lot of us, that's the extent. Maybe we use console.info or console.error, but there is so much more to the console. For example,

console.group

lets you nest statements in a group. The following snippet:

console.log('hello, I am outside the group');
console.group();
console.log('I am in the group');
console.log('me too');
console.groupEnd();
console.log('I am also outside the group');

Produces an output of

hello, I am outside the group
    I am in the group
    me too
I am also outside the group

While the console should only be used for debugging (and there are better libraries for just printouts like debug) and is not necessarily standard across browsers, it can be a really powerful tool. Check out the console docs at https://developer.mozilla.org/en-US/docs/Web/API/Console for a full list of functions.

Mocking non-injected services with groovy

Sometimes we'll come across a piece of code that we want to test, but we're not able to inject a mock because the service is hard coded into the class. Consider this:

class Client {

    private final Service databaseService = new DatabaseService();

    def find(long id) {
       databaseService.find(id)
    }
}

Testing the find method would be difficult because the database service is not injected.

Groovy mocks and stubs can be used as categories for this case.

class ClientTest {

    @Test
    private testFind() {
        MockFor mock = new MockFor(DatabaseService)
        mock.demand.find { id -> someObject }
        mock.use {
           Client client = new Client()
           client.find(1L) // this will use the mock and return someObject
        }
    }
}

While injecting dependencies is easier, this is an alternative method when injection isn't available. See Using MockFor and StubFor for more details in the groovy docs.

Building fault tolerant applications with Hystrix

In any distributed system, failures will happen. Remote calls will fail, servers will go down and database calls will return errors. When these calls fail, it is important that the failures stay isolated and don't cascade throughout the system. With this in mind, Netflix built and open sourced their Hystrix library. They do a pretty good job of describing what it is:

Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where failure is inevitable.

In particular, Hystrix allows you to easily employ the bulkhead pattern to isolate calls to different 3rd party systems and to use a circuit breaker to prevent too many repeated calls to a failing system. Here's an example of a simple command that does a surprisingly number of complex things:

• This call will be executed using a thread pool to isolate it. All hystrix commands with the group MyCommandGroup will use this pool.
• This command will use a circuit breaker in case it fails. In this example, returning "Hello world" is not going to fail, but if it was a remote command it could.
• If the command fails, it will automatically use the fallback method.

public class RemoteCommand extends HystrixCommand {

    public RemoteCommand() {
        // "MyCommandGroup" determines which thread pool to use to execute the commands
        // Use a different group to separate logically different groups of commands
        super(HystrixCommandGroupKey.Factory.asKey("MyCommandGroup"));
    }

    @Override
    protected String run() {
        return "Hello world";
    }

    @Override
    protected String getFallback() {
        return "fallback to me if run() fails";
    }
}

The properties of the command (timeouts, circuit breaker threshold, etc) are highly configurable and can be tuned to your needs.

If you need a battle tested library for implementing these patterns, check out Hystrix.

Jenkins Job DSL Plugin

Jenkins has a ton of plugins available to it, some of which are more well known than others. One particular one that I've recently found to be very useful is the Job DSL Plugin. It allows you to use a groovy DSL to script the creation of your Jenkins jobs. This is beneficial because it makes your jobs recreatable and avoids the pattern where you create a bunch of similar jobs and then they slowly diverge. It also allows you to easily rebuild the jobs in the event of data loss.

As an industry we're getting better at automating the creation of our deployment environments with tools like docker, puppet, ansible and chef, but tools such as the DSL plugin allow for a nice way to automate the creation of your Jenkins jobs. For actually configuring your build environment using docker and ansible, check out this post http://blog.sequenceiq.com/blog/2014/05/09/building-the-build-environment-with-ansible-and-docker/ by the team at SequenceIQ.

Debugging gradle jettyRun in IntelliJ

I was trying to figure out how to attach a debugger to the jetty server launched by running an app from gradle jettyRun. It turned out not to be so straight forward, but here's what I did.

Step 1 - Upgrade to IntelliJ 13 if you're not there already. The gradle support has significantly improved.

Step 2 - Create a new Jetty Server (Remote) configuration. Gradle uses an embedded jetty server, but you need to point IntelliJ at the home folder of a Jetty installation. I downloaded Jetty 6.125 (Gradle 1.10 uses Jetty 6, this may change with newer versions) and pointed at that.

Step 3 - Configure the Jetty Server. I used the following values, but your may change them as needed.

Server tab:
- Application Server: Jetty 6.125
- JMX port: 2099
- Remote Staging type and host are both Same file system
- Remote connection (where your app is running) defaults to localhost:8080

Startup/Connection tab (Select Debug configuration):
- Port: 52252 (default)
- Transport: Socket (default)
- The window will show the parameters you will need to pass to GRADLE_OPTS (or however you get properties to gradle, such as through gradle.properties). These properties are in addition to other properties in gradle.

Step 4 - Create (or modify your existing one if you have) a jetty config file and point your jetty tasks at it as shown in http://blog.james-carr.org/2011/12/20/enabling-jmx-in-gradles-jetty-plugin/. I did not have a jetty-env file.

Step 5 - Start your gradle process from the command line with the following opts (or again here, in gradle.properties):

export GRADLE_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=1099 -Dcom.sumanagement.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -DOPTIONS=jmx -Xdebug -Xrunjdwp:transport=dt_socket,address=52252,suspend=n,server=y -javaagent:/opt/idea-IU-133.1122/plugins/Groovy/lib/agent/gragent.jar"


Note the -Xdebug and opts after that come from the arguments in the Startup/Connection tab in Step 3.

Step 6 - Once your app has started, start the jetty configuration from IntelliJ in Debug mode. Run your webapp, and your code should now stop at breakpoints in IntelliJ. Very many thanks to the StackOverflow's @CrazyCoder (http://stackoverflow.com/questions/14825546/deploy-debug-remote-jetty-with-intellij-12) and James Carr for his blog post referenced above.

Avoid flag parameters in public methods

I was recently reading some code that I wrote a while back, and it looked something like this:

run(true);

And then later on in the code I saw

run(false);

At the time I wrote this, it was very clear what this meant, and I was saving myself time by having a single method where a flag would slightly alter the behavior. Reading this code several years later, it wasn't clear at all what it was doing. So how did I write it so it was easier to read? Instead of having the flag in the public method, just have two separate methods, and bury the flag in a private method. After refactoring, my code now looks like:

runSynchronously();

and

runAsynchronously();

Internally, there is still a run method that takes a flag for running asynchronously, but the public API is now a lot easier to understand.