Hacker News new | ask | show | jobs
by Terretta 2475 days ago
Noting your verb tense, “I was”, I’m assuming you’re no longer in that role. This isn’t feedback, just discussion.

I talked to Jassy after his keynote in 2018: “Your message says AWS is for ‘builders’. Why do you keep saying ‘just click and ...’ instead of ‘just call the API and’?”

In short, to your point: AWS is for builders... who pay. And right now all the growth is in enterprise, where we don’t know how to make API calls from a command line.

We don’t know how, because two decades of IT practices and security practices made sure we couldn’t make API calls from a command line. (No access to install CLI tools, no proxy, firewall rules from the S3 era still classify AWS as cloud storage and block it, etc.) So we can’t adopt AWS at all if that’s the only path in. But our proxy teams can figure out how to open a console URL. For this market, giving a point and click web page with magic infra behind it is a big deal: the modern ‘service catalog’.

So I think he’s right, that’s the dominant use case by dollar count and head count, and he’s speaking to those deciders.

At the same time, I think it’s terrible when capabilities show up in the console first or only, as the infra-as-code builders can’t code infra and services through the console.

So to anyone following along from a team with two pizzas: invest in the UI, but please nail the APIs first, and then use those from the console. Keep yourselves honest to the Bezos imperative from 15 years back: if you want it in the console, so do IaC developers, so let there be an API for that.

8 comments

So we can’t adopt AWS at all if that’s the only path in. But our proxy teams can figure out how to open a console URL. For this market, giving a point and click web page with magic infra behind it is a big deal: the modern ‘service catalog

And then your bean counters are going to be rightfully confused about why they are spending so much more on infrastructure when “they moved to the cloud” without changing their people and/or processes.

But then again, they probably listened to some old school net ops folks who watched one ACloudGuru video, passed a multiple choice AWS certification, called themselves “consultants” when all they were were a bunch of “lift and shifters”.

The AWS APIs documentation is excellent, I have no qualms with it, other than some inconsistencies in payloads/naming across services.

The console should be for exploration/discovery and if you're actually building production infrastucture by pointing and clicking, well, shame on you.

> In short, to your point: AWS is for builders... who pay. And right now all the growth is in enterprise, where we don’t know how to make API calls from a command line.

Infact AWS's HSM devices intentionally don't have an API, as "security feature."

Most AWS services' console/API are 1-1. Occasionally a console might offer some convenience features which are just a combination of API calls, but I'm not aware of any service that has functionality solely offered in the console. As the original comment touched on, this would be really unusual in AWS where most attention goes to the APIs/SDKs which are what larger customers use.
>but I'm not aware of any service that has functionality solely offered in the console

Historically, there have been some big ones, including some features related to pretty core services - I am fairly sure some autoscaling related features were console only for some time before an API was added. Instance limits were a console only feature for a year or so before DescribeEC2InstanceLimits was a thing.

It's not just historic examples, either.

Basically all of Quicksight outside of group/user management lacks an API today. Which is particularly annoying for some of my use cases, since the more technical folks generally will use Athena directly, and the people that want to use quicksight to examine the data are the ones that are less technical, which means needing other people to go and manually configure data sources, setup refresh schedules, etc. I'd love to be able to shove all of that into cloudformation and do it programmatically, but since it lacks APIs to begin with, I can't do it in cloudformation even as a custom resource via lambda.

Lots of features within Amazon Connect are console only.
There are definitely some API-only things. Mostly edge cases. For example, last week I ran into the fact that it's only possible to associate a Route 53 Hosted Zone with a VPC from a different account via the API.
Your parent comment is stating the reverse. That there is no web console only features.
>In short, to your point: AWS is for builders... who pay. And right now all the growth is in enterprise, where we don’t know how to make API calls from a command line.

I work pretty extensively with enterprise companies that are on AWS, and most make significant use of the APIs and command line. Lots of these companies are ones that I am helping move to AWS, and their teams are frequently excited at being able to utilize the command line and API as much as possible.

>We don’t know how, because two decades of IT practices and security practices made sure we couldn’t make API calls from a command line. (No access to install CLI tools, no proxy, firewall rules from the S3 era still classify AWS as cloud storage and block it, etc.) So we can’t adopt AWS at all if that’s the only path in. But our proxy teams can figure out how to open a console URL. For this market, giving a point and click web page with magic infra behind it is a big deal: the modern ‘service catalog’.

This also sounds pretty crazy to me. It's not a situation I've ever spoken to anyone in, and quite frankly: If your security and networking teams are unable to figure out how to open access to API endpoints that are all documented, you need new people on those teams. It's also certainly possible to proxy the API and command line calls to these endpoints, as well.

>So to anyone following along from a team with two pizzas: invest in the UI, but please nail the APIs first, and then use those from the console. Keep yourselves honest to the Bezos imperative from 15 years back: if you want it in the console, so do IaC developers, so let there be an API for that

I 100% agree with this, though. I want APIs for everything, but a lot of people like the console for discoverability and gaining familiarity - not everyone can grok what something is from reading the API documentation as they can from poking at it with the console, even if they ultimately do end up managing it elsewhere. Build great APIs, build a great console on top of those APIs, and everyone is better off for it.

> If your security and networking teams are unable to figure out how to open access to API endpoints that are all documented, you need new people on those teams

Careful, it's not yet 100% possible to do this 100% securely today across all endpoints for all services. Getting closer though.

> This also sounds pretty crazy to me. It's not a situation I've ever spoken to anyone in...

This would seem to disqualify much of your comment. Have a chat with AWS Pro Serv members handling accounts of companies with billion dollar IT budgets.

> I work pretty extensively with enterprise companies that are on AWS...

Most enterprises are not on AWS. That's where the growth will be, and who my comment is about.

>This would seem to disqualify much of your comment. Have a chat with AWS Pro Serv members handling accounts of companies with billion dollar IT budgets.

I work with companies that have budgets that large. Your situation still sounds very atypical to me.

>Most enterprises are not on AWS. That's where the growth will be, and who my comment is about.

I mean, maybe if you take that out of context and ignore the part where I say 'Lots of these companies are ones that I am helping move to AWS'...

Google's cloud put a CLI in the web console. Its hilariously ironic but it solves for this, I suppose.
As did Azure, quite some time ago. Many docs articles say go to the azure portal and open the web console to continue this set of instructions
So did AWS. See https://aws.amazon.com/cloud9/

Not just a shell but a robust IDE in the cloud.

Cloud9 is amazing but it is not anything like a shell for use with the AWS API. It’s, like you said, a robust IDE. Not a terminal emulator.
> firewall rules from the S3 era still classify AWS as cloud storage and block it

For all of the major data leaks from S3 buckets, I suspect the existence (and persistence) of these firewall rules across the industry is a principal reason why there haven't been significantly more of these leaks.

My frustration is more commonly the opposite.

Adopt an AWS service through the console. Then discover advanced feature [X] can only be done from the CLI via APIs.