Into the Cloud: Moving Large-Scale Java EE Apps onto EC2 & RDS

18 Jul 2011 Into the Cloud: Moving Large-Scale Java EE Apps onto EC2 & RDS

Shine Technologies has recently completed a proof-of-concept migrating the hosting of two of its enterprise products into the cloud – specifically, Amazon Web Services (AWS).

This post is aimed at technical managers interested in leveraging cloud technologies to provide new and powerful options to both existing and new clients of established products. We’ll first give a quick overview the products, and then explain why hosting them in the cloud is beneficial for us. We’ll then finish off with a couple of things we’ve learnt whilst getting our products going in the cloud.

Product architecture

NBV and NBM are two of Shine’s products for the energy industry, and are installed on various client sites throughout Australia. They have a three-tier architecture based on Java software and an Oracle database.

Users interact with the system via a desktop client application that is also written in Java. This client uses Enterprise Java Beans over the Java Remote Method Invocation (RMI) Protocol to communicate with the server. The client is designed so that most queries are sent to the server and executed in the background, with the results returned in pages to the client when they are ready.

The applications also do resource-intensive batch processing of large data files uploaded directly to the server, and produce output files that can be downloaded from the server.

Hosting

Originally, NBV and NBM were built to be hosted on dedicated machines installed within each customer’s organization and administered by their staff. The application server and database tiers run on physical servers, and the client runs on staff desktop machines.

When migrating to the cloud, the application server and database tiers are installed on virtual servers, with the client still running on staff desktop machines that connect to the servers in the same way. These two approaches are demonstrated in the following diagram:

From this diagram, we see that an Amazon EC2 instance is used for the application server, which is a virtual server with full root access on which to install the Java-based software. Furthermore, an Amazon RDS instance is used for the database, which provides a virtual server with a pre-prepared Oracle installation on which to create the schema.

First impressions after installing the system were that the internet connection to the cloud has low-enough latency and high-enough bandwidth to perform the operations required by the client desktop operation with low performance impact. Furthermore, load testing determined that, whilst batch throughput was lower than the performance of the dedicated hardware set up on-site (which uses a native operating system and local SCSI disk arrays), it was still acceptable for our customer’s needs.

Benefits achieved

We see a number of benefits of having the option to host our products in the cloud:

• The instance sizes (server capacity) can be scaled up or down with far greater ease than physical hardware. This means the performance can be increased during periods of high demand, or switched off entirely when not in use to reduce costs.
• The cloud environment provides new options for our clients. Product demonstrations could be done from cloud-based installations, which are low cost to set up. This would allow us to demonstrate new features more often. Previously this was done by installing all three tiers on a laptop.
• Instead of clients spending resources maintaining a full time user acceptance testing environment, one could be set up on temporary cloud servers for the duration of testing. This would remove any disruption of the production system and eliminate the need to keep spare hardware capacity. It would also reduce support costs since support staff could also have full access to the test environments.
• Eventually the products may be offered using a software-as-a-service (SaaS) model with cloud hosting. This could include configuration and upgrades, which means the client would not need staff to do this. It could also reduce outsourcing costs for systems administration for clients that do not have internal IT staff.

Issues and limitations

It’s worth noting that there were a couple of issues that we did encounter during our migration to the cloud:

• In order to push notifications of job completion to the client, the server must open TCP connections to the client. While this worked fine over the LAN, to make this work over the internet would require special setup. It was therefore decided to replace this functionality so that the cloud would be a more viable option. Based on the requirements of the notifications, the limited use of polling was chosen over Comet as as a suitable solution. The application was then modified to achieve this.
• While RDS provides simplified administration of the database, in order to achieve this certain Oracle features are unavailable. The biggest impact for the application was the Java stored procedures failing to compile. These stored procedures are used for performance-critical batch processing, so alternatives are still under investigation.

Conclusion

The migration to the cloud has been relatively straightforward for our product. The product architecture has been largely compatible with cloud hosting, with only minor modifications. The cloud provides great flexibility in terms of provisioning hardware and provides new options for running enterprise applications, and a good platform for continuous deployment.