Great article. I appreciate the recognition that there are other software- development models which may make more sense for specific scenarios. Some projects do not need 99.999% uptime if it's going to double the cost, and some do.
The name "mono-environment" might be misleading for some, as "mono" might be understood to mean that there is only one environment in total.
The practice of "development-in-production" is becoming increasingly rare but it is worth mentioning. That would be where there is no separate development environment at all. I'm not recommending it in 2026! This method is sometimes chosen because the cost of setting up a development environment that is a good match with production is too high. Similar to what the article says about the downsides of staging, sometimes the cost of creating and maintaining a separate dev environment is high, and the risk of breaking production is acceptable.
An example is when a small team inherits a complex but stable legacy project, they only need to make a few cosmetic changes, it is nearing its end of life, and some outages are tolerable. If there is no dev environment already, why invest in creating it?
Returning to my point about "mono" meaning "one" - naming is hard. I would prefer to use names which more clearly distinguish between these environment topologies. I would suggest "dev-in-prod" and "dev-plus-prod".
tomwphillips•4w ago
Author here, thanks for reading. Yes, naming is tricky. By mono-environment, I mean that there is one _long-lived_ environment to which we deploy software.
liamph•4w ago
The name "mono-environment" might be misleading for some, as "mono" might be understood to mean that there is only one environment in total.
The practice of "development-in-production" is becoming increasingly rare but it is worth mentioning. That would be where there is no separate development environment at all. I'm not recommending it in 2026! This method is sometimes chosen because the cost of setting up a development environment that is a good match with production is too high. Similar to what the article says about the downsides of staging, sometimes the cost of creating and maintaining a separate dev environment is high, and the risk of breaking production is acceptable.
An example is when a small team inherits a complex but stable legacy project, they only need to make a few cosmetic changes, it is nearing its end of life, and some outages are tolerable. If there is no dev environment already, why invest in creating it?
Returning to my point about "mono" meaning "one" - naming is hard. I would prefer to use names which more clearly distinguish between these environment topologies. I would suggest "dev-in-prod" and "dev-plus-prod".
tomwphillips•4w ago