Dekoh - Amazon EC2 case study

This is a great case study demonstrating how smart developers are moving their production environments over to Amazon EC2.

Last December, I met with Pramati Technologies - a well known household name when it comes to JEE Web Application Server. I learnt about their really cool Web 2.0 product: Dekoh. Dekoh can be described as 'Facebook on the desktop'. It consists of the Dekoh Desktop and the Dekoh Network. The Dekoh Desktop runtime - a JEE compliant small footprint application server - runs on the user’s desktop and converts it into a secure server. The Dekoh Network is a complete server-side solution ecosystem built on top of Amazon EC2 environment. It handles centralized user management and "presence" management.

Third-party developers can write rich applications on top of the Dekoh runtime and can take advantage of the Dekoh Network (friends, groups access permissions). All communications across firewalls is managed by the Dekoh runtime. The Dekoh Network has been built to scale on-demand so when thousands of dekoh applications access the hosted architecture, a few clicks will provision Amazon Machine Images and will dynamically join the topology. This is managed by sophisticated load balancing and dashboard monitoring also built by Pramati. I was impressed by their energy, their Java expertise and their passion.

In an email, they shared:

A virtual computing platform like Amazon’s EC2 serves as a perfect fit for Dekoh. Our experience building production configuration for the Dekoh backend components on Amazon’s EC2 platform has proved to us how quickly an application can be put in production mode without worrying about bottlenecks of the underlying server resources.

I had an opportunity to dig a little further into their hosted architecture.

Each desktop instance connects to a set of of loosely coupled components hosted in the EC2 cloud. The user access component is managed through a 'Login' instance, and the user's list of friends and groups is managed using 'Profile' instance. The content sharing component along with user availability is managed through a 'Presence' instance. Each component is pre-configured in the form of an AMI.

To ensure high-availability and failover there are multiple instances of the Login, Profile, and Presence servers. Each component has an individual load-balancing node which is a custom-built Pramati software Load Balancer. During peak loads, a new instance with its load balancer can be automatically started. Each component manages its own master-slave database replication model. I think this type of loosely coupled on-demand model is not only scalable but also easier to manage than some of the other models I've seen.

Pramati takes pride in their Java expertise on the Amazon EC2 environment and would like to help customers who are eager to move their Java-based production systems to Amazon EC2. Their automated scripts not only sets up the required instance but also updates the load-balancer configuration files to reflect the newly added node. Automated scripts also provide data for real-time monitoring of network topology (CPU/RAM usage etc).

It seemed like Pramati knows what it takes to build a large-scale production system on Amazon EC2. Hence, we invited them to share their architecture, insights and best practices with the community. Pramati is going to co-present with us at the upcoming TheServerSide Java Symposium on March 28th.

I strongly encourage you to check out Dekoh! 

-- Jinesh

Comments

[Jeffrey McManus]

I'm not a load-balancing expert, so I may be totally wrong here, but on that Pramati page they say that hardware-based load balancing "can only be used as a Round-Robin algorithm based network and can not perform request packets based extensive operations" which is not only ungrammatical but seems also incorrect.

How can you control intra-node latency in this scenario? Isn't it possible that your Users node and your Contacts node could be located in different physical data centers?