Fielding, Fowler and Haussmann

Network-based architectures: What Parisian history can teach us

Eric Horesnyi
Paris image via Shutterstock

For all the great strides that IT is taking to bring us to better futures faster, it turns out that everything we need to know about high-performance system architecture can be learned from the history of urban Paris.

As developer or architect, we often have to communicate fine concepts of network or system architecture to “decision-makers”. In my case, I have been using the smart city analogy for twenty years. And to celebrate the 25th birthday of the Web, I propose to draw an analogy in depth between a designed city, Paris and the Web.

Going through Fielding’s thesis, we will compare Paris to the Web in terms of constraints, inherited features, architectural style choices and finally assess whether these choices meet the objectives. All these with a focus on a transformational period of Paris: 1853–1869 under Haussmann as Architect, with an approach worth applying to the many large corporate information systems looking to adopt a microservice style, as proposed by Fowler and Newman.

Here are the first two episodes out of seven that we will cover during the session at the upcoming JAX London. Our audience is, by design, either software experts interested in city architecture to illustrate the beauty of HTTP Rest and Continuous Delivery, or anybody wanting to understand the success of the Web, and get acquainted to key web lingos and concepts.

Who was Haussmann, and his challenge for Paris?

1 220px-Haussmann_BNF_Gallica

Eugene Hausmann

Eugene Haussmann was a civil servant chosen by Napoleon III to accelerate the modernisation of Paris in 1853. He reigned over Paris architecture for sixteen years. When he took office, Paris UX was awful, probably worth less than a star on the Play or Apple store: high dropout rate (cholera stroke every five years with 10,000 dead each time), servers (houses) were congested (up to 1 person per square metre – US translation: 100 people per townhouse floor), and datacentres would work only intermittently: no power (gas, water), no cooling (sewage). No cache (cellar), no proxy (concierge), no streaming (subway) … a UX nightmare.

2 cholera

19,000 deaths of Cholera in 1832

Outside was even worse: ridden with cybercrime (you get it) in obscure streets, slow with narrow access lines (streets) and non-existent backbones (boulevards), without a shared protocol for polling traffic (sidewalk for pedestrians) or streaming (subway), and no garbage collection (gotcha).

Worse, when a user would go from one page to another, TLP was terrible because of these congested un-protocoled lines, but they would come home with viruses by lack of continuous delivery of patches to the servers (air circulation and sun down these narrow streets hidden by overly high buildings).


Congested servers, crowded apartments in Paris

To top it off, service was fully interrupted and redesigned regularly (Revolutions in 1789, 1815, three Glorieuses in 1830, 1848), without backward compatibility. Although users would benefit from these changes on the long run, they definitely did not appreciate the long period of adaptation to the new UI, not to mention calls and escalations to non-existent service desk (votes for poor and women). Well, actually, these small access lines made it easy to build DDOS attacks (barricades), a feature the business people did not like (Napoleon III).

Pre-Haussmannian street in Paris, unsafe, ridden with viruses, no cooling

Pre-Haussmannian street in Paris, unsafe, ridden with viruses, no cooling

Some elements of style that Haussmann ultimately selected were actually imposed upon him by his boss, Napoleon III, nephew of Napoleon. My intention here is definitely not to write an apology of Napoleon who spread war for years across Europe, just to point to one feature he introduced in the Process: the Code Civil. The Code Civil details the way people can interact together, things they can do and can’t. It came out of heated debates during the French Revolution. Its publication had an impact similar to the CERN initial paper on HTTP in 1990. Code Civil rules citizens life the same way HTTP is the protocol governing our exchanges on the Web.

A fundamental principle in the Code Civil is the separation of concern: it defines what is a citizen (Client), and separates its interests and interaction from companies, associations and the state (servers .com, .org or .gov). Any mixing of interest is unlawful (misuse of social assets), pretty much like HTTP is by design Client Server and Stateless. This also means that a server cannot treat two clients differently (equality), or two servers unequally (this links to the current debate on Net Neutrality):

  • Client-Server: the most fundamental concept allowing for a network-based architecture: the system is considered as a set of services provided by servers (shops, public infrastructure services, associations) to clients (citizens). Once roles and possible interactions are defined, each can evolve independently: a citizen can grow from student to shop-owners, a grocery store to a juice provider. People living in a building are not forced to buy their meat from the store in the same building, and a store-owner may practice whatever price he wants. This principle of separation of concern allows for citizens freedom to choose, and for entrepreneurial spirit (ability to create, invest, adapt) to service citizens (with food, entertainment, social bonds through associations or culture).
  • Stateless: no session state, request from client to server must contain all necessary information for server to process. Whoever the citizen, the server must serve him without knowing more about him than other citizen. No mixing of genres is allowed between client and server: all citizens are treated equal, and must be serviced the same way for a same request. Citizens cannot be bound to a single service by services creating dependencies or local monopoly over their services. This separation of concerns from one building to another, and one person to a company is a foundation of citizen life even today (usually).

