How to architect a modern distributed architecture

How do you effectively build a distributed, enterprise architecture? It's a daunting, if not somewhat nebulous question, akin to asking someone how do you build a house?  The answer depends on what kind of dwelling you are building. In the same way, how you decide to architect your distributed system will depend largely on available resources and the business requirements. There are many aspects of distributed architecture and many choices, each with its own purpose, pros and cons, and use cases. Here's an overview of some of the key elements:

Clients and servers

Client/Server distribution and the nature of the client (end user device) itself are important factors in understanding distributed architecture. If the client just features a UI, the server is doing pretty much all the work. If the client hosts part or all of the application and even some of the data (i.e. thick or fat client), it represents an important portion of the architecture. A desktop PC typically has a lot of its own memory space and processing power to host and run applications with only occasional updates from a server. In contrast, a mobile device (even many smartphones) don't have substantial resources and rely heavily on a server to handle most of the workload. In some cases, what appears to be a thick client arrangement can actually be a thin one. For example, a remote desktop application may be hosted on a server or in a virtual PC and simply made available for use on a local PC via a UI.

What's missing from this picture?

Obviously, the examples above leave out a very important aspect of modern distributed architecture – the middle layer. The web is the most obvious example that uses a multi-tiered design. A web server is responsible for displaying static or dynamic content to an end user via a browser. An application server hosts the actual application that is being accessed via the browser. A database server houses all the data delivered, used, and collected by the application. (Bear in mind that the connections and communication between each layer is just as important a part of the architecture as the tiers themselves). Enterprises that want to expose applications to end users outside their company, such as customers, partners and vendors, often choose to use web-based distributed architecture in this way.

Of course, enterprise data may itself be further distributed into multiple databases, creating an even more diverse architecture. Some of the data may reside in a traditional, relational SQL database. Unstructured data may be housed in one or more NoSQL databases, a relatively new option in the data management field. Dan McCreary, author of ‘Making Sense of NoSQL', (coauthored with Ann Kelly) points out that Big Data isn't just changing the face of the database. It will have trickle down effects as well when it comes to enterprise software. "There have been huge innovations in the way we manage large data sets and how this can make developers more agile. I think they are going to have a big impact on the way companies build software in the next 10 years."

When one just isn't enough

With the web-based "as a service" model, some or all of these servers and databases may reside in the cloud. That brings us to the next major aspect of distributed computing – the use of multiple servers. The greatest benefit of using more than one server is that you don't have a single point of failure. In a "peer-to-peer" distributed architecture, each machine can handle any task (although no one machine can handle all tasks at once). The workload is distributed among the servers and rebalanced as needed.

This approach makes the most of the available resources and allows failover to servers that are still running if one node goes down. The data, computing workload and communication can all be distributed, lowering the incidence of bottlenecks that impede performance. This is a highly scalable method of creating a distributed system. It uses less expensive equipment than a single, monolithic server and offers a lot of redundancy for consistent availability of applications.
Whenever multiple servers are required, they may be provisioned on-premise or in a data center. Many enterprises now use a private cloud or hybrid cloud for various aspects of their distributed architecture including the software, platform, or infrastructure.

Distributed architecture frameworks and protocols

Building a distributed system involves many, many different components from APIs and databases to servers and communication networks. At a very zoomed out level, you need a framework for implementing and managing these components such as the currently popular Hadoop. At a zoomed in level, you need methods and rules for actually getting things done at the transaction level. That's often where SOA (Service Oriented Architecture) and its related protocols come into play.

Arnon Rotem-Gal-Oz, Architecture Director at Nice Systems, puts it this way, "SOA is just something that's become a good way to build distributed systems. When you are building a system in frameworks such as .net, you find that a good way to model that and componentize your system while building in flexibility is to build on SOA principles." He points out that it's actually possible to layer SOA on top of frameworks such as Hadoop to garner the benefits of both.
As you can probably tell, the blueprints for the "house" of distributed architecture are getting more and more complex all the time. However, while the features may change, the underlying benefits for enterprise remain remarkably consistent: More computing power, more scalability, more consistency, more availability, more speed, and less overhead.