Hands-On Software Engineering with Python
上QQ阅读APP看书,第一时间看更新

Physical architecture

The primary difference between logical and physical architecture documentation is that, while logical architecture's concerns end with identifying functional elements of the system, physical architecture takes an additional step, specifying actual devices that those functional elements execute on. Individual items identified in logical architecture may reside on common devices, physically. Really, the only limitations are the performance and capabilities of the physical device. This means that these different physical architectures are all logically identical; they are all valid ways of implementing the same three-tier web application's logical architecture:

With the current enthusiasm for virtualization, serverless, and cloud-based technologies in the industry, provided by public and private cloud technologies such as Amazon Web Services and VMware, whether a physical architecture specification really is a physical architecture often becomes something of a semantics quibble. While, in some cases, there may not be a single, identifiable physical computer the way there would be if there was a dedicated piece of server hardware, in many cases that distinction is irrelevant. If it acts like a distinct physical server, it can be treated as one for the purposes of defining a physical architecture. In that case, from a documentation standpoint, there is no knowledge value lost in treating a virtual server like a real one.

When considering many serverless elements in a system, several can still be represented as a physical architecture element as well – so long as it acts like a real device from the perspective of how it interacts with the other elements, the representation is adequate. That is, given a hypothetical web application that lives completely in some public cloud, where:

  • That cloud allows serverless functions to be defined
  • Functions will be defined for processing the following, with back-end databases for each of those entities also living in the cloud:
    • Customers
    • Products
    • Orders

A corresponding physical architecture might look something as follows:

 

An example real-world implementation of this serverless architecture can be implemented in all three of the big-name public clouds: Amazon Web Services (AWS), Azure, and Google Cloud Platform (GCP). Each of these public cloud platforms provides virtual server-instances that could serve the website and maybe databases. The processor servers in this structure could use serverless functions (AWS Lambda, or Cloud Functions in Azure and GCP) to drive the interactions between the website and the databases as the website sends events to the functions in the processor elements.

Collectively, logical and physical architecture specifications provide development with at least some of the information needed to be able to interact with non-application tiers. Even if specific credentials will be required but are not supplied in the documentation, knowing, for example, what kind of database drives the data tier of a system defines how that data tier will be accessed.