One of the most formative course I had during my time at Sherbrooke University in Computer Engineering was the static physics CSxxx. Even 20 years later, I remember this course well for two reasons.
First, Canada uses the S.I. units as most of the rest of the world. A Newton is a unit of force, which is defined as m/s². Earth’s gravity is 9.80665 Newton. One Liter of pure water is one Kilogram. It’s generally easy to convert force into motion, calculate the effect of inertia, etc.
The United States uses imperial units. Converting between a Pound force and ft/s² involves constants. There are constants everywhere, and it is very easy to get it wrong. To make the story short, I bought the wrong book: I bought the one where half the exercises used S.I. units … and the other half used imperial units. Fun times.
The second reason is that it provided a wealth of analogies to use as a software developper, even decades later.
A solid material can be described with different measurable properties; fragility, ductility, hardness, electrical conductivity, thermal conductivity, viscosity and others. The same material can have widly different properties based of the way it’s treated. For example steel is ductile, but can become hard, albeit more fragile, by using thermal treatment. Mixing materials change the properties. Adding cooper in aluminium can make it electrically conductive. Its physical form can have a great impact on the properties. With the same weight per meter, a H beam is much stronger than pole. Coating a material may work around issues: galvanized steel ‘stainless steel’ is corrosion proof, that is as long as the cating is not deteriorated. The atomic structure has drastic effect; both graphite and diamond are made of pure carbon, but hare wildly different.
While fragility, hardness and ductility are related, they are subtly different. A very hard and not fragile material exists but it is hard to work with, it is not ductile, and it costs a lot: it’s diamonds. It’s still useful in specific cases, like for saws, but it’s used with parçimonie.
When constructing a sky scrapper or a town house, a simple road or a bridge, civil engineers and architects have to use the right material according to the design constraints. It’s more than just choosing the ‘best’ materials.
Some constraints are internal to the project itself. Is it an earthquake-prone location? Is the ground made of rock or sand? What are the regulations? An ancestral house nearby may constrain a construction to be made of specific types of materials. Are the materials cheap enough or is there a cheaper alternative? What’s the temperature variations at this location? Is it close to the sea, increasing risks of corrosion? What’s the weight per square meter that the structure has to sustain? An hospital floor must sustain much more weight than a normal house.
These questions are important. Construction quality wood is cheap in most parts of the world and is not fragile, but is not very hard. There’s a limit of how many stories a building can be made out of wood. We generally do not construct a multi-level parking lot out of wood, but one can be surprised. Concrete is hard but it is fragile. Using concrete in an earthquake-prone area must be done with care, the wood house has an higher chance of not imploding during an earthquake. Putting steel bars into concrete makes it both harder, and less fragile. Steel is useful for a bridge as it is not fragile, but will be affected by corrosion unless treated. It also has to be well placed, and not in a tapon. The inspectors have to audit on-site, at the exact moment concrete is poured, otherwise it’s too late and no one knows if the job was well done.
Some constraints are external. Can the materials be sourced on time? Is there a trade war, limiting the available choices? Maybe using a mixture of different materials, especially for large projects, may mean better availability, as each type of material is required in smaller quantities, enabling to source from more providers. Are the engineers, architects, and construction workers familiar with these materials and how to use them?
Some contraints are due to planning of sequential events. A good example is that when the new Champlain bridge connecting Montréal to its South shore was being constructed, they had planned to store 50 tons steel beams on the South shore, as there were more storing place available. Some of the beams were needed on the North shore, and it was planned to move these by using the old bridge using large trucks. The problem is that the old bridge deteriorated faster than expected, it became fragile, and once it was time to drive the heavy beams across the old bridge, it was deemed too dangerous. They had to fallback to using boats, which was significantly costlier and caused delays.
Some contraints are forward looking. Maybe the evolution of the construction is taken in account? A good example is again a bridge. They are generally now designed to be easier to repair or replace in incremental part. They are made so one way can be replaced at a time, reducing available traffic by half instead of completely shutting it off. A good counter example of home improvement is a castle. It is tricky to retrofit with restrooms (!) or safely wire electricity through stone walls. On the other hand, nobody wants to pay 30% more to strenghten a house just in case someone (likely the next owner anyway) would want to add a second floor to make it a two story house; but many self-constructors pass extra cables in walls ‘just in case’.
During the course, one team exercise was to construct an pylon (the kind used to transport electricity) using a selection of different beam lengths and materials, each with a specific price. The goal was to construct the pylon at the cheapest price, while having a structure that sustains the specified weight and wind force. This was a pure optimization problem, which could have been solved by brute force, but instead we assigned one team member to do it (Sorry JOECHOSE!).
In practice, there’s generally hardly a single perfect answer, and instead a delicate mix of hard data and experience. Sometimes there is a perfect ‘design’, but calculating it would be impractical due to time or cost constraints and a good enough one does the job.
Similar to a civil engineer designing infrastructure, selecting the right software foundation for a project requires careful thoughts. By software foundation, I mean the languages used to develop the project for both the client and server sides, the frameworks used, the software leveraged, the service providers, the physical location(s) of the hosting.
As an engineer, computer languages, software frameworks and services have to be evaluated and knowledge must be gathered on each alternative to find the best fit for a specific project. Experience helps. As with physical construction, planning is crucial, otherwise you may find yourself to have to tear down the building one year into the project and construct a new one from scratch. Oops!
How to measure the appropriateness of your software material? Leveraging the physical properties, we can get meaningful answers!
I use the analogy of fragility for availability. An available service is a service that doesn’t have a single point of failure. Airplanes are more available than cars, as they duplicate key components. A car has a single fuel tank, an airplane has two. Spaceships are more available than airplanes, using three copies of the same hardware for redundancy for key elements. There’s cost associated, a spaceship is more expensive than an airplane, which is more expensive than a car.
In the software world, a good example is that one of the server node can be turned down, without visible impact on the users. An available service has redundancy. A cost efficient available service does it in a way that split the workload across each node, instead of duplicating work like a spaceship does. An high-availability database may err on the side of duplication instead of effeciency for various reasons. In the physical world, a bridge that can be repaired and traffic redirected in one of the reverse lane is available, instead of completely cutting the traffic off, it still allows traffic to goes through at half the throughput.
I use the analogy of hardness for reliability. A reliable service is measured in uptime, number of nines. A 99.999 service can only be inaccessible for 5.25 minutes per year. That’s not a lot. As much as a XX saw is made of diamonds, a reliable service is, well, made of great routing logic, fallbacks and exponential backoff by the clients.
One can approximate a reliable service by making it fail gracefully. A famous example is Netflix which supports partial degradation. It makes the service, as seen externally, harder by putting steel bars in the concrete. Sometimes the recommandations fail, but the user will have a user experience that still mostly meet their needs.
This is different to an available service at reduced throughput, a partially available reliable service has reduced functionality.
I use the analogy of ductility for refactoribility. There’s two close concepts related: refactoribility, which is how easy it is to refactor a code base without breaking it, and future-proofing which is how safe it is to extend the software in new unforeseen ways.
A good example is NoSQL tables versus schema-based databases. A NoSQL can be refactored, but it is at a cost of unclean data. A schema based table is safer and stricter, but doing schema upgrades are disruptive. Similar to a bridge, a castle or an overdesigned house, it is important to choose the right level, so that one can have enough flexibility, without paying too much upfront.
I use the analogy of corrosion for security. While concrete can be poured over steel bars to make the concrete less fragile, it is very hard to assess when the steel bars become corroded, because they are not visible, and most sensing tools fail to read through concrete. Because the steel bars are sealed inside the concrete and invisible, only very specialized (read: expensive) tools can help get an approximative measurement of the degradation level over the years. It is very hard to diagnose. Corrosion is a chemical attack. Rust is the result of the attack. Eventually, a bystander may spot rust forming at the surface of the conrete, but it’s often too late at this point. There’s no guarantee that the bystander will notify the authorities, stakeholder must be proactive.
Same goes for a secure foundation. Audit is needed to assess the security boundaries, but that only work for visible actions. How to improve visibility? By reducting state changes, and limiting what the service is allowed to do and for how long. Containment and statelessness (what people call serverless) help here. It is really a case of less is more. Bug bounties may help, but are not sufficient alone.
I use the analogy of electrical conductivity for latency. Some services are fine with 500ms RPCs, others must draw a frame every 16ms. Intuitively, the more lightweight, the leaner, the faster but this can go at odds. For some low latency requirement, the system must be complex. Running a web search engine is anything but light. The holy grail of supra conductivity at room temperature is not yet found, similarly not everyone can create a database requiring an atomic clocks.
Dynamic language engines and JIT VMs pay a start up cost that is generally higher than statically compiled languages.
I use the analogy of sourceability for dependendable software foundation. Is the framework or software vendor still there in 5 years? Are they using semver or are pushing breaking changes along minor version update?
Service provider come and go. Some were ornament, they are easy to replace. Some were structural piece, thus harder to replace. When choosing each, think about the switching cost in case of abrupt failure. Maybe use multiple service providers?
Many projects start with a single homed SQL database on a single purpose server, on a fast local network. Leveraging the analogy again, a long time after being built, a building may be extended or retrofitted. The service may need to grow, or support new use cases. The assumption about unlimited LAN bandwidth may not hold anymore.
A single homed mariadb instance is fragile, hard and slightly ductile. I could be corroded without noticing. It never fails and very reliable when it runs alone on a large host, but when it fails, it fails hard. Just like a poorly designed concrete building fails upon an earthquake.
In the software world, things go much faster and retroffitting may have to be done after a handful of years, if not months. An initial project that looked disposable may require a lot of follow up work. That said, similarly the vast majority of projects will never need to scale more than a single server.
This cannot be overstated: build for the project’s needs.
In the end, I didn’t keep the book, but I kept the learnings.