Hacker News new | past | comments | ask | show | jobs | submit login

Console is just for checking stuff. Real infra is managed by APIs.



The “No True AWS Guru” ( https://en.wikipedia.org/wiki/No_true_Scotsman) argument...

I don’t think I’ve ever used the CLI to manage infrastructure on AWS.

I usually use the console for one offs. When something needs to be repeatable, I’ll create a Cloud Formation template.

Anything that’s more conplicated, I’ll either use Python directly or create a custom resource that gets called from CF.


Yes, Cloudformation is my main tool too. I just simplified my comment. Read it as managed by code, be it CF, python, awscli from shell, and all of it in the end boils down to specific API calls.


The key thing is a repeatable process that's checked in, which pointing and clicking in the console is not.


Not always.

For instance we have a process that sends sns messages for alerts. It’s just as easy to go into the console and subscribe to the sns event notifications (emails and sms).

Second example. I initially configure passwords with CF (of course with parameters that are added when you run it.) It’s easier to go into the console afterwards to change passwords as it would be to update the stack and renter the passwords.

You aren’t going to store passwords in source control anyway.


For SNS I'd use the API just to make sure every new team member gets signed up for every appropriate deployment (test, prod, whatever) and every old team member gets removed.

I agree it doesn't add much value for a single user rotating their own password.


The console is absolutely indispensable. You need it for your majority of aws users who are doing it for the first or second time. You need it for quick lookups, prototyping, experimentation.

Then when you have the Lego design you want, yes, you whip out cloudformation or bash scripts or Python scripts or ansible or whatever else.


I was astonished to learn that you can sort of scrape your from-console resources into a CloudFormation template, but you cannot get a stack to manage them inplace. Instead you have to blow them away (manually!) and have CloudFormation create a new stack from scratch, because it only touches stuff it created with hidden stack tags.

Terraform import is pretty painful but at least it can handle this.


Not every service has an API, especially new ones. They tend to launch things console first. Look at Alexa. It took over a year to get API, and it still doesn't have CloudFormation support.


I don’t think Alexa is considered an AWS product/service. While you need AWS’ Lambda to make it work, Alexa is an Amazon (versus AWS) product.


Ok, fair point, but you can see the same pattern with other services. Look at any of the AI services for example. Everything was console first.


For some. For others it’s indispensable. “You should be smarter” isn’t something I’m prepared to tell newcomers to AWS.


I've been to two AWS Summits (Stockholm) and most if not all AWS employees explicitly point out that you should never use the console for anything serious. It might be good for presentations, but it's horrible when you need to manage infrastructure.


Right. And "here's a thing we make available to you but it's horrible and you should never use it" is terrible messaging.


That's not accurate. There are some things you cannot even do in the API and it must be done in the console. I agree with others here that you should be using Cloudformation as much as possible, but even that isn't 100% supported and sometimes you need to click around the console to set things up.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: