Develop Reference

Creating a program to manage Amazon EC2 instances

I am attempting to create a program that can manage EC2 instances (create, stop, terminate). I am unfamiliar with the service, and after looking through documentation and searching the web have not found any general advice on creating a management service. My questions are:
What programming environment/language would best be suited to creating a management program?
How can this program interact with EC2 instances? (I've looked into AWS EC2 command line tools. Can these be used from a program to create/terminate instances?)
Any general advice in accomplishing this is appreciated (links to examples especially).

What programming environment/language would best be suited to creating a management program?
This question cannot be answered in a definite way, rather you should either choose the language you are most comfortable with or that's best suited to your environment/team instead - there are plenty to choose from, most popular major languages are covered by a dedicated SDK (currently Java, .NET, Node.js, Python, PHP, Ruby), see Tools for Amazon Web Services for the detailed listing and links to further information about each.
Please note that there are also two IDE Toolkits listed that might make it easier to get started if you happen to develop in Java or C#, specifically the AWS Toolkit for Eclipse and the AWS Toolkit for Microsoft Visual Studio.
How can this program interact with EC2 instances?
All the SDKs (and also the command line tools build on top of these) do use the AWS APIs to interact with the respective services (each one has a separate API, but most of them are structured very similar), see Documentation for a listing of all currently available services and links to their documentation:
Welcome to the Amazon Web Services (AWS) Documentation. Whether you are new to AWS or an advanced user, you can find useful information about the services ranging from introductions to advanced features.
To learn how you can get started with AWS, see our Getting Started with AWS guide. If you are interested in learning more about our AWS Free Usage Tier, see our AWS free usage tier article.

I guess you are new to the cloud and aws world, you can use AWS Command line tools to management the services. Also to make things pretty simpler you can make use of the readily available aws management console if you are only worry is to start, stop or terminate the instance. Also people have build some thing called Config management system like opscode chef which is built of ruby or you can use puppet built of puppet lab's custom DSL.

I am not sure if you really need a program to do that. The Amazon Management Console ( https://console.aws.amazon.com ) is pretty straight forward, simple to use, you can spin thousands of instances in a very short time. I created 20 instances in about 3 minutes and deleted(terminated) 9 during my first interaction with the technology. Would you provide a use case where this is necessary? Its like you want to create a missile to kill a chicken(rather than buy a knife)
HTH, Thanks,
Bles

I used to work on a project that deals a lot with EC2 and one of my responsibility was to manage instances remotly( deploy/start/stor/reboot). I used Java and the Amazon API to write a communication module for the application.
In addition I made a few general ant scripts to deal with code that has to be deploed into an instance. Kind a old fashion way, but works perfectly :)

JMX "Dashboard" App

I have been playing around with JMX for the last few days and although I don't mind JConsole or the standard JMX web admin tool, it would be nice to create my own web app that somehow queried the registered JMX MBeans and presented a nice, rich-UI-style "dashboard" with charts and graphs; things that the JMX console or JConsole simply do not have.
Is this possible? I've heard of something called a JMX "agent" but not sure if that has anything to do with how JMX can be queried and managed by a dashboard-style app. Thanks in advance!

Jolokia is an agent based approach to JMX which translates JMX native calls to JSON-over-HTTP. It comes with a Javascript library which is perfectly suited for used within the browser. For a sample usage within a web page look at the demo of the Jolokia-Cubism Integration or even better have a look at the blog post from Tomasz Nurkiewicz which gives a very nice example of using Jolokia along with the Highcharts graphing library.
Said all this, there is even more: Ají, Jolokia's fancy sister, has been started as project which will provide an JMX console bundled along with Jolokia clients. I'm still sorting things outs (well, it moves slowly ...), but I think that over the summer more will be there. One can already play around with it and we still look for volunteers (hint ;-) ....

What you are looking to do has probably already been built unless you really want to do it yourself. Have you looked at VisualVM before? I really like it http://visualvm.java.net/mbeans_tab.html/
To write your own application that manages MBeans remotely I think you could start with this tutorial. Seems to be a good starting point.
http://docs.oracle.com/javase/tutorial/jmx/remote/custom.html

One of the comments here is that VisualVM is a profiler. VisualVM isn't a profiler, it's a platform built on top of the NetBeans platform. The platform supports connecting to a VM in flight a number ways including using a JMXConnector to the MBeanPlatformServer, Serviceability Agent (SA), Attach on demand and so on.
VisualVM does contain 2 different profilers but there is also an MBean plugin that allows you to view and manipulate MBeans that have been registered with the MBeansPlatformServer.
A number of the view in VisualVM scrape data from the MXBeans found in the java.lang.management package that are registered with the MBeansPlatformServer. Many of these MXBeans are wrappers over the SA, a component of HotSpot that maintains a set of performance counters. For example, counters can give you some information about JIT compiler activity, GC activity and even host platform CPU utilization and so on.
You can easily build your own plugins to view or manipulate MBeans. The tutorial mentioned in a posting here is one source of information as to how to get it done. I have written a demonstration VisualVM plugin that looks at data from the MemoryPool MXBeans. That plugin has been augmented by others to do a number of other things. All the code can be found at java.net in the project MemoryPoolView. It covers reading data. However executing functionality is really just executing a method against the JMXConnector with the parameters required by the MBean you are interacting with. IOWs, it's a fairly trivial extension of the plugin.

HawtIO Is about the best plug-and-play, works out of the box solution for getting JMX stuff on a web page. You can put multiple mbeans on the same page and see them all at once, it works in a browser, you don't have to write a bunch of front-end code yourself, and it can be done without opening up weird ports that your IT department will get nervous about. The data visualization options that work with the simple drag and drop interface are pretty minimal, but there is documentation for writing more advanced plugins.
The backend uses Jolokia to put an HTTP REST interface on JMX, which is probably going to be true for any solution you might look at.

Standalone Daemon or App Container?

I've been researching Apache's commons-daemon and it seems pretty cool: basically its an API as well as a library that helps register your JAR with the underlying OS so that it can be started and stopped like a daemon service. Additionally, it intercepts OS signals that would normally kill your app and instead gives you a chance to shutdown politely.
So it's got me wondering, if given the choice between deploying your business logic inside EJBs and wrapping them in a container like OGS or JBoss, why not just create a daemon JAR that listens on a port and responds to client requests?
Is it just the benefit of all the features/services that an app container provides out of the box (security, logging, etc.), or are there times when it would be favorable to choose a daemon over an app container/EJB solution?
Basically, what I'm asking if: when is it more appropriate to use an app container/EJB solution, and when is it more appropriate to use commons-daemon to help build a system-level service (in Java)?
Disclaimer: just interested in these two choices, I am aware that other solutions exist (web containers, ESBs, OSGi, etc.). But for the purposes of this question I am only interested in hearing the reasoning between app container or daemon solutions. Thanks in advance!

Why don't you look at it like System level (daemon) vs Application level (in container)?
This will give more or less clear distinction (especially if worked with Linux some time).
For Daemon:
has its own life cycle (you can start and stop it separately);
different privileges (could be run under different user);
use case is something like CRON, MailServer, synchronization and any system-level service.
For Container:
managed app (by some privileged user via Container console);
plenty of out-of-the-box features (which you'd already mentioned);
use case some general case business application.

Well the simple answer is yes, the app server (Glassfish or JBoss) give you plenty of nice things that you would have to implement or setup yourself in a plain Java SE app.
However it is not so black and white, and you can get a lot of the application server goodness with very little effort, I am in the process of writing a blog series on exactly this topic.
My reason for not using an app server, was that we had a project for a widely distributed software product, and we wanted to avoid having to patch and maintain thousands of application server instances!
However if your app will be running in one place, there is little reason to go Java SE.

What sort of Java container for long-running processes on EC2?

I'm a long-time client-side (Swing) developer and I operated pretty much by myself in the same job for a long time. Working from home in a vacuum, I was pretty much completely isolated from the community. I recently took a position as a server-side Java guy for a startup, and I'm learning a ton of stuff but I'm the only Java person and am pretty much on my own again. Having never done server-side Java before, so much of this stuff is completely new and I feel like I have no idea what the normal best-practices are, or I don't have an intuitive feel for what tools to use for what jobs. I keep reading and reading various Internet sources (SO is awesome!) trying to bulk up my knowledge, but some things seem hard to search for because they don't have any obvious keywords. Hopefully some of you gurus here can point me in the right direction.
I'm in charge of implementing our backend REST service, which for now supports our website and an iPhone app. We're doing a social media site, eventually with many different clients. Currently the only clients of the service are our own website and our own iPhone app. I'm using Jersey, Spring, Tomcat, and RDS (Amazon's MySQL) on Amazon's EC2 platform. Our media storage is via S3. I've picked up all of these things pretty quickly and so far so good -- things are working fine with the website and the iPhone app. Cool.
Our next step is adding some long-running server-side processing. This processing is basically CPU-intensive stuff that doesn't involve any communication until it's done. I'm trying to figure out what the best way to handle this is. I'm thinking of using Amazon's SQS to queue up jobs in response to the REST events that should trigger them, but I can't figure out how I should handle the dequeuing and processing. I know I need some threads somewhere that take jobs off the SQS queue and process them, and then tell the REST service that the job is done. But where do these threads live?
In a plain "java -jar jobconsumer.jar" process on another EC2 instance that starts a small thread pool. Maybe use Spring to wire up this piece and start it running?
In a webapp deployed in a container like Tomcat on another EC2 instance? I don't really know what benefits I would get from this, but somehow running in a container like this seems more stable? Does this sort of container even really support long-running processing loops, or is it just good at responding to HTTP events?
Now that I write it out like that, I don't really see why I would want to use a container. It just seems like an over-complication. However, the Java community seems so centered on these types of containerized, "managed" environments that to not use a container seems somehow wrong. I feel like maybe I'm not understanding what some of the major benefits of these containers are? I mean, beyond the obvious benefits of the web-facing Servlet and JSP specs. Would any of the functionality of those specs help me out with something like this?

For a regular Java web app, you almost certainly want to be using one of the Servlet containers such as Tomcat - it takes care of accepting connections, parsing and serialising HTTP messages, JSPs, SSL, authentication, etc for you.
For a non-web app, the argument for using Tomcat (or similar) is weaker, but there are a few reasons to still consider it:
straightforward to add JSPs for querying and managing the app or add a web API in future
easy distribution of releases (one .war vs. an unholy mess of jars and config files)
hot deployment (although I've yet to see anyone using this for anything serious)
In terms of long-running processing loops, Servlet containers don't help you out beyond notifying your ServletContextListener when the app starts, so you can kick off any long-running tasks.
It's worth noting that if you're already using Spring, it's relatively easy to switch from a stand-alone app to a container using ContextLoaderListener, so it shouldn't be a problem if you decide later that you need the web stuff.

We recently faced a similar question, as we are hosting a large distributed service on EC2.
In short, we are very happy with Jetty 7 as a container. We use it for our user-facing-www, public-api, and internal-backend-api services. In some cases we use it for non-api services such as a workqueue, simply to expose a bit of status & health info for our monitoring.
The great thing about Jetty (any version) is that it can be configured in ~5 lines of code, with zero external config files etc. It's not a container specifically, but an http server that you can embed.
We use Guice for dependency injection, which also favors config-file-less implementations.
Long lived Java processes are nothing to worry about - you basically bring up your servers / threads / threadpools in your main method and don't call System.exit until you want to shutdown explicitly.

Glassfish Clustering architecture and Node Agents

I am going to be creating an application that will be highly distributed. There will be several "agents" each agent is a source of events, from external devices, ftp or filesystem. These agents will be deployed on seporate machines, close to the hardware source that will create the event. These agents will report back events to the central system for processing. One of the requirements is to be able to deploy new agents on the fly. These choices will be made by the user, because they will know what machines will be close to the hardware device, or will contain certain events. I will be writing this application in java, and have been looking at the glassfsh platform and what it can provide for me.
I'm looking at the clustering functionality of Glassfish, the Node Agents, and the heartbeet and startup functionality of the Node Agents.
My question is, can the clustering functionality support my requirements, I believe the original intent of the cluster is to load balance requests. My requirement is not quite the same, but it seems that Glassfish is really close to solving my requirements.
Does Glassfish offer the ability to expose what agents will have what applications, and allow me to configure the application running in a specific agent seporate from the application running on a different agent?
if anyone knows of any other platform that would allow me to deploy agents and manage them individually, along with supporting a heatbeet, and other management / high availability tasks I would love to hear of them.
Thanks
Joshua

Might a JMS based system be more appropriate for your application?