In his seminal essay, “Five Points Toward a New Architecture” (Les Cinq Points d’une Architecture Nouvelle, 1927), the Swiss-born architect, Le Corbusier, established five points of architecture. In doing so, he created an architectural philosophy that continues to influence designers today.
Based on his belief that a house was a “machine for living,” each point is intended to serve a purpose, ultimately creating an environment that meets its occupants’ need for space, flow and comfort. In effect, the floors, walls and ceilings are not there to contain its occupants; instead, they serve as the platform for individuals to move about and make the most out of their lives.
Free Façade, Ribbon Windows, Roof Garden, Piloti. Image “The Villa Savoye in Poissy” by Valueyou licensed under CC BY-SA 3.0)
Better Cloud Living
At first, this concept may not seem relatable to cloud architecture. However, one can see the overlap when thinking metaphorically:
- The Application as the house
- Underlying process as its occupants
The workload (infrastructure, application, UI and database) enhances this analogy and serve as aspects that accommodate process and scale – similar to the relationship between the house in Le Corbusier’s model and its occupants.
Five Points of Cloud-Native Architecture
Within this context, it is possible to extrapolate the Five Points and translate them into cloud-native architecture concepts that can inspire the design of modern applications and cloud infrastructures. In the same way that architects must ask themselves how to design a house that doesn’t constrain its occupants, a software architect is faced with the challenge of building an application that will scale with demand.
In this paper, we explore the parallel between Le Corbusier’s Five Points and those for developing cloud-native architecture.
|Le Corbusier’s Points|
1. The Pilotis
2. The Flat Roof
3. The Open Plan
4. The Ribbon Windows
5. The Free Façade
|Cloud Architecture Equivalents|
5. User interface
Five Points, Two Contexts
1. The Pilotis
The concept behind the pilotis, Le Corbusier’s first point, is to create usable space below the structure by elevating the house off the ground with pillars called pilotis. As you will see in the other points, this element is potentially the most important of the five points since, without it, none of the other space-liberating aspects would be as impactful. It lays the foundation (no pun intended) for a modular and flexible environment.
First point of a Cloud-Native Architecture: Decoupling
In the context of software architecture, the new generation of cloud-native applications requires separation between the process and the underlying software and hardware platforms, just as the new architecture breaks the coupling between the structure and the ground.
The application’s ability to execute a process must survive changes to the underlying infrastructure on which that process runs. This freedom is best achieved through decoupling, the first point of a cloud-native architecture.
In the past, software engineers had the luxury of developing applications designed for a hardware platform. Many aspects of the application depended directly on not only the hardware architecture but also on how it was configured. If the hardware changed, the application could break.
Today, we’ve achieved such a level of commoditization of the hardware platform (or Infrastructure-as-a-Service – IaaS) that we can rarely dictate the hardware configuration on which our application will run. When designing an application, we must assume that the underlying infrastructure will evolve and our application must be able to cope with this evolution.
The rapid rate of adoption of container technology, which allows applications to be moved across environments and underlying infrastructures in a mostly transparent way, leaves little doubt about this path. Containers play an important role in solving the need to decouple the application from the infrastructure, and they will become a more prevalent element of cloud-native environments.
2. The Flat Roof
The pilotis-based design makes it possible to build a reinforced concrete flat roof. This allows the living areas to extend to the top of the structure.
However, this roof design requires an element of knowledge (the precise calculation of the load borne by each piloti) and protection (coverage of the concrete with plants for weather proofing).
Second Point of a Cloud-Native Architecture: Robustness
Similarly, cloud-native applications require an element of knowledge (visibility) and protection (fault tolerance and recovery).
As applications moved to the cloud and their functions are distributed, each service becomes a potential point of failure. Additionally, the dispersion of resources across the cloud introduces an element of variability due to cloud latency. This is opposite of monolithic environments, where all processes are local and the performance of the entire application – good or bad – rarely depends on extraneous dependencies.
In the context of a cloud-native application, Robustness, the second point of a cloud-native architecture, includes visibility into dependencies and protection against failure:
- Visibility: Micro-segmentation requires document dependencies so the application can operate. Moreover, components must be monitored individually for performance and availability to ensure the end-to-end success of the application.
- Protection: failure of a single component must be contained, and the entire application must recover from that failure. Services must be redundant and able to auto-recover gracefully, while the application that depends on these services must handle any intermittency without major impact.
A cloud-native application relies on the full visibility of dependencies and must recover from intermittency of these services gracefully.
3. The Open Floorplan
Another benefit of a pilotis-based design is that supports are reduced to finite, minimal elements instead of entire walls. These, in turn, become modular elements which can be freely placed and replaced within the structure to define various floor plan layouts.
Third Point of a Cloud-Native Architecture: Statelessness
When translating this principle to software architecture, we can think of the application as the structure and the session state the layout. The same state (layout) must persist across different instances (structures) of the application, unbound from any single instance and reproducible across all instances. The application does not “own” the state of a session; it takes on a state as needed to deliver session continuity across different instances. This brings us to the third point of a cloud-native architecture: Statelessness.
4. The Ribbon Windows
By creating windows, the extension through the entire façade, the architect provides every room an equal opportunity to be naturally lit.
Fourth Point of a Cloud-Native Architecture: API First
This principle is about “access.” Similarly, to how the ribbon windows give every room access to natural light, in a cloud-native architecture processes are distributed onto a micro-service framework that can provide access to and from such services.
This principle is accomplished via an API-first architecture, the fourth point of a cloud-native architecture, where every process is abstracted as an input, an operation and an output accessible via the API service. By doing so, any element of the application that requires operation has access to the best-suited micro-service.
5. The Free Façade
In a structure built on piloti, the building’s façade does not play a structural role. By doing so, it maintains its independence from the interior structure and consequently, it can be freely designed.
Fifth Point of a Cloud-Native Architecture: Free UI
The façade is the most obviously visible component of a building, just as the user interface (UI) is the most visible component of a software application.
With the pervasiveness of computing, especially mobility platforms, the UI must be adaptable to a plethora of form factors (e.g. phone, tablet). In addition, micro-services-based architectures essentially transform an application into the “patching” of various services that are exposed to the user via a single interface. Which services are exposed depends on the persona of the user for whom the UI was intended.
Much like a free façade, the UI must be an independent entity, taking multiple forms as deemed appropriate. This principle, only possible through the distributed nature of a cloud-native architecture, is the Free UI, the fifth step of a cloud-native architecture.
The UI is an independent entity that takes multiple forms according to the user persona and exposes API functionality as needed to provide the most appropriate user experience.
As we see in the Le Corbusier’s Five Points, there is a common thread that permeates the entire articulation of a modern design: the structure is decoupled from the form and the function of a building, giving the architect freedom to adapt the design to the different needs of its occupants.
This basic principle is conspicuously like the nature of cloud architecture: distributed systems that can be moved across pieces of infrastructure (decoupling) so they can be scaled to fit its users’ needs.
While techniques evolve quickly as new technologies are developed, principles last much longer and create a lasting impact on the works architects and engineers – especially when they are as forward thinking as the Five Points. It is nearly 100 years since Le Corbusier’s 1927 manifesto and his impact is still visible today. Hopefully, our Five Points of Cloud-Native Architecture will have similar longevity, influencing cloud architects along the way.
“Five Points Toward a New Architecture” by Le Corbusier is reprinted from Programs and Manifestos in Twentieth Century Architecture. Copyright ©1970 MIT Press.
“Migrating to Cloud-Native Application Architectures” by Matt Stine, O’Reilly Media, 2015