Next Generation Architecture

Earlier this week, I talked about some of the short term work we’re doing to establish performance benchmarks and some of the first steps toward speeding things up.  I also mentioned the issues we have with our instance-per-customer deployment model.  I neglected to mention what our proposed solution is for a long term architecture that provides greater reliability, faster performance and efficiently uses resources, so I thought I’d do a short post to catch every one up on our progress toward the next generation architecture.

In A Nutshell

Over the next twelve months we’ll be modifying Flex to support something called multitenancy, which means a single instance of Flex will simultaneously support hundreds of customers.  This will enable us to allocate resources based on customer load or usage.  Instead of having one server for every eleven customers, we’ll have a minimum of two servers (for failover) in front of a load balancer and dynamically allocate additional server capacity in response to load.  When the load drops off (overnight, for example) we’ll spin down the extra servers.

We also plan on adding some extra special purpose servers for things like report generation, caching, search and indexing and overall control of the cluster.  The diagram shows what we’re thinking about doing:

Planning the hardware deployment architecture is always fun, but the bulk of the work will be in the software.  There are a lot of interesting software engineering problems we’ll be tackling and none of these problems are unique to Flex; they’re common to any traditionally developed back office J2EE application migrating to a cloud based mult-tenant architecture.

The Alto Project

We’ve already started work on the software part of this problem by creating an open source project dedicated to providing frameworks and utilities J2EE projects will need to move to a mult-tenant efficient cloud architecture.  You can find a summary of the engineering problems we’ll be addressing by viewing the project’s wiki here:

You can also take a look at the project’s source code as it develops and even contribute if you’re so inclined.

Two Ways

A unique challenge for our architecture is that we always want to maintain support for the single instance back office model.  Just as there’s now a big move to the cloud, who’s to say that some years down the road there won’t be a move back to self-hosted applications.  This prospect, along with the fact that we do have a fair number of self-hosted or dedicated hosting customers, means we never want our architecture to “force” anyone to be in the cloud.  We need an architecture that works both ways without requiring separate builds for a cloud deployed version or a self-hosted version.  Switching between the two should be configured solely through external JNDI parameters.

So, that’s the vision for Flex over the next year or so and a big reason why we feel branching the code is so important.  Work on this next generation architecture is ongoing and will ramp up even more once we’ve addressed the Hibernate performance bottlenecks.  We need to be doing this work in a code branch that won’t impact or slow down ongoing Fast Track projects or routine maintenance.

I, for one, am looking forward to the next twelve months.  I’ll get to work on some pretty cool stuff.

Leave a Comment