DevOps Zone is brought to you in partnership with:

A passionate professional in areas of java performance, distributed systems and in-memory-data-grids. For the last 5 years I was working on various performance critical java systems (usually involving data grids) in areas of finance, telecom and ecommerce. See http://blog.ragozin.info for a list of my articles. Alexey is a DZone MVB and is not an employee of DZone and has posted 4 posts at DZone. You can read more from them at their website. View Full User Profile

Java as a Platform for Deployment Automation

03.25.2013
| 6471 views |
  • submit to reddit

I love automation. Computers are working and I’m being paid – a beautiful concept isn’t it?

I’m working with Java and clustered applications. So my routine tasks look like: “deploy a new build to half dozen of servers, then start few dozen of processes across these servers, then wait for all processes to do initialization, and, finally, initiate preloading of data to a cluster” or “deploy load generator on few dozen of servers, then start generating a load from hundreds of generator instance, hour later collect metrics and produce a report”.

To put it simple, I have to control multiple servers, do a lot of stuff in parallel and sometimes need coordination between these activities.

What tool would be good for such job? There are several ones trying to address this domain, to name few: FuncFabricCapistrano. In past, I was using Fabric quite successfully. You can notice that all of them are written in either Python or Ruby.

How about using Java for same task?

Sounds insane, isn’t it? :)

Ok, let’s try to stop laughing and try to consider it seriously.

On good side:

  • Java is cross platform (I’m mean really cross platform, e.g. it runs of Spark Solaris same way as it does on x86 Windows).
  • Java has enormous eco system of libraries.
  • JDK is not coupled with OS - you do not need a root to install JVM (or place a jar), multiple version of JDK could coexist peacefully on same OS.
  • On bad side:

  • Java “feels” heavy; you need to compile code then package ...
  • Well, I entry barrier to make a simple deployment tool in Java seems to be quite high. Imagine solving one of tasks described above in pure Java.

    Indeed there a lot of hassles, but after years of searching, I can say that I have a solution. On my blog you can read about a library making remote execution of Java code as easy as remote execution of shell command via SSH.

    As easy, as ...

    @Test
    public void remote_hello_world() throws InterruptedException {
        ViManager cloud = CloudFactory.createSimpleSshCloud();
        cloud.node("myserver.acme.com");
       
        cloud.node("**").exec(new Callable<Void>() {
            @Override
            public Void call() throws Exception {
                String localHost = InetAddress.getLocalHost().toString();
                System.out.println("Hi! I'm running on " + localHost);
                return null;
            }
        });
        // Console output is transfered asynchronously, 
        // so it is better to wait few seconds for it to arrive
        Thread.sleep(1000);
    }
    

    Simple utility for remote execution combined with richness of Java platform (threads, java.util.concurent, etc), suddenly makes tasks like "start something at 10 servers, then wait for ..., then do ..." fairly trivial.

    Benefits of automation using Java

    I’m actively using this library for about a year. First, it was used mostly for performance test automation, but later I have found it extremely useful for other routinely tasks such as deployment. During last year, I was slowly phasing out shell scripts replacing them with Java code.

    One critical outcome from this transformation is mavenization of all maintenance activities. Deployments of builds, starting/stopping environments – all these tasks are launched as maven goals (DB schema management is in maven too). Being maven goals makes this utility code very portable, they are executed in exactly same way from both windows-based developers’ desktop and Hudson CI server running on Solaris.

    Another outcome was reusability of deployment logic. Having them written in Java, allows you to apply common coding good practices. There are, probably, some good practices for writing shell scripts; it is just that I cannot afford to spend few years to learn them.

    What is a bottom line?

    If you are not using Java already, I would not advertise you to use it just for sake of environment management automation. But if you are using it and invested already to be good with it, it makes a perfect sense to leverage your skills and use Java as a platform for deployment automation.

    At least for me, this approach was very successful. And this success is measured by hours of work, which were saved by automation.

    Give it a try, it is worth it.

    Published at DZone with permission of Alexey Ragozin, author and DZone MVB.

    (Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

    Comments

    Marcus Philip replied on Sun, 2013/04/07 - 9:20am

    You are not insane :) It makes sense. A former colleague wrote a package in Java for installing all middleware for, and components of our solution plus a CI server. He tried to do part in Groovy as well, but came back to Java. I thought this was a great solution. The overhead of compiling and packaging as you have in Java is completely irrelevant. It's only a plus. 

    Comment viewing options

    Select your preferred way to display the comments and click "Save settings" to activate your changes.