Hacker News Reader

Don't get me wrong, I love AWS. I use ~15 products almost everyday. I actually like how powerful IAM is.

But yeah, CloudFormation just sucks. It does. It's painful because it's a really good idea but the configuration format is inadequate for the task.

CF should have been implemented using a declarative DSL similar to Puppet from the start. I've been tinkering with the idea of creating a DSL with a JSON translation layer but I always assumed AWS would eventually move away from JSON anyway, making the effort futile. Four years later and still no improvements. Definitely my biggest disappointment with their platform.

Plenty of those DSLs already exist, the cfer project[1] that I contribute to and SparkleFormation being two I can vouch for. I don't find CloudFormation particularly annoying or difficult, and certainly better than the alternatives (BOSH/Terraform/etc.), given such a wrapper, and cfn-init with CloudFormation metadata is miles ahead of "well, install Consul and connect to the cluster and eventually reach the state you want to be in" for my uses.

[1] - https://github.com/seanedwards/cfer

[2] - https://github.com/sparkleformation/sparkle_formation

I maintain a ruby dsl as well at http://github.com/bazaarvoice/cloudformation-ruby-dsl

The format is a weak argument against cloud formation. It has some negatives. This one is easily overcome.

And I salute you! We heavily use the Ruby DSL.

I have to state that configuration is not easy. CF might suck, but imagine something easily to replace it and works better is close to be wishful thinking.

Terraform

Am I insane, or are you and the commentators below unknowingly describing Terraform?

https://www.terraform.io/

You're not insane!

I'm glad I'm not the only one who thought cloudformation was difficult.

Terraform is great so far. I am running into some duct-tape issues with resources shared between two terraformations, though.

As already said, you should use terraform which has its own DSL (called HCL). Inspired by JSON but way simpler and more appropriate for this specific task.

Important tip: If you use one of jetbrains IDE (IntelliJ/PyCharm/...) there is a free plugin to handle terraform files.

It gives the usual syntax highlighting + auto completion of variables and devices + detection of errors. It's very very nice!

> And god forbid you enable 2FA, you'll have to get your phone out twice a day.

How onerous, a security mechanism you actively turned on actually requiring you to do something. My car is just as bad - I drove it at a wall, and the front bit crumpled up!

And if you're getting your phone out twice a day, then perhaps your work hours are a bit crazy (12 hours+) and the problem is less to do with AWS than your workplace?

My Google account is far more secure than my AWS account, but it can actually remember device-based 2FA for a month. Yes, how onerous, Google accounts are LITERALLY like a crashing car.

And as someone who works at home, I work whenever the hell I want, get off my back and go troll elsewhere.

Far more secure how?

>it can actually remember device-based 2FA for a month

Call me crazy, but that seems like a totally different feature than what AWS two-factor auth is doing. AWS uses 2FA to validate users, while Google uses it to validate devices, and you're making it seem like Amazon is too dumb to use local storage for something.

(Also, I don't think the parent commenter was comparing Google to a car crash. The analogy was that it seems weird to get mad about features performing their stated actions.)

2FA that is long lived and only protects the device does not sound as secure for something this critical.

Wow. My apologies, I didn't realise your personal self-worth was so wrapped up in your google account. I wasn't even referencing google with the car thing, but the AWS mechanism doing what it's been activated to do.

If you're that sensitive about lighthearted hyperbole, then perhaps you shouldn't use it in the first place.

I work 12 hours apart in one day all the time. I work an average of 16 hours a week, from home. Stick to the actual discussion rather than trying to invent nonsense reasons to dismiss people's opinions.

> you'll have to get your phone out twice a day.

I pull out my phone at least 6 times a day for that just to switch between accounts.

Welcome to the wonderful world that agile/lean methodology has given us. They've delievered shit just to say they delievered something. They won't actually give you what you need until they get enough backing for it.

It's ridiculous to blame agile for "delivering shit" (I'm not a huge agile fan neither) - after all it always comes down to the people involved not the methodology/process applied.

A though experiment: do you blame democracy, because Trump is now a nominee? If you have lousy people, choice of process does not really matter.

Actually that would be a perfectly valid criticism of democracy. A dictatorship, for instance, is more robust to a generally lousy populace, though it suffers from other problems of course.

It is possible to link accounts so you get a simple dropdown that lets you select the account you want to use without logging out and in again.

> They've delievered shit just to say they delievered something.

You're right.

This never happened before the agile manifesto was published.

Yes, some limitations and bugs are just ridiculously interesting. As a customer, I know my TAM would tell me this is much an organizational issue. One team pushed a feature, but the other team wasn't ready so the feature would just hold up in a pending state for months. I can't disclose which new feature's coming out, but essentially, yeah that feature won't come out until the other team gets their product updated.

