jump to navigation

ACID in the Cloud January 13, 2010

Posted by Peter Varhol in Architectures, Software platforms.

I’ve generally not worked in heavily transaction-based computing environments, and while I know the fundamentals of database management, I don’t have a lot of background in architecting scalable transaction systems.  I’ve discovered that key to scalable transactions is the acronym ACID – atomicity, consistency, isolation, and durability.

Atomicity is the ability to guarantee that either all of the tasks of a transaction are performed or none of them are.  A transaction can never be left in limbo, not committed to the system of record but not rolled back.

Consistency assures that the database remains in a consistent state before the start of the transaction and after the transaction is over.

Isolation means that other operations cannot access or see the data in an intermediate state during a transaction.  Doing so means that those operations may make decisions based on a transitional state rather than the beginning or ending state.

Durability means that once the user has been notified of success of the transaction, it will persist in storage, and not be undone.  Simply, a completed transaction is permanent, because its results have been written into a persistent storage.

As long as you can apply these characteristics to an architecture, you have a chance to build a mission-critical transaction-based application that can scale to a reasonably high level.

But the cloud makes such characteristics different, and more difficult.  Because organizations may be running application components both locally and in the cloud, rolling back a transaction can involve complexities in queuing, state management, and performance.

Yet there are good reasons to run mission-critical transaction-based applications in the cloud, not the least of which is the ability to scale on demand.  In addition, if you’re running an SOA, it may make sense to run certain high-volume services in the cloud.

But how you get there is a different story entirely.  The architecture you need for managing transactions in the cloud has to deal with both database performance and latency issues that are much more visible than they are in the local data center.

I’ve found one product that seems to address the issues of architecting for highly scalable transaction performance in the cloud.  I’ll write more after I look into it more closely.



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: