This post is part of an ongoing series that explains IT concepts for business leaders. Some key concepts in this article are explained in the previous Distributed Systems Primer article.
With technology increasingly becoming a powerful differentiator, many business leaders are engaging with their IT leaders to understand how technology can better meet their business needs. This means having a foundational understanding of how software and system architectures work. But it also means understanding how decisions about selecting the right architecture can impact the desired business application or system and its flexibility, scalability, and usability.
This article provides the needed context so that business leaders can navigate that conversation. It is particularly applicable to conversations with software architects about understanding, deploying, and managing distributed cloud native systems.
As my earlier article explained, distributed systems are complex and must be properly organized. Two important organization concepts that we must first discuss are software architecture and system architecture.
Software architecture is the organization of a distributed system into key software components. Instead of a single, giant application, distributed systems are broken down into many components. How this architectural pattern is achieved can affect system performance, response latency, and reliability.
System architecture is the placement of these components on physical machines. They can be either co-located or located on separate machines. Where they are placed will impact performance and reliability.
The architectural style that is chosen will determine how components are connected, data is exchanged, and how the system works together.
Let’s take a deeper dive into each concept and how they can help achieve good architecture.
What is software architecture?
Distributed systems can be designed in many different software architectural styles: object-based architectures, layered architectures, service-oriented architectures (SOAs), RESTful architectures, pub/sub architects, etc. The style chosen depends on the functional requirements of the applications. Furthermore, as you build more complex, interconnected software systems your distributed system will only grow in size. So it’s important to ensure that processes across these systems, such as communication, are streamlined and simplified.
Let’s consider the quality attributes of each of your software architecture options.
1. Understanding layered architecture
In this architecture of a software, components are organized in layers. Those on a higher layer make downcalls to the lower layer. Components on the lower layer make upcalls to the higher layer, but only typically respond to requests from the higher layer.
Google Drive and Google Docs are a useful example of a layered architecture. At the interface layer you request the latest document on Google Drive. The processing layer processes your request and asks for information from the data layer. That data layer is where your file (known as persistent data) is stored and gives access to higher level layers.
From here, the data layer returns the information to the processing layer which then sends it to the interface for you to view and edit your file.
It can feel like a cohesive process, but is broken down into three components across three distinct layers. Each of these layers may or may not be located on a different server.
Simplified organization of a Google Drive/Doc view request
2. Understanding object-oriented, service-oriented architectures, microservices, and mesh architectures
These architectures are more loosely organized and represent an evolutionary sequence. While all are grouped here, it’s important to know that object-oriented architectures aren’t in fact an architectural style but a programming methodology. Object-oriented architectures make (SOAs) and microservices possible.
Object-oriented architectural styles
This programming methodology is often used when dealing with monolithic apps where logical components are grouped as objects. It helps organize functionality and manage the complexity inherent to monolithic apps.
The object’s state is the term for the encapsulated data set within each object. The operations performed on that data is known as the object’s method.
While each object is distinguishable, they are highly interconnected through procedure call mechanisms. An object will call another object during a procedure with specific requests.
Object-based architectural style
Service-oriented architectures
Services are independent, self-contained objects that make use of other services. Messages sent to each interface ensure communication over the network.
Microservices
The next step in the evolution of software architectures are microservices. These are smaller than the services in a SOA, are less tightly coupled, and are more lightweight.
The big benefit of microservices is that they speed time to market of business applications.
How? SOAs require developers to design and map all interactions and interfaces before an application can be deployed to users. This process can take months. Microservices, however, are independent. So developers can release updates without worrying about the underlying architecture they can also use any software programming language – which can further speed the application delivery time.
Mesh architectures
These are formed by processes or services that run on nodes that can’t easily be accounted for. They can connect and disconnect often using peer-to-peer connections and may not use the internet. Examples of mesh architectures include TOR, p2p messengers, torrents, and blockchain.
Mesh architectures are beneficial because the interacting services and processes are more uniform – unlike traditional architectures where there are dozens of non-uniform services. Just one or even a few service types may participate in a mesh network and each is equally trustworthy or untrustworthy from a security perspective.
Mesh architectures also place greater emphasis on their distributed design. This means they stay efficient even in unstable environments where connectivity can easily lapse between components. Some components may not even connect directly but communicate over multiple hops using other system elements.
Clearly, there’s an evolutionary path across each of the software architectures from the earliest object-oriented programming technologies. But this methodology still has a role to play. Object-oriented just refers to the separation of blocks inside a monolithic system or application. It’s a methodology that is still used today even as object-oriented microservices.
3. Understanding REST or RESTful architectures
REST architectures are a key characteristic of the web (also known as a web-native architecture). It’s a distributed system characterized by a massive collection of resources that are each managed by components. These resources understand a limited set of commands, have only one naming scheme (URL-based), their interfaces follow the same conventions and semantics, and messages are fully self-described. After an operation is executed on a resource, it forgets everything about that call from the client except for the resulting changes in service state - called stateless execution.
Commands and interface specifications are highly restricted because the internet is made up of vastly diverse systems that need to communicate. When interfaces are standardized and commands are reduced, it becomes much easier to develop compatible systems. A URL is a descriptive resource address that gives developers enough flexibility to express everything they need. For example, the command here:
HTTP GET http://amazon.com/shoppingcart/546/items/98765
is a command to request items “98765” from shopping cart “546”. All the details needed are contained in the URL.
4. Public-subscribe architectures
Also known as pub/sub, this architecture is a very loosely coupled architecture that allows processes to easily join or leave. What distinguishes pub/sub architectures is how services communicate. Instead of services calling and getting a response, they send one-way, typically asynchronous messages to a non-specific receiver who may be an administrator, configurator, or developer (who can also choose to sign-up to receive messages).
It’s a process you may be familiar with. It’s how people receive breaking news push notifications from CNN, for instance. Each time a news item is categorized as breaking news all subscribers receive the update.
In this way, pub/sub has most relevance for mobile applications where network reliability can be an issue. If there’s a network issue, you’ll simply get the update later when service is renewed.
What are system architectures?
Decisions about system architecture must be made to ensure the proper placement of specific software components. For example, should certain components reside together on the same or different machines? Organizations may also have high-speed processing servers or a certain storage facility that they prefer to use for certain components.
These architectural analysis decisions will define different types of architectural organizations and can be categorized as centralized and decentralized organizations.
1. Centralized organizations
A server is a system that implements a service, such as a database service. A client requests that service from the server and waits for a reply (request-reply behavior). These processes may be physically distributed which can lead to different multitiered architectural styles.
There are several ways to distribute a client-server app across machines. The simplest is to use two types of machines: a client machine with the user interface (layer one) and the server interface that contains the program implementing the process and the data (layers two and three). Everything is handled by the server, the client is a dumb terminal. This is known as a (physically) two-tiered architecture.
Other ways to separate these three layers in both machines include separation to having everything except the stored data running on the client – see below:
Variations of physically two-tiered three-layered architectures
Now in a three-tiered architecture the application is spread across one client and two servers. One of the servers must act as the client.
Three-tier architecture: one client and two servers with the app server also acting as a client.
2. Decentralized organizations
Today’s modern architectures are characterized by distributed clients and servers (horizontal distribution). Although physically apart, each part operates with a share of complete data thus balancing the load. Rather than have a single data store that all components can access, a potential bottleneck, each component has its own dataset – these are called peer-to-peer systems and are connected via an overlay network. Each process acts simultaneously as client and server, often referred to as servant.
Peer-to-peer system network connected via an overlay network.
Conclusion
There are many ways to organize applications into logical components including layered software architectures, SOAs, REST, or pub/sub. Which is best depends on the application. Considerations about system architecture informs which components are placed on different physical machines whether in a client-server or peer-to-peer approach.
A big thanks to Oleg Chunikhin who was instrumental in getting all technical details right. And to Evgeny Pishnyuk who also provided valuable feedback.