AWS Toolkit for Eclipse Integration with AWS OpsWorks

Today, we are introducing a new addition to the AWS toolkit for Eclipse — the AWS OpsWorks plugin. This new plugin allows you to easily deploy your Java web applications from your development environment directly to AWS infrastructures.

So you might remember the AWS CodeDeploy plugin that we introduced recently, and some of you have probably used the AWS Elastic Beanstalk plugin before — they both seem to provide the same functionality of deploying a Java web app. Then why do we need yet another option for accomplishing the very same thing?

AWS Elastic Beanstalk, AWS CodeDeploy and AWS OpsWorks indeed share a lot in common as they are all considered part of the AWS deployment services family. However, they differ from each other in aspects like deployment execution and infrastructure resource management, and these differences make each of them suitable for a specific category of use cases.

• AWS Elastic Beanstalk is a fully-managed application container service. It’s based on a PaaS (Platform as a Service) model where your application is provisioned by infrastructures that are automatically managed by AWS — there is no need for you to manually build and maintain them. As a container service, it also provides built-in deployment features for a variety of web app frameworks. All of these allow you to focus on your application development, while the deployments and provisioning of the application are handled by the service powered by cloud ninjas. The downside of this whole black box-ish model is of course its limited flexibility and extensibility. For example, you might not have fine-grained control over the underlying infrastructure resource, and it sometimes could be difficult to extend the built-in deployment commands to execute your custom tasks.
• In contrast, AWS CodeDeploy focuses on only one thing — managing deployments to your existing instances in EC2 or elsewhere. It is not an application container service, so there are no built-in deployment features. You need to write your own deployment logic, which gives you the freedom to perform any kind of custom tasks for your deployments. Another difference compared to Elastic Beanstalk is that the service does not create or maintain the EC2 instances for you; you need to manage them yourself, which also means you have full control over your infrastructure. At a higher-level, you can think of AWS CodeDeploy as a fully-programmable robot that delivers your application artifacts to your EC2 instances fleet and then runs your custom commands on each of the instances for you.
• Within the range between fully-managed (Elastic Beanstalk) and fully-customizable (CodeDeploy), AWS OpsWorks sits somewhere in the middle. It is an application management service that provides built-in deployment features for instances running a specific web framework (a.k.a., an application server layer). The reason that makes it really stand out compared to Elastic Beanstalk is that it uses Chef to perform the deployment actions. The deployment logic for built-in layers is essentially a default Chef cookbook that is open to all levels of customization. Using Chef allows you to achieve the necessary customization for your specific task while at the same time enjoy all the built-in features that are useful for the majority of use cases.

So generally speaking, AWS Elastic Beanstalk is the easiest option if you need to quickly deploy your application and don’t want to be concerned about infrastructure maintenance. AWS CodeDeploy gives you maximum flexibility but lacks built-in deployment features. AWS OpsWorks has a good tradeoff between flexibility and ease of use, but you need to learn Chef in order to fully utilize it.

Ok, now I hope I have answered your doubts about why you should care about this blog post if you are already familiar with the other deployment services. Then let’s get back to Eclipse and see how the plugin works.

After you install the new AWS OpsWorks Plugin component, you should see the “AWS OpsWorks” node under the AWS Explorer View. (Make sure you select “US East (Virginia)” as the current region since OpsWorks is available only in this region.)

The top-level elements under the service node are your stacks, each of which includes all the resources serving the same high-level purpose (e.g., hosting a Tomcat application). Each stack consists of one or more layers, where each layer represents a system component that consists of a set of instances that are functionally the same. For each layer that acts as an application server, it is associated with one app, which is where the revision of the application code for this layer should be deployed to.

For this demo, I have created a sample stack that has only one Java App Server layer in it and I have started two EC2 instances for this layer. Creating all of these can be done in a couple of minutes using the AWS OpsWorks console. We will create the Java app for this layer inside Eclipse.

To start with, let’s switch to “Java” or “Java EE” perspective and then create a sample web project. File -> New -> AWS Java Web Project. Then in the Project Explorer, right-click on the sample project that we just created, and select Amazon Web Services -> Deploy to AWS OpsWorks.

In the first page of the deployment wizard, choose our target region (US East) and target stack (MyStack) and then let’s create a new Java app called “My App“.

In the App Configuration page, you are required to specify an S3 location where the application artifact will the uploaded to. You can optionally pass in additional environment variables, specify a custom domain, and enable SSL for your application.

Click Next, and you will see the Deployment Action Configuration page. Here you can optionally add a comment for your deployment and  provide custom Chef JSON input.

Now click Finish, and the deployment will be initiated immediately. Wait for a couple of minutes until all the instances in the layer are successfully deployed.

After it finishes, you will see a confirmation message that shows you the expected endpoint where your application will be hosted on the instances. You can access the endpoint via web browser to make sure the deployment succeeds (make sure you include the trailing slash character in the URL).

As you can see, because of the built-in support for Tomcat applications, it’s really easy to deploy and host your Java web app using AWS OpsWorks. We want to focus on the deployment experience of this plugin, but we are also interested in what other features you are specifically looking for. More support on service resource creation and configuration? Or integration with Chef cookbook and recipe? Let us know in the comments!