COMP 310

Distributed Systems

    Current Home  Java Resources  Eclipse Resources




Server vs. Microservices

[PRELIMINARY DRAFT -- This page is still under construction!   Check back often for updates.]

 There are two common ways in which people see the interconnected pieces of a distributed system (or possibly a hybrid of the two):

All the major cloud service providers now have both server and microservice offerings plus some, e.g. Microsoft Azure, offer services that are positioned between the two ideas. 

The classic example of the "server" architecture viewpoint would be Amazon EC2 virtual servers.    The classic microservice example would be the Google AppEngine Standard Environment.


Pros and Cons

Server architecture:

Microservice architecture:


Servers and Microservices in ChatApp and the Final Project

The following discussion is typically more applicable to the Final Project but technically, is applicable to ChatApp as well.

These projects are designed to introduce the students to a wide range of issues surrounding distributed systems.   The architecture being used in the projects actually involves both server and microservice architectures.

"Game Server"

The Final Project has a well-defined notion of a "game server" but even in ChatApp, the "game server" is really just any message sender that is sending out messages whose type and processing are initially unknown to the message receiver.

Since all the messages associated with a game are known a priori to the game server, internally can treat the commands that process those message as well-known.   That is, all the commands installed on the game server can have intimate access to any shared game state as well as to each other. (Note:  The commands that a game server sends to the game clients are NOT necessarily the same as those installed on the game server itself!)

Thus, the game server application most closely matches the "server" architecture described above.   It is able to gain the advantages of a server without most of the disadvantages because there is only a single game server instance in a typical Final Project implementation.  


 "Game Client"

The Final Project has a well-defined notion of a "game client" but even in ChatApp, the "game client" is really just the receiver of any initially unknown message type.

Since none of the game-specific message types are known a priori to a game client, the game client must treat all game-specific messages as unknown types and thus the commands to process those message types (sourced originally from the game server) are subject to the sandbox created by the ICmd2ModelAdapter.    Each command only processes a single type of messag and are naturally decoupled from each other unless a connection is made through the use of shared data storage (e.g. mixed data dictionary services).   

Thus, the game client application most closely matches the "microservices" architecture described above.   Because every game involves many game clients, it makes sense to take advantage of the scaling advantages of the microservices architecture here.



Synchronization of Distributed Data

Trying to maintain coherent copies of data across a distributed system is a very difficult problem.   While it tempting to simply put all of the shared data onto a single, central server, there are many reasons that this may not be desirable, such as but not limited to:

There are different approaches to solving the problem of synchronizing distributed data

  1. Purely distributed protocols -- each holder of the data acts identically, sending messages to/from each other to come to consensus about the current state of the replicated data.
  2.  Authoritative server protocols -- a single holder defines the current state of the data and all other holders synchronize to that single holder.
  3. Hybrid protocols -- Attempt to gain the advantages of both distributed and authoritative protocols while minimizing the disadvantages.
  4. Controlling server -- a single central server creates and manages all synchronized data. Clients must always access the central server for any operations involving the synchronized data.


There are many systems, both commercial and open-source, that tackle to this very difficult problem of synchronizing data and operations across a distributed system.

Here are a few examples:

  1. RAFT Consensus Algorithm -- distributed process with a "strong leader" notion.
  2. Apache ZooKeeper -- centralized server
  3. PAXOS family of consensus algorithms -- assumes a network of unreliable processors



© 2017 by Stephen Wong