You know, I'm pretty sure you could build a PHP monolith in 2023 without a framework and it would do what it needed to do.
Monoliths are not dinosaurs
11–20 of 243 posts
Re: Monoliths are not dinosaurs
#12Earlier quoted context omitted.
> Aka don't fall prey to Conway's law You can't not fall prey to Conway's law. You can only choose how you organize your people and their interfaces.
Right! Decide on the shape of the software, then rearrange your organization to match.
This is probably good advice for CTOs and directors who manage software products, but it seems to imply the rest of us have to make software that already matches the political structure.
Re: Monoliths are not dinosaurs
#13You know, I'm pretty sure you could build a PHP monolith in 2023 without a framework and it would do what it needed to do.
Bad coding is infinitely worse than a “bad” language.
I don’t know how many of you are musicians, but many people are surprised to find that the tone quality of a guitar has way more to do with the person playing it than the way it was built.
Re: Monoliths are not dinosaurs
#14Cloud computing is not a religion could be another good title
Re: Monoliths are not dinosaurs
#15Werner's advice in my own words: 1. Don't pick an architecture because it's all the rage right now. 2. Don't pick an architecture that mimics your org's structure. Aka don't fall prey to Conway's law: https://en.wikipedia.org/wiki/Conway%27s_law . 3. Don't pick an architecture that your team can't operationalize--e.g. due to lack of skills or due to business constraints.
(Some of) Werner's advice in his own words (from the linked article): * "I always urge builders to consider the evolution of their systems over time and make sure the foundation is such that you can change and expand them with the minimum number of dependencies." * "There are few one-way doors. Evaluating your systems regularly is as important, if not more so, than building them in the first place."
> Evaluating your systems regularly is as important, if not more so, than building them in the first place.
This is useful advice to people who can make high level org decisions. But they don’t necessarily know what’s going on at a software level.
The people who do know what’s going on often have a very hard time getting buy in for refactoring. Many of them (rightfully) conclude it’s better to just make management happy churning out features.
Re: Monoliths are not dinosaurs
#16Werner's advice in my own words: 1. Don't pick an architecture because it's all the rage right now. 2. Don't pick an architecture that mimics your org's structure. Aka don't fall prey to Conway's law: https://en.wikipedia.org/wiki/Conway%27s_law . 3. Don't pick an architecture that your team can't operationalize--e.g. due to lack of skills or due to business constraints.
> Aka don't fall prey to Conway's law You can't not fall prey to Conway's law. You can only choose how you organize your people and their interfaces.
You can't do either. How a system is structured drives how the organization running it is structured; how an organization running a system is structured drives how the system is structured.
This is natural and even beneficial: it reduces communication and coordination costs, which is the costliest and hardest part of any organization or system. Perhaps that sometimes lands you in a suboptimal local minimum, but escaping that is usually quite costly in the short term. Think about how often top-down reorgs actually generate value.
Re: Monoliths are not dinosaurs
#17Earlier quoted context omitted.
Right! Decide on the shape of the software, then rearrange your organization to match.
This is probably good advice for CTOs and directors who manage software products, but it seems to imply the rest of us have to make software that already matches the political structure.
Another way of saying that is to be strategic about where you go against the grain of the organization. I’ve seen that work well when it was something important where the value was high and poorly when someone was either just being dogmatic or overestimated their ability to negotiate.
A long time ago I remember hearing a good bit of advice that for a new project you should innovate the product or the tech stack but not both. I think this is similar: unless you have a lot of resources (people + political clout), don’t buck the existing org chart in more than one area if you can avoid it.
Re: Monoliths are not dinosaurs
#18Like most articles in distributed systems, this makes wild assumptions about the most important, i.e. the human layer. I would bet $100 that this is written by the same sort of person who thinks "Managers – what do they do all day exactly?" [1]
> If you hire the best engineers....
Guess what, there is no broad consensus on what "best engineer" means. I bet your org is rejecting really good engineers right now because they don't know what Kubernetes is. Same goes for literally any other technology that has been part of a hype cycle (Java in 2001, Ruby on Rails in 2011, ML in 2011; no the precise years don't matter).
> ...trust them to make the best decisions.
A lot of work encapsulated there in less than ten words. If you hire a bunch of people and tell them "you are the best", you think they are going to sit around and run the Raft protocol for consensus on deciding how to architect the system? No, each of them is going to reinvent Kubernetes, and likely not in an amazing way.
Microservices are often best deployed when there is a mixture of cultural and engineering factors that makes it easy to split up a system into different parts that have interfaces with each other. It has little to do with the superiority of the technical architecture.
----------------------------------------
[1] Looks like the article was written by the CTO of Amazon, which...surprises me a bit. Then again, from all accounts, Amazon's not exactly known as the best place to work; so maybe I'm right? In any case, anything written by Amazon is not directly applicable to the vast majority of small-to-medium companies.
Re: Monoliths are not dinosaurs
#19Like most articles in distributed systems, this makes wild assumptions about the most important, i.e. the human layer. I would bet $100 that this is written by the same sort of person who thinks "Managers – what do they do all day exactly?" [1] > If you hire the best engineers.... Guess what, there is no broad consensus on what "best engineer" means. I bet your org is rejecting really good engineers right now because…
[deleted]
Re: Monoliths are not dinosaurs
#20You know, I'm pretty sure you could build a PHP monolith in 2023 without a framework and it would do what it needed to do.
Can confirm. judyrecords is built on a near framework-less monolith in PHP + 2 search servers. Searches complete within 100 milliseconds and SRPs return in less than 15 milliseconds on average. Runs a trimmed down version of CodeIgniter 2 (released in 2012) updated to run on PHP 8.2. Still got the CI 2 profiler.