The DNS scheme of Paris

Another feature Haussmann had to take into consideration was the addressing scheme of Paris, defined in 1805, similar to our DNS scheme used for HTTP requests:

  • The main backbone, la Seine, defines the start of every street (our root)
  • Each association (.org), state organisation (.gov) and company (.com) can define its scheme within its own domain

    Wanting to build on Code Civil/HTTP, Napoleon III ego did not tolerate for his capital city be less civilised than London or emerging New York.

    In terms of performance, his network-based architecture needed to do the job on:

    • Network (streets) performance: throughput (fast pedestrians and carriages), small overhead (no need for a citizen to walk the street with a policeman to protect himself), bandwidth (wide street)
    • User-perceived performance: latency (ability to quickly reach ground floor of buildings), and completion (get business done)
    • Network-efficiency: best way to be efficient is to avoid using the street too much. Examples are homeworking (differential data) and news or music kiosks avoiding to hear music only in the Opera or get news from Le Monde headquarter (cache)

    As Fielding, he would also select his architectural style against the following metrics:

    1. Scalable: make it possible for Paris to grow
    2. Simple: citizens, civil servants and visitors would need to understand the way the city worked without a user manual,
    3. Modifiable: ability to evolve in the future through change
    4. Extensible: add new neighbourhood without impacting the system
    5. Customizable: specialize a building without impacting others
    6. Configurable: easily modify a building (component) after construction (post-deployment)
    7. Reusable: a building hosting an accounting firm one day can serve as creamery the next
    8. Visible: to provide best security and auditability of the system, interactions between components needed to be visible (people should see each other in the street)
    9. Portable: style should work well in other regions, with other materials and weather conditions
    10. Reliable: susceptible to failure (no single event could stop water, gas or circulation for citizens)
    Low-entry barrier for citizens, Montmartre example of a popular neighbourhood in Paris

    Low-entry barrier for citizens, Montmartre example of a popular neighbourhood in Paris

    Looking into the challenges he wanted to address in Paris through his architectural style, Haussmann weighted each of these properties for his evaluation criteria. The main objectives appeared to be:

    • Low entry-barrier: citizens are not forced to live in Paris, and Haussmann wanted to provide them best possible UX to increase adoption. A citizen needed to be able to simply find an address, and a builder to publish a new reference, allowing for the creation of an initial system very quickly.
    • Extensibility: a low-entry barrier would help create the modern community Haussmann wanted, and in the long-term, Paris needed to be ready for changes in its style to adapt to new technologies.
    • Distributed hypermedia: Paris needed to provide citizens with life experience ranging from music (Opera and kiosk), films (actually theatres), ecommerce (food from les Halles) and health (parks). All these experiences were rich in content and would attract many citizens, so much so that they needed to be distributed across the city.
    • Anarchic scalability: once the first set of new neighbourhoods would be in place, the city could grow in one direction or another, at a very large scale, without the need for a centralized control (anarchy) to ensure integrity of the entire system. This required for each building to ensure its own authentication, and be able to inspect incoming traffic through firewalls (double door, concierge).
    • Independent deployment: each server (building) or application (neighbourhood) could be deployed independently from the others, without compromising the system. Legacy systems (older neighbourhoods that could/should not be changed, eg. Notre Dame de Paris) needed to be easily encapsulated to interact and be part of the entire system.
    Eric Horesnyi
    Eric was a founding team member at Internet Way (French B2B ISP, sold to UUnet) then Radianz (Global Finance Cloud, sold to BT). He is a High Frequency Trading infrastructure expert, passionate about Fintech and Cleantech. Eric looks after 3 bozons and has worked in San Francisco, NYC, Mexico and now Paris.

    Inline Feedbacks
    View all comments