Reasons for bad performance in distributed systems

Another great figure from DynaTrace, this time by Alois Reitbauer. It summarizes the possible reasons for bad performance in distributed applications.

Java Web Services separation of concerns

Source: Harold Carr, Clemens Vasters at JavaOne 2009

Practical advice about Distributed Systems

Distributed Systems generic approach:
- Develop "entity"
-- Define the Unit-of-Work (UOW) it supports
- Search for "entity"
-- Agree "entity" offers the desired capability or UOW
- Request "entity" to perform UOW
-- Create a network-transferable message
-- Send the message
-- Maybe try to make the remote interaction appear local
-- Maybe do some "enterprise" (Security, transactions, replication etc.) work as well

The same requirements are present throughout the stack:
- Uniform interface allows for generic infrastructural support
-- Caching, extremely loose coupling
-- Can push more requirements on to the "developer"
-- Requires more from external contract meta-data
- Specific interface allows for more limited generic support
-- Targeted caching, application semantics
-- Impacts less on the "developer" but may cost in terms of flexibility

Different approaches to distribution - there is no global panacea:
- Event Driven Architectures (Pub/Sub)
- Service Oriented Architectures
- Resource Oriented Architectures
- Message Oriented Architectures (MOM, Pub/Sub)
- Tuple Spaces (E.g., Linda, Jini)
- RPC based
- Group communication based (Reliable or unreliable)

Source: Mark Little at JavaOne 2009

Physical limitations of Distributed Systems

(...) Engineers should be aware of some of the fundamental limitations they face when developing (...) distributed applications — in particular, the finite speed of light.

"Fighting Physics: A Tough Battle" by Jonathan M. Smith in "Communications of the ACM", July 2009

No to SQL

It appears there is a "rebellion" against relational databases, as reported in Computer World.

This is the typical problem when you just use off-the-shelf software without considering other options.

Some years ago, Prof. PMMVAS, in a class, presented a good summarization of the trade-offs in the database world:

Data structure complexity VS Query capabilities

Relational databases have simple data structures (tables) but sophisticated querying capabilities (SQL SELECT).

Hierarchical databases (e.g. XML) have more complex data structures (records) and less powerful queries.

Object databases have complex data structures (object graphs, code+data encapsulation) but poor querying capabilities.


It is an interesting discussion on how to keep our digital "bookshelves" organized...

Advanced Distributed Systems (ADS) - naming and file systems

I'm taking a Advanced Distributed Systems course. We read papers and we present and discuss them.

The first two topics were:

Naming


1 - The Design and Implementation of an Intentional Naming System. William Adjie-Winoto, Elliot Schwartz, Hari Balakrishnan, Jeremy Lilley, SOSP 1999.
2 - Locating Objects in Wide-Area Systems. Maarten van Steen, Franz J. Hauck, Philip Homburg, Andrew S. Tanenbaum, IEEE Communications Magazine 36(1), January 1998, pages 104–109

Adjie-Winoto99 is a seminal paper for DHTs (Distributed Hash Tables). DHTs are good for matching items using identifiers but are not so good in matching attribute value ranges.

Another interesting topic were the trade-offs between soft-state (time limited persistence, fate sharing) and hard-state (persistence until explicit deletion). Hard requires recovery, checkpoints, transactions, logs. Soft allows for much faster node recovery.


Distributed File Systems

1 - An application of a context-aware file system. Christopher K. Hess, Roy H. Campbel. Springer-Verlag, London, 2003
2- The Google File System. Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung, SOSP 2003.

There are subtle differences in consistency definitions. For instance, the Google File System uses consistent and defined.

A file region is consistent if all clients will always see the same data, regardless of which replicas they read from.

A region is defined after a file data mutation if it is consistent and clients will see what the mutation writes in its entirety.

e.g. "The sky is yellow" - it's wrong, but it's consistent if everyone sees the same statement. Consistent isn't the same as correct.

John Chambers at MIT

It's not about YOU as Time Magazine stated, but about US, the on-line collaboration communities.

I was at John Chamber's talk at MIT. He is CEO of CISCO Systems.

He did a very good presentation overall. I was particularly impressed with the way he connected with the audience, climbing up and down the stairs, and looking straight into the people's eyes. He was using a lapel wireless microphone. He also used Powerpoint as a complete accessory. Great!

Some of his insights were:

On business...

Understand a crisis 101:
1 - Is it market-driven or self inflicted?
2 - Determine its length and depth
3 - Prepare for the upturn

Time frames:
Vision - 5 years
Strategy - 2 to 4 years
Execution - 12 to 18 months

Organizations are switching from "Command & control" to "collaboration". This change is process-driven and requires a common vocabulary inside a company.


On technology...


We're going from "software as a service" to "everything as a service".

The importance of telepresence, not just teleconference.

With collaboration and tele-presence, CISCO now can keep track of 26 priorities a year, instead of 2 or 3 as before.

In-network processing to perform bandwidth adjustment to destination's screen size.

They have an internal Facebook-like application that enables them to choose the right people for the right job, in a cross-department view. They have a reward engine in place that is based on these kinds of contributions.


--

Joana was also at the event and posted about it on her blog.

Distributed Systems: Principles and Paradigms (2nd edition)

Distributed Systems: Principles and Paradigms (2nd edition)



An updated version of my favorite book on distributed computing.

Excellent references list and suggested readings. It's a very good book to get a broad sense of distributed systems.

The new materials are mainly about peer-to-peer, with extensive discussion about distributed hash tables although scattered across the book.
There is also coverage for Web Services but it's not very extensive with some major omissions, namely WS-Security and WS-ReliableMessaging.

The new Architectures chapter is not very clear and it somewhat confusing because of the paradigm approach in the later chapters of object-based, file-based, web-based and coordination-based distributed systems.

Finally, I loved the new cover. It's much more sober and inspiring than the first edition's.