You forgot to mention that Terraform is incredibly slow (also it's to some extent plugins fault), especially if you set all the dependencies between modules. And it creates single lock point: if somebody from the team is actively working with it, others will have to wait for a lock to become free.
You forgot to mention that Terraform is incredibly slow (also it's to some extent plugins fault), especially if you set all the dependencies between modules. And it creates single lock point: if somebody from the team is actively working with it, others will have to wait for a lock to become free.
Great column. Can you please drag systemd/journald through the coals? I have never seen such an abomination in my life. Can I please have a simple text file? KISS FTW.
Spot on. Terraform is the worst, except its the best so far.
Pulumi and CDK's are starting up which show some promise. I think the CDK model is probably the best one (real language frontend describing desired state + engine to make that desired state happen AFAICT; but I've never used one).
The problem with Terraform is that, at its core, it's just an API invocation caching layer. It has no domain knowledge about infrastructure objects. GCL was in many ways better designed(e.g. it targetted a specific infrastructure and it had lazy evaluation), and there are several clues in Terraform's design that the authors were somawhat familiar with GCL without knowing it well, and therefore didn't copy it competently.
Would've been nice to see your thoughts on some of the other IaC tools that actually use programming languages for their DSL (pulumi, CDK).
I've just found terraform to be cognitively cumbersome in most projects. You end up with so many variables, parameters(SSM) and modules that it becomes really difficult to reason about just from looking at the code.
I have _some_ experience using AWS's CDK and generally I found that easier to work with and more powerful in terms of specification. *But* their problem is easier because they only cover AWS.
You forgot to mention that Terraform is incredibly slow (also it's to some extent plugins fault), especially if you set all the dependencies between modules. And it creates single lock point: if somebody from the team is actively working with it, others will have to wait for a lock to become free.
If you think Terraform is slow you haven't seen the alternatives. Pulumi is often an order of magnitude slower on the same resources.
If there is one thing that software engineers have conclusively proven, it is that it is always possible to go slower, even on faster hardware :-)
You forgot to mention that Terraform is incredibly slow (also it's to some extent plugins fault), especially if you set all the dependencies between modules. And it creates single lock point: if somebody from the team is actively working with it, others will have to wait for a lock to become free.
Great column. Can you please drag systemd/journald through the coals? I have never seen such an abomination in my life. Can I please have a simple text file? KISS FTW.
:-)
Systemd is nothing but great.
Spot on. Terraform is the worst, except its the best so far.
Pulumi and CDK's are starting up which show some promise. I think the CDK model is probably the best one (real language frontend describing desired state + engine to make that desired state happen AFAICT; but I've never used one).
The problem with Terraform is that, at its core, it's just an API invocation caching layer. It has no domain knowledge about infrastructure objects. GCL was in many ways better designed(e.g. it targetted a specific infrastructure and it had lazy evaluation), and there are several clues in Terraform's design that the authors were somawhat familiar with GCL without knowing it well, and therefore didn't copy it competently.
Great read Jos!
Would've been nice to see your thoughts on some of the other IaC tools that actually use programming languages for their DSL (pulumi, CDK).
I've just found terraform to be cognitively cumbersome in most projects. You end up with so many variables, parameters(SSM) and modules that it becomes really difficult to reason about just from looking at the code.
I have _some_ experience using AWS's CDK and generally I found that easier to work with and more powerful in terms of specification. *But* their problem is easier because they only cover AWS.