The many lies about reducing complexity part 2: Cloud

This is true, but it is balanced by the fact that uncertainty can be insanely expensive. And diving into complicated cloud infrastructure with a small business, if you're not already an expert on it, is a very uncertain endeavour in terms of whether you'll get everything set up right (and not find out otherwise at 3am when it turns out your redundancy wasn't, for example) and what everything will cost. By the time you have either become an expert yourself or hired someone who already is, your costs have already increased significantly too, for exactly the reason you've just stated yourself.

- the network engineers who manage switches, firewalls, routers, nats and connectivity

- the people who manage on-prem hardware, install new servers, replace failing servers, and switch broken disks for working ones and install base os using some ilom

- the whole process for ordering that hardware and getting it delivered on time - including knowing when it's going to be necessary

- if your on-prem had virtual servers, the people who manage and operate vmware

- if your on-prem had SAN, the people who manage and operate that SAN (and buy new disks and take care of capacity planning)

Some of those things you still have to do - for example configure firewall, or say "I want to take a snapshot of this virtual disk drive" but instead of doing a difficult technical thing, you can do it in web ui - but you still need to do what to do.

And of course, if you never had SAN and virtual servers and two data center with your team managing the interconnect between private networks, there's a lot of stuff that the Cloud could give you that you probably don't need.

Now if you move to managed redis, you're also replacing the person who installs and patches the linux the redis runs on, and the one who installs, backups and configures the redis. And you get the redis on button click, so if you suddenly need three more, you're also replacing the person who automates building redises.

You are right, that it is not that the operational support is just gone. Some of it is gone. Some of it is replace by doing cloud stuff (like thinking of buying reserved instances instead of actual physical servers). Some of it is just more efficient.

Now if any of this doesn't fit you're use case because you have too small or too large scale, then the Cloud is of course a bad idea.

I have never used Pulumi, I've used Terraform a bit. I like Terraform so this isn't a dig at the tools.

Abstracting your cloud provider is similar to abstracting your database. At a high-level they appear to be the same, they do similar things however the are very different when you get to the fine detail.

Pulmi / Terraform are useful in the provide a common language / API between cloud providers however you will never just switch cloud provider with changing a few lines of code.

1. The models (plural intended) of a business are not necessarily a relational. There could be an upstream/downstream relationship. There could be an event-based relationship. There may be no relations at all (documents are handy in these scenarios).

Stop assuming you start with an entity relation diagram. That's an immediate limiting factor when listening to the business describe their processes.

2. There is no such thing as immediate updates to any database. There is _always_ latency. Build software understanding this.

3. Operational data and Analytical data are TWO DIFFERENT THINGS. (sorry for the shouting)

Operationally, I only need concern myself with the immediate needs of the user or process. If I'm doing "something" to the customer domain, I don't need to know or do anything else. If I'm doing something to the order domain, I may need to notify some other domains of what I'm doing or have done, but that's secondary and not _immediately important_. Inventory systems should have built-in mechanisms for levels and never need to know the exact up-to-date figures.

My operational domains can notify whole other systems on changes in data. So your analytical system can subscribe to these changes and normalize that data all it wants. I can even build user interfaces that display both operational and analytical data.

Micro-services are brilliant at operational domain boundary adherence. Events are brilliant at notifying external boundaries of change.

The caveat I point out to my clients is that thinking in this way is very different than we're used to and often comfortable with. It takes time to identify the best boundaries and events for the models of a business. But if you put in that time, the result will be software that your business personnel can actually understand.

Is eternal longevity even a relevant concept in computing ops any more?

I think businesses must grok that all services are living things that will require eventual maintenance. If you roll your own service, eventually the OS, even an LTS, will need upgrading when the prior release goes EOL. If you're higher up on a FaaS, the language/runtime will still age out, like Python 2, Node.js 6, or Java 5. These will inevitably come with changes. You application will need to adapt.

In extreme cases you can pay for ancient language support and customer IBM mainframe hardware, but the reality is the software's hosting will always need to be updated as time marches on.