Very true. I wonder if the control plane is hosted in a single region.
995 karma · joined December 30, 2011
You can contact me at: hn [ at ] reidwiggins [ dot ] com
(To my knowledge, it's the only AWS service to promise 100%.)
Like one sibling comment mentioned, getting support from AWS is nice. You can buy Terraform support, too, but knowing HashiCorp it'd probably cost more than most peoples' AWS bills in their entirety. (This is me being a little cheeky and unfair—HashiCorp handles community support via GitHub Issues for Terraform really well.)
CloudFormation's built straight into AWS, so there's no need to set up state file storage or locking or worry about a state file at all, really. This has its own set of drawbacks, but it's nice for getting started, and in theory it makes CloudFormation more robust out-of-the-box.
CloudFormation StackSets are really nice if you have identical resources that need to be placed in many different regions and accounts. (Example: we use it to place GuardDuty and Config, both regional services, in every region.) With Terraform, this means copy-and-paste, as far as I know, though maybe Terraform 0.12 sets up the groundwork to make this better?
The Service Catalog is basically a way to let technical end-users manage products via CloudFormation templates. Something could be built to do the same for Terraform, but I don't think there is anything like that right now.
CloudFormation does (attempt to) roll back to a known-good state if an update fails. Terraform just stops in the middle of what it was doing. I have mixed feelings about that.
I find YAML to have better tooling/editor support than HCL, though I actually prefer HCL.
There are existing CloudFormation wrappers (e.g. Troposphere) that can give you a full programming language on top of CloudFormation. To my knowledge, there isn't anything similar for Terraform.
Some things that have changed with 0.12:
CloudFormation has had `AWS::NoValue` for as long as I can remember. Terraform <=0.11 had special values (like empty string, number zero, etc.) that were special-cased as no value. Terraform 0.12 now has `null` properly.
Terraform <=0.11's ternary operators were maddening because both sides were evaluated, which led to errors, unlike CloudFormation's !If. In Terraform 0.12, the ternary only evaluates one side.
I've never had Terraform "forget" resources or disallow me from deleting them (unless I requested that). Maybe those are bugs that've since been fixed?
It sounds like we've had very different experiences with these tools.
That said, I don't think CloudFormer does the same thing. I haven't used it before, so please correct me if I'm wrong, but to me it looks like it takes existing resources and generates a CloudFormation template out of them. But then you're still expected to upload that template and create a new stack, with all brand-new CloudFormation managed resources—is that right?
So for example, CloudFormer for an RDS instance would probably be a no-go.
In the Terraform case, after you've imported resources, there's no need to re-create them. There's the question of if what's in the template will match what the resources actually are, but there are also tools to generate Terraform templates straight off resources.
Auditability and controls are one of the many facets of IaC. We require code changes to be approved by another developer, and similarly we require infrastructure changes to be approved by another developer. Regularly working outside the IaC tool would be in violation of that policy.
It's in this approval step that the change-set (CFN) or plan (Terraform) should be carefully reviewed by a human. If someone's made manual changes, reversion of them should appear here, and those should be unusual and eyebrow-raising. At that point, it's either fix the IaC definition of the infrastructure, manually un-drift it as you say, or do some workaround to ignore specific changes.
(To reiterate, IMO no one should ever run CFN/Terraform unattended on prod infrastructure, and there should always be a step to review the change-set/plan.)
I'll also say that the sword cuts both ways when it comes to prod outages and manual changes. Not so long ago, I ran into a prod-impacting issue when turning on multi-AZ for an RDS instance. In the other regions that had multi-AZ enabled, someone had manually added an extra parameter to the RDS parameter group, one that was required for certain app functionality to work. No one ever added it back to CloudFormation and that knowledge was eventually lost. When we enabled multi-AZ in a different region, we expected no problems at all, but instead we ended up with a whole section of app functionality breaking.
(This would've been before drift detection was a thing in CloudFormation, but actually I don't think RDS parameter groups are supported in CloudFormation's drift detection right now anyway. [0])
[0] https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...
I do think you're selling Terraform short, though. Sure, the core is the toposort-create-things. But it also stores the state of its created things and (crucially) has the ability to diff the actual state of resources against what it thinks they ought to be.
Being able to inspect existing resources and diff state is also what lets it import existing resources, so that they can be Terraform-managed going forward.
Terraform is also capable of determining if its planned changes can be performed in-place or if they require resources to be destroyed and re-created. That boils down to a boolean flag on a field, ultimately, but it's still something a dead-simple make clone probably wouldn't do well.
I've only really used Terraform seriously for AWS, so I'm not sure about the other providers, but the Terraform AWS Provider has an enormous amount of work behind it. Basically every resource API has schema validation written in the AWS provider, and depending on the resource there are often eventual-consistency issues handled by the provider. See for example [0].
In contrast, AWS CloudFormation: can't import existing resources; isn't always sure whether an update will require replacement or not; and, as of ~6 months ago, can detect configuration drift, but not correct it (!). Of course, CloudFormation wins in other areas...
[0]: https://github.com/terraform-providers/terraform-provider-aw...
Copying the "layman's terms" from that page for your convenience...
In layman's terms, during SRP (or any other PAKE protocol) authentication, one party (the "client" or "user") demonstrates to another party (the "server") that they know the password, without sending the password itself nor any other information from which the password can be derived. The password never leaves the client and is unknown to the server.
I don't really feel extorted. These things are usually services provided to me, services that probably would not exist without revenue, whether by ads or subscriptions.
I will say this: there are times where I feel somewhat disconnected as a result, especially when it comes to entertainment. Like, I saw Avengers: Endgame without having seen Captain Marvel first... because I didn't know Captain Marvel was being released. It didn't show up on any of my social media, I guess, or I missed it if it did.
Similarly, I've missed new seasons of shows I cared about. No political ads - sometimes people refer to local ads in casual conversation and I'm mostly lost. Stuff like that.
It's sort of eye-opening to realize how much information is disseminated via ads/media. I mean, it's obvious in retrospect, right? But to experience it, well, it's something.
It would definitely be an annoying migration, even if import works for your use-case, but honestly, dealing with CloudFormation is so irritating on a day-to-day basis for me that I'd consider it worth it.
After a few rounds of back-and-forth, I eventually gave up.
(I even gave them permission to copy test snapshot data, at their request, and sample queries to reproduce the issue. They could have done all the testing they wanted in-house. But that might have actually required them to spend time on their side to diagnose and fix something, I guess.)
It wasn't a critical issue, exactly, and we worked around it in code. I mostly just wanted to report a problem.
Also: The heart beat monitoring features account for some portion of the Apple Watch's price, surely, but I suspect for most people this feels like a "free" benefit.
(If anyone can't tell, this is incredibly frustrating for me, since Inbox is going away soon.)
You can even add vinyl effects (warmness/clicks) in post-processing. I have a few songs in my library that really do sound like you're playing an LP, even though they're completely synthetic.
In the ripping community, there are some well-known albums that were mastered differently for LPs and are considered superior to their digital mastering. And so there are folks who spend $$$ on setups to play back the LP, record it, and then postprocess it to remove clicks. You end up with a digital audio file that has the better mastering. You could put that same file on a CD, after all.
https://terrytao.wordpress.com/career-advice/theres-more-to-...
That said, for most organizations, I've never been all that convinced that the multi-key-holder model provides much benefit.
For instance, a us-east-1 bucket has a data transfer rate to the internet starting at $0.09/GB. That's flat, regardless of where the requester is located.
On the other hand, while US- and Europe-based transfer pricing is cheaper in CloudFront (starting at $0.085/GB), all the other regions are more expensive... for example, South America starts at $0.25/GB (!).
Of course the reverse is true: a bucket originally hosted in South America would probably do well to enable CloudFront, as requests from every other region become cheaper...
And yet another wrinkle, I think CloudFront always is cheaper than S3 eventually (with enough data usage). So for very large customers, maybe it is true that CloudFront will always be cheaper. Clear as mud.
I also prefer Terraform. However, both Terraform and CloudFormation are warty in their own ways—this is a space where there's a lot of room for improvement. Fortunately, the as-yet-unreleased Terraform 0.12 [1] looks as though it'll resolve most of my complaints...
The summary (from the article) is that:
sleep_time = random_between(0, min(2 ** retries, max_sleep_time))
In contrast, Discord has a volume slider that I end up having to adjust for most people. That requires manual tweaking, often while I'm playing a game, and isn't future-proof; just the other day, one of my friends changed his microphone setup and was extremely loud (I had him at 200% when in the new setup he should've been at about 75%).
This is really my only complaint with Discord's VOIP functionality. It is a major step backward from Mumble. (Also, for some reason the Discord community mostly uses voice activated mic instead of push-to-talk, but I don't think that's Discord's fault.)