3 ms·

I have always kind of disliked both cloud and containers. Primarily, they just add more complexity and overhead into the computing landscape. I've thought this

I have always kind of disliked both cloud and containers. Primarily, they just add more complexity and overhead into the computing landscape. I've thought this to be bad both in material resources and energy consumption, but humans have a high time preference, and therefore they choose to spend both materials and resources to get a little more time back. This is much the same reason that hipster languages and frameworks are in a constant state of churn. I myself am guilty of perpetuating these things that I dislike from an analytical perspective where I say they are wasteful, because I often just want to get something done so I spin up a cloudy service of some kind, deploy some code, close a ticket and walk away knowing I didn't go about things the "correct" way. For all of this to stop, not only does the bubble need to burst but people would need to be far more intentional about what resources they use where and when. People would also need to have longer software lifecycles, more QA, and so on. This would only happen in an environment with far higher interest rates and far lower monetary velocity. In essence, there'd have to be a lower tolerance of risk to stop the constant churn of hardware, software, and development methodologies on both. There are tradeoffs to such changes.

llanowarelves 4y ago
I predict that in the downturn, we will see not only less cloud, but less microservices -- more "macroservices" or monoliths. For the same reasons you outlined above: complexity.
outworlder 4y ago
> Primarily, they just add more complexity and overhead into the computing landscape. No, they don't 'just add more complexity and overhead'. They are tools. Properly utilized, they are great. There's a reason why you are (probably!) not running a power station and home and have, instead, hooked to a power utility company. They have the expertise and can amortize the costs among many customers. Similarly, containers actually brought efficiency – they replaced many(obviously, not all) of the use-cases that usually required virtual machines. They also simplified some very difficult deployments. The problem arises when you are doing things for the wrong reasons. For example, using 'microservices' just so you can try to avoid teams from having to talk to one another and end up shipping your org chart. I do agree with a more generalized statement: more often than not, monoliths are what you need.
raffraffraff 4y ago
I worked in a small team that brought containers into a co-lo / bare metal / centos / rpm / puppet shop. There was extra shit for developers to learn but I don't think it was waste. Not just because "everything is containers" nowadays, but because until they tried to build a container with their code actually working in it, most of them had little idea about how their shit worked. One example from the field: a VM got rebuilt and the app installed from scratch, but it wouldn't work. I hopped into the box and farted around with logs, strace, ldd, rpm commands and eventually realised that they introduced a dependence on a package that used to be installed on the system but was no longer there. It kept working on all existing machines but failed in a "build VM from scratch and run Puppet". Not only did that mistake make it out to production, but at that time few of the developers would have had a clue how to fix it. After the containerization of our services, this was absolutely not the case. (And honestly, we just conceptually replaced RPMs with containers, standardized all of our servers to the same build and forced developers to be aware of how their code actually worked).

llanowarelves 4y ago

I predict that in the downturn, we will see not only less cloud, but less microservices -- more "macroservices" or monoliths. For the same reasons you outlined above: complexity.

outworlder 4y ago

> Primarily, they just add more complexity and overhead into the computing landscape. No, they don't 'just add more complexity and overhead'. They are tools. Properly utilized, they are great. There's a reason why you are (probably!) not running a power station and home and have, instead, hooked to a power utility company. They have the expertise and can amortize the costs among many customers. Similarly, containers actually brought efficiency – they replaced many(obviously, not all) of the use-cases that usually required virtual machines. They also simplified some very difficult deployments. The problem arises when you are doing things for the wrong reasons. For example, using 'microservices' just so you can try to avoid teams from having to talk to one another and end up shipping your org chart. I do agree with a more generalized statement: more often than not, monoliths are what you need.

raffraffraff 4y ago

I worked in a small team that brought containers into a co-lo / bare metal / centos / rpm / puppet shop. There was extra shit for developers to learn but I don't think it was waste. Not just because "everything is containers" nowadays, but because until they tried to build a container with their code actually working in it, most of them had little idea about how their shit worked. One example from the field: a VM got rebuilt and the app installed from scratch, but it wouldn't work. I hopped into the box and farted around with logs, strace, ldd, rpm commands and eventually realised that they introduced a dependence on a package that used to be installed on the system but was no longer there. It kept working on all existing machines but failed in a "build VM from scratch and run Puppet". Not only did that mistake make it out to production, but at that time few of the developers would have had a clue how to fix it. After the containerization of our services, this was absolutely not the case. (And honestly, we just conceptually replaced RPMs with containers, standardized all of our servers to the same build and forced developers to be aware of how their code actually worked).