8 ms·
I honestly love Terraform as a product. It was one of probably three tools I've used in my entire career that made me feel immediately more productive. After u
by alexbanks 7y ago
I honestly love Terraform as a product. It was one of probably three tools I've used in my entire career that made me feel immediately more productive. After using it for a very short period of time I was shocked developers continued to struggle through CF templates and the fragility the whole process entailed.
- techntoke 7y agoAgreed about CF. AWS puts a huge emphasis on CloudFormation when they know it is sub-par. Ansible is pretty cool too because you can easily convert between YAML/JSON for CF, and add a lot of flexibility based on variables and other things such as error handling that you can't do with Terraform.
- deboflo 7y agoDefinitely not subpar. Cloudformation is an incredible service. I’ve used it to deploy thousands of stacks. It just works.
- mirceal 7y agodoes it rollback in the face of failure? /s
- reilly3000 7y agohttps://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-rollback-triggers.html https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...
- mirceal 7y agoi know, hence the /s it was a jab at Terraform’s behavior
- joseph 7y agoI don't agree it is subpar. I have a fairly long list of reasons for preferring CF over Terraform. I agree on combining CF with Ansible though. My recipe is to wrap a CF template in an Ansible role. It makes for a versioned chunk of automation that composes well with my other roles, including ones that are not CF based. Plus I can do non-CF setup tasks using any Ansible module, and even run tests, to get pretty much full end-to-end automation for a given stack. I haven't found a way to get the same degree of power and flexibility from Terraform without resorting to writing custom plugins.
- haolez 7y agoWhen working solely on AWS, I prefer CloudFormation, since I feel it's easier to organize my deployments into CloudFormation Stacks.
- deboflo 7y agoWell, I feel the same about terraform. I much prefer cloudformation.
- maxaf 7y agoViewing Terraform solely through the lens of cloud automation and in comparison with CloudFormation is a shortsighted mistake. Terraform has providers for plenty of other services that don't qualify as "cloud things" and lack proper configuration of their own. In a very general sense, Terraform is a terrific resource management tool with state versioning & locking built in. For example, there's a terraform-kafka-provider[1], which can be used to manage topics in a Kafka cluster. Could shell scripts be written to accomplish the same goal? Of course. Would those scripts inevitably develop in a haphazard, organic way to form a buggy and incomplete implementation of something like Terraform? You bet! "Cloud" configuration may have been Terraform's proverbial toe in water, but the truly untapped potential lies in the other providers. Anything that can be packaged as a Terraform provider exposing resource abstractions can be easily managed using convenient HCL syntax. This, IMHO, is the unfortunately buried lede. [1]: https://github.com/Mongey/terraform-provider-kafka https://github.com/Mongey/terraform-provider-kafka
- zbentley 7y agoSomeday folks will rediscover the potential of Puppet for these use cases. Until then, I'm content to watch countless alternative implementations come and go.
- aprdm 7y agoWonder why you got downvoted, as someone who has been using ansible for years to accomplish what was said and what you accomplish with puppet I wonder what I am missing out of terraform
- gtirloni 7y agoThere's a lot of overlap but, in general, Terraform is focused on orchestrating things while Puppet is more about configuration management. Plus, the different philosophies of mutable/immutable infrastructure that the different capabilities/limitations in each tool encourage.
- StreamBright 7y ago
- mirceal 7y agothis is short-sighted. Terraform and CloudFormation are not even in the same league. One of them works and actually can be used for Infrastructure as Code, the other one does not roll back in the face of failure - it effectively craps for reasons ranging from network failure, process crash, even normal operation. One is heavy kool-aid with bugs that go unresolved for years, the other behaves as advertised. Sorry, but I have yet to meet a developer that used Terraform and willingly wants to keep using it after seeing it fail. When your tool cannot keep track of the resources it created or when it gets into situations where it doesn’t allow you to do certain things (like deleting all resources created) and you have to relearn how the underlying cloud works, it’s time to move on. Do yourselves a favor and use Cloudformation (or your favorite cloud’s equivalent and just move on with your life)
- tptacek 7y agoI mean, this is harsh, but there's a running joke that the big feature terraform is missing is a -twice flag so that it'll re-run itself on failure, since that's what you end up having to do anyways. Also, the terraform language, HCL? It's, I guess there's no better way to put this: not good. Am I misunderstanding the complexity of what Terraform is trying to do? To me, it looks like a bunch of tiny API clients tied together with a topological sort --- in other words, it's just another species of "make". It feels like it carries a whole lot more complexity than that concept warrants, but just enough simplicity to make it not a serious programming language. It's, to me, one of those frustrating uncanny valley systems. I am prepared to be totally wrong about this.
- peterwwillis 7y agoNo, it's pretty straightforward, terraform is just intended to parse and execute random functions in a graph generated by a template language. It is absolutely a form of 'make': overcomplicated and generic to serve the needs of supporting random companies' infrastructure as versioned code, without having to write the implementation bits. It's a good idea and not a bad design, but the user experience is pretty bad and nearly all the operational aspect is an afterthought. It was not built to be sold as a product, hence it kind of sucks as a product, but it's fine as a free tool. The fact that it's the best free tool we have for this task speaks volumes about how most companies are deathly afraid to work as a community to build better solutions.
- rsp1984 7y agoI'm an ex Googler and 2nd time founder of a company in the computer vision / robotics space and started hacking when I was 14. I'd consider myself pretty knowledgeable in my area -- yet, I must admit that I have absolutely no clue what Hashicorp and Terraform do and why everybody likes it. I am very curious though. Would you mind explaining this from a high level (to someone who knows cloud technology about as well as your dog)?
- slap_shot 7y agoJust curious: what exactly about the description on the website is unclear? > Provision and Manage any Infrastructure Use infrastructure as code to consistently provision any cloud, infrastructure, and service.
- rsp1984 7y agoThe terms "provision", "manage", "infrastructure" and "service" alone can each have 10s of different meanings. Hence if you multiply it out that sentence could have 10000s of different meanings. Hence it's meaningless to me.
- dodobirdlord 7y agoTerraform serves to translate a descriptive statement about a desired infrastructure state into the sequence of API calls that will bring about that state. Given something like "I want three auto-scaling groups, each containing a minimum of three instances of type m4.xlarge, in the AWS us-west-2 region. And I want an S3 bucket that has permissions set up so that only the code running on those instances can read and write to the bucket. And I want a load balancer between all of them. And I want the instances to run Ubuntu 18.04 and to install these 6 dependencies on startup. And I want a large pepperoni pizza[1]." Terraform will read your credentials and make it happen. [1] https://github.com/ndmckinley/terraform-provider-dominos https://github.com/ndmckinley/terraform-provider-dominos
- alexbanks 7y agoBoth CloudFormation and Terraform are tools that allow a dev to define Cloud Resources (databases, networks, permissions, instances, all that) as code/markup, and then run those markup files through their respective engines (CloudFormation or Terraform) and have those resources get created/modified/whatever. They both have their drawbacks, Terraform obviously suffers from not being a first-class service to AWS (since their service CloudFormation is a direct competitor). It is also possible to accidentally discard your Cloud "state" file, that keeps track of every instance that already exists and its current state (so TF can do a "diff" on what is there vs. what you're trying to apply), which definitely causes some headaches. In my experience the benefits of the design decisions from the tool far far outweigh any of the cons. On the contrary, I have never had a good experience with CloudFormation. The workflow is long/slow, some of the AWS Best Practices are hilariously bad (looking at you "Paste this entire Python file as a text string into a yaml file), and more than a few times have I gotten into a state where CF-generated instances cannot be deleted and require the intervention of an AWS Rep.
- mxschumacher 7y agowhat are the other two tools?
- goatinaboat 7y agoMy experience of TF is very much the opposite. It looks fantastic on paper (well, in the browser) and I was excited to start using it. But the shine quickly wore off. It claims to be multi-cloud but it's not as if you can take some TF from AWS and run it on Azure - it's a rewrite. And it claims to be able to import existing, running cloud configurations so migrating to it should be easy, but it doesn't work, so that's a rewrite. And it is terrible at modifying existing things, the developers of TF seem to be believe that destroying everything and rebuilding from scratch is the way to, say, add another node. Of course by the time you figure all this out you have invested so much political capital in persuading the organisation and your peers to adopt it that you're stuck with it. But the lesson is really, use whatever is native to each cloud, such as CF on AWS, beyond any trivial deployment you're locked in anyway, might as well enjoy it.