Another classic example is Directory Service's security group can only be found if you go to VPC / EC2 console page to search. The SG isn't even mentioned in the Directory Service console. I bought reserved instances for RDS and EC2, one of them accepts custom tagging, so you could name the purchase, but the other doesn't.

If you use CloudFormation you want to make sure the resources are managed by the CFn. Your manual change could break the next CFn update. In some cases, rollback is not possible and will require AWS Support's intervention. Another example, say you have a cluster of 3 Cassandra nodes, you would build 3 EC2 from a single CFn stack. Well, time for server rotation (by that I meant taking the instance out and replace with a new one), one node at a time. Too bad you really can't out of the box. You have to build another stack with 3 instances, and then start configuring one node and swapping one node at a time plus changing the underlying dynamic inventory we got out of Ansible.

Is there any particular reason you need IPv6? I get the whole IPv4 exhaustion thing, but if AWS can figure out a way to get me an IPv4 address when I need it, this seems preferable to dealing with IPv6.

From my experience, some (Virgin Media in IE) ISPs with IPv4 CGNAT have a slower/less reliable IPv4 connectivity than with native IPv6.

IPv6 is provably faster, especially for mobile clients. iOS 9/10 also prefer it and the App Store has begun requiring apps to work on full v6 stacks, meaning any end points in AWS will require 6to4 somewhere.

I don't understand the AWS fetish either. I guess nobody ever got fired for using AWS. It's the IBM of the cloud.

If you need managed services Azure and Google Cloud are largely better. If you just need compute and transfer Digital Ocean and Vultr absolutely destroy AWS.

DigitalOcean and Vultr destroy not just AWS on network traffic costs, they destroy all three of them by an absurd margin. I have no explanation for that huge gap. It's the great mystery of cloud computing.

I've never heard of Vultr until today. Have you used it? Can you tell more about it?

I am using Vultr, but the particular project I'm using it for doesn't put a whole lot of strain on their infrastructure yet.

So far it's been working well and support was very responsive on the one occasion when I needed their help.

Samething as DigitalOcean without the hype.

5$ SSD VPS, 768M of Ram instead of 512 at DO, the reason I moved in at first.

The popularity clearly helps DO keeping up with more 1 click apps and other features than Vultr, but they recently made available reserved IPs and Object Storage, so they continue to be a good alternative to DO.

As others have said, similar to DO. It has a few more options available, though, including better support for booting your own OSes if you don't want to use a prepackaged one, and dedicated instances (last I checked DO didn't do either, but haven't looked for a bit, might be out of date). I've also found their support to be more willing to work with me to get things running how I want, but that's obviously just anecdotal.

The thing I really like about Vultr is that to use their site, you just have to enable Vultr.com (in NoScript). For DO, you have to enable 15-20 domains because they use all kinds of outsourced services, and every time you go to a new page, there are new things that have to be enabled. I got tired of it.

Very much depends what you are actually doing in the cloud.

The huge gap is easy: there is significant security in place at the big 3 that DO and other vendors simply do not have.

Google's security team is probably as big as DO's engineering team.

That's not why <cloud provider> networking is so much more expensive than a VPS provider... All of the big providers have fairly serious networking investments (and I think it's fair and honest to say that Google's is the largest) that provide a network quality and performance you won't match with any VPS provider. Do you want to stream more than 100 Gbps during the Olympics to people all over the world? Don't try that on OVH, DO, etc. but you can do it on us. We (Google) in fact charge more than AWS for our networking because of our massive global network.

tl;dr: you get what you pay for, and you don't always need our crazy network!

I understand that in principle, but before paying the big cloud providers between 10 and 20 times what I would be paying Vultr/DO (for network traffic), I would like to know a great deal more about the actual performance difference.

I know it's probably on me to find that out myself.

There's an entire industry of companies and analysts willing to sell you that information :)

Interesting... so with Google and Amazon and the like I am paying more for the existence of capacity that I could hypothetically utilize?

DO and Vultr are colocated at very large sites. For many locations they sit right next to carrier hotels. I am a bit skeptical of whether the real world difference is that huge, especially if I sprawl my endpoints across both these providers and many locations.

The gap is that you are expected to serve most of your traffic through their blob stores and CDNs, not through the compute instances.

The traffic prices for each of these are very different.

In that case I can just use S3 for blobs and use Digital Ocean and Vultr and Linode for compute. Amazon charges $0 for bandwidth ingress so uploading to S3 costs me nothing.

We use VPS providers for compute and S3 for backup and large blob storage. The only other Amazon product we use is Route 53, which is a decent DNS-as-a-service and is very reliable.

Of course. The trick is to decide what mix of lower price and lower complexity is your sweet spot.

