[Waterluvian]

Aws feels like it was built by a bunch of siloed teams. There's a lot of design inconsistency I notice every time I'm in the console. For example, deleting entities is never consistent. Some just do it, some ask you to type in the name, some as you to type "delete me".

Some entities have a name and a description field that are immutable on creation, even though they also have a unique id. I now have drop downs everywhere that list "Rds creation wizard VPC" or something long those lines.

Its not clear what fields are drop downs so I have to type stuff into them to see if they'll give me a list of options.

The UI uses the same styles but inconsistent language. In ECS there's a list of entities. To delete an entity you have to go into it and delete all its children. Then the entity disappears.

I know there's engineering reasons for all this, but I feel like they can do better than settle for engineer grade UI.

[binarymax]

AWS was built by a bunch of siloed teams. In the mid 2000's there was a mandate for each separate infrastructure team to open their infrastructure as a service, and they were given tight deadlines. This was meant to solve internal issues but was opened up to the world and AWS was born.

[timfrietas]

This is a bit of a myth.

Yes, there was a mandate for everything to be SOA. However, AWS built almost every service from scratch. For example, S3 and EC2 were NOT used for production in Amazon until well after launch (it was a huge migration when the company did it years later).

My team built a world class transcoding service for video and were surprised to find later that AWS had built it's own (much less good) transcoding service. As part of that we also built a 5-10x optimization to multi-part fully-encrypted S3 uploads with a user-friendly client and the response from the S3 team was a shrug, they just weren't interested.

It is actually really common at Amazon for five teams to be building almost the same thing. Some of it is on purpose as a sort of insurance policy or bake-off.

But almost every AWS service was built in the AWS org, even if there was something similar in place at Amazon, at least when I was there (2006-2015).

[ben509]

> Yes, there was a mandate for everything to be SOA. However, AWS built almost every service from scratch.

I think it's more true than false though; tldr: there was effectively a super-fugly internal set of services that were the prototype for many of the real AWS services.

Some of the computing capacity AWS itself used was built on the internal services that Amazon had been using. Provisioning capacity on those internal services required weeks as the API was very primitive compared to EC2. I think also it wasn't until VPC became quite stable that they could start to move Amazon to AWS.

So for a long time, you essentially had AWS service teams having to file paperwork for capacity (decommissioning capacity could sit in a queue for months just like in a regular data center) while AWS customers could spin up capacity via EC2. As you can imagine, AWS would build on AWS, and then they promptly ran into problems when they had to stand up new regions because they had dependency cycles... There was also a ton of tooling built around requesting all the capacity and dependencies, and maintaining the configuration for all that.

So the SOA story is really that there were a bunch of AWS-like services that were absolutely awful, and those were often the prototypes for the AWS services themselves. And many services like Lambda are now possible because they've been solving all the obscure security issues and dependency problems associated with having AWS be their own customer.

For instance, the genesis of one service was that a large customer was using EC2 and had some specialized hardware; they were big enough they said, "hey, we'd like to move this hardware out of our datacenters" and AWS stood up an incredibly primitive service that literally routed some specialized racks into this customer's VPCs. There was no API, you'd email the service team and they'd run some scripts. That's gradually morphed into a real service that's unrecognizable from the early days.

[mountainofdeath]

This is true. Each team owns their service end-to-end. It just happens that the console is usually an afterthought. Something to be left for the interns to work on.

The funny thing is, some of the AWS services are indeed quite primitive compared to their Amazon internal equivalent.

[mirceal]

Hah. Guess it depends on what siloed means. With a certain size you need to figure out ways of aligning/comunnicating things - whole AWS is probably thousands of people. You will get siloes.

On top of that: it’s not like all services were build at the same time. Some of them are the “bedrock” of Aws (S3, EC2), some of them are experiments that went viral.

On top of that: Aws is meant to give you building blocks. The magic happens at API/sdk level. The console is there to help you discover and play with the service in a few basic scenarios (and to maybe observer your resources). If you click your way through settings things up you’re going to probably have a bad time.

[auslander]

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

[scarface74]

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.

[auslander]

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.

[erik_seaberg]

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

[scarface74]

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.

[erik_seaberg]

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.

[Waterluvian]

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.

[erik_seaberg]

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.

[jedberg]

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.

[Bellyache5]

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.

[jedberg]

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.

[QuinnyPig]

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

[megalodon]

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.

[QuinnyPig]

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

[eeeeeeeeeeeee]

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.

[granshaw]

I feel like AWS’s MO is to eschew things like usability and consistency in favor of getting features out as quickly as possible. Perhaps it doesn’t have to be an either/or, but as an observer from outside the org, it’s hard to know

[eeeeeeeeeeeee]

You can still have siloed teams, and I think you need them in this case. AWS has many different products and they don't all relate to each other. It sounds like they simply need to adopt some UX/style guides and enforce them across the company.

[avip]

To state the obvious, you really should not be using that console to do anything. Basically browsing the console is already technical debt.