>What used to take them ~45min by hand using prebuilt AMIs, now takes ~500 lines of Terraform "code" and several hours of troubleshooting every time
This is just operational immaturity. No one should be building anything "by hand," everything should be automated. Deploying instances from prebuilt AMIs takes a dozen or so lines of Terraform code. Terraform can spin up dozens of instances in less than 5 minutes with a dozen lines of code: https://dev.to/bennyfmo_237/deploying-basic-infrastructure-o...
If you're not operationally mature enough, the problem isn't the tool, it's you. This is basic Terraform usage.
>because Enterprise architecture is mutable by default and cannot simply be torn down and replaced.
This is no longer correct/true. Maybe for laggards it's true, but modern enterprises with modern ops teams using modern tooling are deploying most of everything with immutability in mind. Enterprise architecture is immutable by default now, and destroying and replacing is the norm.
> Enterprise architecture is immutable by default now, and destroying and replacing is the norm.
real life is harder. If I have a cluster of 8 H200 machines running training I can't really destroy it and redeploy. Technically I can but I need to spend time with the data scientists to make sure they configured everything to continue training from checkpoints. And if this cluster is idle for a day the amount of money wasted is around my monthly salary..
hm, maybe more enterprisey clusters are used in a such a way that any node can be replaced at any time.
And this gets into another complication of ET that doesn't happen with PT: with Product Tech, the onus is on the customers to modernize around a new update, whereas with ET, it's our responsibility to work around the customers, on their schedule, and their timeline, unless we want to be fired for "bad customer service".
We cannot simply rip and tear like Product can, placing trust in your orchestrators to rebuild from configs with brand new instances. We can't spool up Chaos Monkey and test-tank the ERP system, because the ERP team has no interest (or political benefit) in modernizing their infrastructure to support Configuration Management tools or pipelines.
> Deploying instances from prebuilt AMIs takes a dozen or so lines of Terraform code. Terraform can spin up dozens of instances in less than 5 minutes with a dozen lines of code
That's ignoring everything that goes into even deciding the "nitty-gritty" around the deployment, which is where the bulk of the code comes from. What security keys does the customer use? Do we use ASGs or one-offs? Is the underlying application fault tolerant or not? Does the customer require backups? What subnet does it go in? What security groups need to be added? What are the tags? Is it region-specific? Does it belong in a higher security zone? Does it need specific failover criteria?
500 lines later, you can deploy one VM with everything needed to meet the customer and organizational demands. That's not efficient, but that's how enterprise technology ultimately works.
> Maybe for laggards it's true, but modern enterprises with modern ops teams using modern tooling are deploying most of everything with immutability in mind. Enterprise architecture is immutable by default now, and destroying and replacing is the norm.
So throwing insults isn't exactly helping here, because I'm literally coming from said modern ops teams, using said modern tooling, from a large enterprise. You can apply a universal standard to "all enterprise" all you want, but the cruel reality is that most Enterprise technology does not work in the way you are describing. ERP servers remain mutable, database clusters are mutable, Physical Security appliances are mutable, hypervisor ops appliances are mutable, VPN concentrators are - you guessed it - mutable. We have built the tooling to support immutable architecture, we have demonstrated its capabilities to the Enterprise, we are ready for Kubernetes and Containers both on-prem and in the cloud, but our customers and applications flatly do not use or support it.
This is something I have had to explain time and again to the Powers that Be (TM), that Enterprise Technology and Product Technology needs/pipelines/customers are vastly different, with different paces, needs, and operational goals. No amount of Terraform, Ansible, GitHub Actions, Argo Workflows, Puppet, or other pipeline add-ons are going to speed up Enterprise Technology, because the software providers do not care to do so. If your Enterprise application selection enables immutable architecture across the board, you are exceedingly lucky to have leaders who allow that to be the case, because in my experience - from small MSPs, to major publishers, to giant tech conglomerates, and everywhere in between - Enterprise Technology is mostly mutable infrastructure with old-but-custom software that will never, ever be modernized, and often with SLAs far superior than anything public customers are allowed to have.
This is just operational immaturity. No one should be building anything "by hand," everything should be automated. Deploying instances from prebuilt AMIs takes a dozen or so lines of Terraform code. Terraform can spin up dozens of instances in less than 5 minutes with a dozen lines of code: https://dev.to/bennyfmo_237/deploying-basic-infrastructure-o...
If you're not operationally mature enough, the problem isn't the tool, it's you. This is basic Terraform usage.
>because Enterprise architecture is mutable by default and cannot simply be torn down and replaced.
This is no longer correct/true. Maybe for laggards it's true, but modern enterprises with modern ops teams using modern tooling are deploying most of everything with immutability in mind. Enterprise architecture is immutable by default now, and destroying and replacing is the norm.