Disagree on compute, actually - specifically, AWS Lambda is great. Its lack of Python 3 support certainly is the thing that pisses me off the most across the whole AWS stack but that's also because it's my favourite there. It's fantastic for on-demand distributed computing, and really cheap.

Azure functions seems similar enough and a bit easier to adapt, though the runtime is windows based, so it's easy enough to include other executables.

What I'd really like to see is Compose.io's full product lineup on Digital Ocean already. As it is, I'm considering seeing how well Azure Tables, and Azure SQL work from DO SFO2 to Azure West US...

Would really love to hear what makes Azure "largely better". My own experience is far from that. I have yet to meet anyone not relying heavily on moving over a MS stack or that has gone beyond the "hit a template to deploy a test" use case that really likes it. When I get folks down to the brass tacks, it tends to boil down to "I don't have to pay the overhead of the Windows license anymore" or "I like having MS services as a PaaS".

On the other hand there are a lot of inconsistencies and odd limitations on the services.

I echo your sentiments. I run Azure in production at my job, running both Windows and Linux stuff and constantly run into weird edge cases, inconsistencies and stuff that just doesn't make sense.

There's really only one thing I can think of that I love is resource groups. It's nice to be able to group together everything in a deployment, for quick access and administration.

Its simple - moving to the cloud at all is a big risk for some executives. They don't want to compound the risk by going with anything but the leader.

The Lambda UI used to be atrocious: You couldn't resize the multiselect for subnets.

My main nemesis now is the ElasticSearch dashboard. Just opening it gives me a 50-50 chance of my browser tab crashing.

Why do you think Cloudformation sucks?

Because massive json files with pseudo-invocation syntax and a ton of gaping issues that aren't readily solved by pre-existing template solutions pauses for breath and just bizarre decisions about holding and fielding and really poor integration with new services (you can tie ECS clusters in a knot with CF trivially) and API call limit hits KOing CF provisioning jobs and...

I mean, what it's doing is hard and I use it over, say, Chef... but it's not a "good" product. Heck, you cannot even truly validate CF templates without running them. The CLI and builder just do a crude structural check pass. Got a case error in a nested structure? Too bad, the entire job is rolling back.

While we're on the subject, I want to mention terraform (https://www.terraform.io/).

I'm not going to straight up recommend using it, but I will recommend checking it out. It's certainly a lot better than CF, but it still has really glaring issues and very much feels like alpha software (see discussion here: https://news.ycombinator.com/item?id=12213935 and some of my complaints here: https://news.ycombinator.com/item?id=12214358).

I am on the opposite fence. I also comment on the recent Terraform discussion. Basically the abstraction layer is too complex; why not template JSON and build the cloudformation stack? In the end, nested CF stack is still, a hard problem.

Why do you think the abstraction layer is too complex? I found terraform was essentially designed with AWS as a first-class citizen (if not for AWS in the first place), which means everything maps really well.

I strongly dislike HCL, but that's essentially what it is - templated JSON.

Not the parent, but for one, doing a CF update is all-or-nothing. Either you roll the whole thing out, or you roll the whole thing back. If you have a lot of servers, and things are going down, you want to just STOP. But you can't. Also, if you click too quickly, sometimes you can get into a weird state and not be able to rollback OR update anymore.

Same thing happens with other tools like Terraform though: once you've kicked off an apply, you are committed.

yeah, but having the option to run 'terraform plan' really helps you know what you're getting yourself into.

We've had Terraform take action that wasn't in the plan, in production.

I call it "pray and apply".

https://news.ycombinator.com/item?id=12214879

BOSH is able to cancel operations. You press Ctrl+C and it asks if that's what you intend.

CloudFormation change sets make CF updates a little less painful/mysterious:

https://aws.amazon.com/blogs/aws/new-change-sets-for-aws-clo...

changeset is very limited. when you have sub stack, change set cannot detect thing change in sub stack :(

I think this behavior is sensible. Additionally, you can disable rollback. However, cloud formation has needed and lacked a "dry run" option for a long time. It would be really nice to have that. However, the documentation does indicate what effect an update on any given resource will have.

I recommend against making sweeping changes to your infrastructure without thoroughness. Without saying this is what you're doing, I see a lot of developers who get involved with cloud treating changes whimsically. I'm not saying you should write perfect code. But thoroughness and a solid procedure (and backup plan) is a good place to start.

dry run for cfn == create change set :-)

(also, it helps to use nested stacks)

There are a few issues: stacks sometimes partially complete and you are left with a bit of a mess; stack creation has insanely long timeouts and a lot of retries, so it often sits there for 15 minutes before eventually failing; and deletions can fail part way through because there is some dependency that isn't obvious (and which they don't make it easy to find). I still like it (infrastructure as code is cool), but it needs more work.