Terraform is literally a program that looks at a declarative configuration file, looks at a state file, queries some APIs, and then submits some API calls. That is all it does.
There is no "infrastructure", or "config", or "cloud". It's literally just calling HTTPS APIs, the same way it would call a system call or a library function. Call function, pass input, receive output.
There is no magic sauce. There is no difference between it and any other tool that has a declarative configuration, a state, and operations to try to change things to match a desired state.
It's all configuration management. The words "infra", "orchestration", "cloud", etc is marketing bullshit. It's all just software.
But there is a very real difference between "Deploying a server" and "Modifying configuration files on that server". The former used to require actual physical actions in a data center and it's only in the world of modern virtualization and clouds that it has become possible to do it through an API. Where as the latter used to require secure access to an individual physical machine, often over SSH after someone had done the physical work of setting it up. Again, it's only in the world of modern virtualization and clouds that you can start to do that through APIs.
It is only modern clouds that has blurred the lines between these two by abstracting away the difference between the physical server and the software running on it behind APIs.
Conceptually, it can still useful to think of "infrastructure orchestration" and "configuration management" as different things and different categories. Like I said, in many cases cloud offerings significantly reduce the utility of those categorizations - because they often abstract both steps behind a unified API where you are launching virtual infrastructure (still largely using the same conceptions that were used when it was physical) and defining its configuration at the same time through the same interface.
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. Whether or not terraform is "infrastructure orchestration", "configuration management" or both is neither here nor there for the definition of those terms and considerations of their utility.
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.
