31–40 of 119 posts
The code comparison between CloudFormation’s abysmal JSON formatting and Terraform’s DSL is a bit disingenuous. CloudFormation has supported YAML for at least a year or two now, and it’s leagues more readable and compact, not to mention maintainable—you can even add comments to your code with YAML (something that is impossible with the old JSON format). I’ve spent a lot of time working between the two, and while Terr…
CloudFormation is really bad compared to TF.
Their AWS bill seems like it would be a lot higher than it needs to be. They're spinning up always-on staging, testing and development environments in 3 different regions. I know they've got autoscaling configured, so their production environment should be significantly larger than the others, but it still should be possible to be much more economical while accomplishing all of those non-production workloads. The who…
In cloud development environments, you need to account for multi-AZ deployments and the challenges associated with such.
I'd wager that they'd have far more issues from sharing a development environment between developers who are all pushing unreleased code to the same environment than they'd have from differences with the production environment. It should be pretty easy for a developer to spin up a simplified environment on demand from a branch or specific commit to do their testing. As a bonus, anyone reviewing code can spin up a similar environment from a pull request to ensure that code does what they think it does.
Infrastructure as code is a good first step. Embracing the freedom you get from that reproduceability is the next step.
Interesting blog post, but AgileBits should have communicated planned downtime to their customers via email, which they did not. I’ve been a 1Password user for years and recently switched to their hosted offering. I know a massive infrastructure migration is rare, but that’s all the more reason to be transparent ahead of time.
I am sorry if the downtime affected you in any way. Sending several million emails could be a challenge considering that most of our customers depend on 1Password apps and usually not affected by the downtime. We do have a status page and Twitter feed where we make announcements: https://status.1password.com https://twitter.com/1passwordstatus
The code comparison between CloudFormation’s abysmal JSON formatting and Terraform’s DSL is a bit disingenuous. CloudFormation has supported YAML for at least a year or two now, and it’s leagues more readable and compact, not to mention maintainable—you can even add comments to your code with YAML (something that is impossible with the old JSON format). I’ve spent a lot of time working between the two, and while Terr…
I believe there was a case last year when one of the new AWS features was available in Terraform before it made it to CloudFormation :)
Their AWS bill seems like it would be a lot higher than it needs to be. They're spinning up always-on staging, testing and development environments in 3 different regions. I know they've got autoscaling configured, so their production environment should be significantly larger than the others, but it still should be possible to be much more economical while accomplishing all of those non-production workloads. The who…
You are right. Our AWS bill could certainly be lower and we will have to start optimizing it at some point. It is does require extra time/effort though. We deployed 1password.ca and 1password.eu just a few months ago and never really got to that. The only thing we "optimize" at the moment is the smaller number and size of EC2 instances in non-production environments.
Always-on non-production environments are, to my mind, a vestige of the time where you had physical servers that needed to be provisioned by a person and cost roughly the same amount when switched off. Or at least the time where OPS built and maintained each AWS VM by hand. On-demand just offers so much more flexibility...stuff like the example from my response to a sibling comment--you should be able to type a single command and spin up an environment from a pull request any time a code reviewer wants to do testing to ensure that what code looks like it does is what it actually does.
The more you can leverage the work you've done to get to where you are, the more you can drive down your AWS costs while giving greater flexibility and isolation to your non-prod workload.
Earlier quoted context omitted.
Every time I see Cloudcraft, I wish it was available for GCP. I think it's a fantastic way to visualize interconnected systems
Ah. I wondered what made these terrible diagrams. They look cute but the text and the symbols are incomprehensible.
With that said, I consider getting the AMI id dynamically to be an anti-pattern which undermines the principles of infrastructure-as-code. Specifically, it introduces an implicit build variable "time of `terraform apply`", which is not tracked in version control. Happily, because of Terraform's design, this sort of thing mostly won't cause your infrastructure to drift into unexpected states (e.g. production instance 1 running AMI X and production instance 2 running AMI Y). Within an environment, things should be consistent, but your staging environment may run AMI X while production is running AMI Y, and you wouldn't know from looking at your Terraform definitions.
I previously wrote about similar ideas in the context of pinning dependency versions, where wildcards can and often do get you into bad states. https://jonathan.bergknoff.com/journal/always-pin-your-versi...
Great post. It's always good to see more examples of people putting these tools to work. With that said, I consider getting the AMI id dynamically to be an anti-pattern which undermines the principles of infrastructure-as-code. Specifically, it introduces an implicit build variable "time of `terraform apply`", which is not tracked in version control. Happily, because of Terraform's design, this sort of thing mostly w…
I’ve always wondered — from a security perspective, is this kind of an in-depth engineering blogpost a good idea? You’re basically handing a map of your internal infrastructure to any potential attacker who reads the blog. Of course obscurity is not security blah blah blah. Still I can’t help feeling that writeups like this could backfire down the line.
The internal infrastructure of AWS apps are fairly guessable anyway. There are only a limited number of AWS resources and they fit together in predictable ways, VPC - Gateway - ASG - EC2 etc etc. I think it's really great that they've talked about this, it's quite rare to hear about these kinds of internal migrations, and it's something I do a lot with clients but it's not really glamorous enough to talk about.