Programs, life cycles, and laws of software evolution, Modulith First! The appropriate path to microservices, The Microservices Fallacy - Part 9 Moduliths, An Update on the Lock Icon
Top-level managerial pressure to apply life-cycle evaluation is therefore essential if a development and maintenance process is to be attained that continuously achieves, say, desired overall balance between the short- and long-term objectives of the organization. Neglect will inevitably result in a lifetime expenditure on the system that exceeds many times the assessed development cost on the basis of which the system or project was initially authorized.
[…]
The final section of the paper (V. Applied Dynamics) is a case study in how knowledge of these laws can be used to guide longer-term planning processes. Lehman analyses the releases of System X (a general purpose batch operating system) through one by looking at the number of modules added and changed during each release, as a proxy for complexity. By looking at the average number of modules changed per day during a release, it can be seen that releases that push the rate higher tended to be ‘extremely’ troublesome and followed by considerable clean-up. Likewise releases that exceeded the normal incremental baseline of module growth (number of new modules) also tended to leave a poor quality base and need to be followed by a clean-up release. Thus it becomes possible to look at the current rates of change and addition, and make an assessment of the likely underlying quality trends and what what can be accomplished in the near future.
Résumé d’un papier datant de 1980, très agréable à lire, et qui montre bien qu’on a pas fini de lutter à gérer la complexité du développement logiciel. Sur mon projet actuel encore je me bat pour qu’on gère l’obsolescence et qu’on arrête de considérer le développement comme un empilement de code.
Microservices are a great mechanism to ensure modular delimitation in a system over the long term. As an architectural style, however, they do not answer the question of where exactly the demarcation between the individual services works best. Technical, vertical structures and domain-driven design are on everyone's lips, but they also do not represent an easy-to-use panacea for an efficient separation of modules and services. In this article we take a look at approaches that are comparatively objective because they are supported by metrics. At least at the beginning, we rely on a so-called "modulith" because it is easier to measure than distributed systems such as microservices.
Un article qui donne de la matière quel que soit le découpage et découplage de code qu’on vit ! Je pense me servir des métriques pour mesurer le chaos de microservices que je vois en ce moment. Je pense que ça peut servir de bons proxies pour évaluer la qualité du mode d’organisation et d’implémentation de la solution.
If you do not need to go fast and/or do not have multiple teams and do not have very disparate NFRs for different parts of your application, a modulith can be a sensible alternative to microservices. It offers most advantages of microservices like better maintainability and evolvability, team independence and more while not exhibiting the intricacies of microservices at runtime. A modulith is still a deployment monolith, i.e., one of the simplest runtimes architectures available.
A modulith requires advanced functional design skills and strict implementation rigor – two properties that unfortunately are not seen very often in most companies. If you do not have the two skills in your company, most likely you will up with the dreaded big-ball-of-mud-type monolith.
Yet, this is still better than a distributed big ball of mud that you would end up with if you were going for microservices while lacking the two aforementioned skills.
Pas nécessairement l’article le plus auto-portant, mais il donne déjà de quoi penser sur la stratégie modulith (qui en soit ne surprendra pas, mais qui pourrait bien être la mode qui nous sauvera de la précédente). L’article suivant est intéressant également, et donne une autre stratégie d’isolation. Reste tout de même et toujours la façon formaliser le modèle mental pour que le découpage et découplages deviennent évidents, et ça, ça ne viendra pas d’un style d’architecture qui n’a pour but que d’organiser la solution.
For example: we know that the lock icon does not indicate website trustworthiness. We redesigned the lock icon in 2016 after our research showed that many users misunderstood what the icon conveyed. Despite our best efforts, our research in 2021 showed that only 11% of study participants correctly understood the precise meaning of the lock icon. This misunderstanding is not harmless — nearly all phishing sites use HTTPS, and therefore also display the lock icon. Misunderstandings are so pervasive that many organizations, including the FBI, publish explicit guidance that the lock icon is not an indicator of website safety.
Énième exemple que l’UX est cruciale dans le domaine de la sécurité. Chrome dévoile sa prochaine évolution de l’icône verrou de la barre d’adresse.
