Yeah: latency. Everything else is identical, from the software perspective. Even the distributed aspect is identical: multiple copies of software running in one OS, or multiple machines running one copy of the software, are treated virtually identically.

> it's only in the world of modern virtualization and clouds that you can start to do that through APIs

I've worked in multiple companies, starting nearly 20 years ago, that had automated the process of provisioning and re-provisioning both hardware and software across tens of thousands of machines in multiple datacenters. Without virtualization, without the cloud. Know how we did it? Same way Terraform does it. Make an API, make a tool to call it, API backend does some magic, returns result, tool does something with result. Nothing has changed except the buzzwords (and the programming languages).

Configuration management is "a systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life." [1] It is not Puppet or CFengine. It is an engineering practice that is nearly 70 years old. Terraform is an implementation of it, as are many other tools, and many things that aren't software at all.

> None of this is marketing speak. It's just definitions and categorizations. Sometimes useful, sometimes not. And all of it is orthogonal to what terraform does do or should do.

On the contrary, the categorizations are made up by people who don't understand the history and practice of the field and confuse designers and practitioners into thinking that what they're doing is correct because "that's just what things in this category do". It's throwing out systems thinking and replacing it with a cargo cult of buzzwords and generally useless concepts.

Every week I see somebody talking about "Infrastructure as Code" as if it's a real thing. It's not. IaC just means somebody put a shell script and config file in Git. Yet they treat it like it's both revolutionary and specific to this one corner of tech. Like we haven't been version-controlling or change-managing the provisioning of computing devices for decades. People who weren't aware of standardized practices for management of fleets of devices basically had to stumble upon it, and not having any other reference, decided to give it a new name and pretend it was novel, and in the process did not learn the lessons from past decades of similar practice.

This is not just an "old man yells at cloud" rant - the point is that tech people keep refusing to learn their history, and then poorly implementing something that could have been designed much better if they'd learned their history. It's like the history of medical practice, where some areas of the globe (cough western europe cough) were embarrassingly backward because they never reached out to learn about the history, research, and best practices outside their sphere. They just did what everyone else around them did. People suffered for decades as a result. We don't suffer quite as much now, but the advancement of technology does suffer as a result of the industry's stodgy refusal to improve on its cargo cult mentality. (Repeating whatever you read in a blog post on HN is what makes things like "Infrastructure as Code" seem like a real and novel idea to people; repeat an idea enough and people just believe it and repeat it too)

Another example: "declarative configuration". All configuration is declarative. Even imperative configuration is declarative. This tautology is debated in blog posts the same way you'd debate the use of types of butter in cooking. It's all just butter. Yeah, some comes without salt; just add some salt to your dish. Yeah, some comes with salt; just withhold some salt from your food. We don't need to go on long-winded writings about the use of different butters. But some people create entire software projects dedicated to one kind of butter, because they think it's super important to only use unsalted butter.

[1] https://en.wikipedia.org/wiki/Configuration_management