Dr. Dobb's | Distributed Computing: Challenges Ahead

Distributed Computing: Challenges Ahead

Terracotta CTO Ari Zilka talks with us about the challenges ahead for distributed computing.

October 10, 2007
URL:http://www.drdobbs.com/architecture-and-design/distributed-computing-challenges-ahead/202401127

Ari Zilka

Ari Zilka is founder and Chief Technology Officer at Terracotta (www.terracottatech.com), a company that focuses on enabling distributed Java applications. Prior to that, Ari was Chief Architect at Walmart.com.

DDJ: Over the past couple of years, distributed computing has grown to encompass a number of technologies and approaches, including grids, clusters, concurrency, and the like. What do all of these have in common?

AZ: Distributed computing delivers to business a nonstop computing platform that can scale on demand, and can be made 100-percent available in that the loss of a few servers doesn't equate to a loss of application services. Whether partitioning workload across a grid of servers—like Google—or installing the same application on multiple servers in a cluster, everyone is writing programs in a distributed/concurrent way to promise a scalable and highly available operation. It's a classic divide-and-conquer strategy, yet with no single point of failure.

DDJ: Do we currently have the necessary tools for distributed computing?

AZ: Many approaches depend on development APIs today. So all the concurrency, replication, and general correctness of business logic when spread across many servers is handled in an expensive manner, directly in every application's source code. Yet a new approach has emerged to combat the notion that distribution is a matter of copying the data to a cluster, then updating the cluster in a transactional manner. I call this approach "network attached memory" (NAM). Think of it like NAS but for RAM, and the implication is that memory can be durable and scalable.

The problem is that writing to disk makes our data available, but slows our app down by bottlenecking on disk I/O. By writing to durable RAM that can be reached by not just one server but many, we can write at faster network speeds, and we can avoid moving data out of application-native format, thus improving latency and throughput. Also with NAM, just like with storage where we get to decide which files are local and which are networked, we can decide which memory is local and which is networked. With NAM, we have the right tools to deliver scalability to the application tier without lots of custom development.

DDJ: The focus of your company, Terracotta, is on Java, which was originally designed, generally speaking, as a language for embedded systems. Do we need to begin thinking in terms of more specialized languages when it comes to building large-scale distributed systems?

AZ: I don't think so. Languages are languages and frameworks are frameworks. In the case of Java, the virtual machine is proving very powerful and extensible. It runs Ruby, .NET, PHP, and Python all faster than their native runtimes. So it has performance (and stability) on its side. Java also has succeeded in abstracting most of the platform idiosyncrasies we used to live with. As a result, we can assemble computing environments that are heterogeneous, and write apps that are portable and completely scalable. All this comes from an object-oriented and flexible core, which lets us abstract as necessary. And abstraction is the key to successful distribution.

But frameworks exist more to focus thinking and provide well-known patterns than to provide flexibility. I have seen distributed computing use cases that are so different that a good framework in one case could be poor in another. This leads to my strong belief that distributed computing is a deployment artifact and should not be a design artifact.

DDJ: Programming languages aside, what are the biggest challenges to building successful distributed computing systems?

AZ: My experience shows that there are very few good ways to cluster a database, whereas distributed computing has a high need for shared state and signaling. This is the biggest challenge—scaling stateless applications. Most frameworks assume stateless architecture. This causes a bottleneck on the database leading to clustered database implementations, and it also leads to unnecessary use of transactions to update state in a reliable way.

There is another challenge, which I will call "applicability." When deciding on a replication/partitioning scheme, many frameworks are incompatible with such distribution strategies as including stateless replication to a database or stateful replication over a network.

As such, distributed computing cannot even be delivered (it is not applicable) when using those frameworks. In any case, distributed computing, used as a means for scaling applications, requires a low-level infrastructure service that does not affect application development as much as database and network-based approaches do today.