Announcing the Second Edition of Infrastructure as Code(infrastructure-as-code.com)
infrastructure-as-code.com
Announcing the Second Edition of Infrastructure as Code
https://infrastructure-as-code.com/book/2019/12/10/announcing-second-edition.html
2 comments
I really hope this book has some discussion regarding Pulumi in addition to the normal Terraform discussion. My team switched over to Pulumi recently after using Terraform for a couple of years and it's so much easier to work with. It would be a shame if it is not at least included in the discussion.
I've seen lots of comments (not just on HN) about how Pulumi/CDK are easier, more powerful, etc. This is probably true from the perspective of someone writing infrastructure as code. Working in security I spend more time _reading_ pull requests for infrastructure as code, and I think Terraform's declarative syntax is 100% superior in that regard. Being able to see the infrastructure without trying to mentally execute code, and being able to run static analysis tools against your infrastructure, make it my preferred infrastructure as code tool.
>and being able to run static analysis tools against your infrastructure
Is the Pulumi/CDK code too dynamic to support static analysis?
Is the Pulumi/CDK code too dynamic to support static analysis?
HCL is declarative whereas a general purpose language is imperative, which makes static analysis much harder.
I had never heard about it before reading this comment, and just going and checking out the video on the front page, I am blown away.
I have to be honest, I hadn't messed around with Terraform before, but I've been working with Ansible/CloudFormation and Pulumi is just on another level. There are so many hacks you need to do to work around CloudFormation peculiarities, and separating stack creation and manipulation into two separate formats is frustrating at best.
Going to have to play around Pulumi more seriously when it's time to stand up more servers.
I have to be honest, I hadn't messed around with Terraform before, but I've been working with Ansible/CloudFormation and Pulumi is just on another level. There are so many hacks you need to do to work around CloudFormation peculiarities, and separating stack creation and manipulation into two separate formats is frustrating at best.
Going to have to play around Pulumi more seriously when it's time to stand up more servers.
> I really hope this book has some discussion regarding Pulumi in addition to the normal Terraform discussion. My team switched over to Pulumi recently after using Terraform for a couple of years and it's so much easier to work with. It would be a shame if it is not at least included in the discussion.
Could you speak more to some of the ways it was easier to work with? How was the transition and what was the migration strategy?
Could you speak more to some of the ways it was easier to work with? How was the transition and what was the migration strategy?
Total IaC n00b here.
3 weeks ago I set up our AWS infrastructure with Terraform but somehow I never got it to work correctly (somehow the AWS Elastic Beanstalk health checker never turned green).
Just this week I decided to migrate to Pulumi and after a few very explanatory good error messages I got it to work. I'd say Pulumi's error messages are superior.
Another major benefit of Pulumi is that you can use typescript (and others) to script your setup. Terraform supports some scripting [1] but you have to take a few hours to learn it, and it never will be as powerful as plain ts/js/py.
[1] https://www.hashicorp.com/blog/hashicorp-terraform-0-12-prev...
3 weeks ago I set up our AWS infrastructure with Terraform but somehow I never got it to work correctly (somehow the AWS Elastic Beanstalk health checker never turned green).
Just this week I decided to migrate to Pulumi and after a few very explanatory good error messages I got it to work. I'd say Pulumi's error messages are superior.
Another major benefit of Pulumi is that you can use typescript (and others) to script your setup. Terraform supports some scripting [1] but you have to take a few hours to learn it, and it never will be as powerful as plain ts/js/py.
[1] https://www.hashicorp.com/blog/hashicorp-terraform-0-12-prev...
Just looking between the two (where I'm at we've adopted Terraform), I wish where I'm at would switch to Pulumi as well. After seeing the contortions required under Terraform when someone strays from Terraform's pre-conceived notions embedded into HCL DSL, I'm convinced that at-scale (>200 servers, arguably >100 servers), there is no satisfactory way around the "learn to code" requirement in devops at this layer interacting with infrastructure.
It doesn't seem to have the same level of provider support though. I would rather pick a tool thats well supported by cloud providers if I need to use it for production stuff.
Extremely good point, thank you for making it!
Where I'm at, we just so happen to only be in the initial phases of a cloud strategy, and it happens to align with Pulumi's current support of AWS. So Pulumi's execution of a multi-vendor solution will bear keeping a close eye upon.
We're likely in for a few years yet of fragmented API wars amongst the cloud vendors, before the value extraction from uncoordinated API's levels off enough that a more universal API is adopted for a progressively-larger "core cloud" of defined services (we're kind of seeing that with cloud object storage for example), W3C-style.
Where I'm at, we just so happen to only be in the initial phases of a cloud strategy, and it happens to align with Pulumi's current support of AWS. So Pulumi's execution of a multi-vendor solution will bear keeping a close eye upon.
We're likely in for a few years yet of fragmented API wars amongst the cloud vendors, before the value extraction from uncoordinated API's levels off enough that a more universal API is adopted for a progressively-larger "core cloud" of defined services (we're kind of seeing that with cloud object storage for example), W3C-style.
Not sure what you mean. I don’t think there will be any api wars; likely providers will support tooling that can talk to their apis. This is currently the case for Terraform where different cloud officially support the tf modules. If they start supporting Pulumi, that would be when I would be comfortable switching to the tool.
It's a sad day when the tool you are using to call an API over HTTPS has to be supported by AWS for people to use it.
There's absolutely nothing sad about setting expectations over quality of service for infrastructure management tools. HTTP as a protocol wasn't designed to be e.g. the language for expressively communicating complex state changes when managing cloud infrastructure.
A better analogy, would be if e.g. the NFS protocol spec wasn't enough to use NFS file systems, but required vendor support to work correctly.
A better analogy, would be if e.g. the NFS protocol spec wasn't enough to use NFS file systems, but required vendor support to work correctly.
I know that Pulumi can use Terraform providers, at least. I'm not sure how good the integration is or if it's in the main way of doing things, though. I'd love to hear more details if anyone here has used it.
AWS CDK was what came to my mind as "next gen" infra as code, sounds like Pulumi has somewhat comparable approach
Thanks for mentioning this, my org is in the process of evaluating various options for Infrastructure as code stuff and Terraform is very high up on that list. I don't believe Pulumi has been discussed and looks quite good, always nice to be able to suggest it before adoption.
In some quick searching, Pulumi has a high level (and assumedly biased) comparison between Terraform and itself: https://www.pulumi.com/docs/intro/vs/terraform/
In some quick searching, Pulumi has a high level (and assumedly biased) comparison between Terraform and itself: https://www.pulumi.com/docs/intro/vs/terraform/
The oreilly site to buy is not http :yuck:
Thats one thing I wish were enforced more than anything. SSL or better for financial transactions online. Surprised its HTTP. Maybe they redirect once you are actually paying? I have seen that be the case.
It doesn't look like you can buy anything at their shop, they either redirect to Amazon or to their subscription platform (which does use HTTPS).
Redirecting to https is still problematic though.
Let's say your websites homepage only uses http but the login form is over https. You can MiTM the homepage, and change the login link to haX0r.xyz and then proxy the login.
Let's say your websites homepage only uses http but the login form is over https. You can MiTM the homepage, and change the login link to haX0r.xyz and then proxy the login.
Is that the case here?
They have to, or will quickly find themselves racking up some PCI fines.