[KaiserPro]

I know many people will disagree, but I really miss the VMware fat windows client. (vsphere 5, before they ruined it with the weird flash hybrid that didn't work properly)

That, was a paragon of design reliability and speed compared to the AWS console.

What annoys me the most is the sheer weight of each page. If you have to context change, its multiple seconds before the page is useable.

A classic example is lambda. I click on the function, page reloads (no problem) 1-2 seconds later the page is fully rendered, I can _then_ click on the monitoring tab, another couple of seconds, and then I can jump to the latest log, in cloudwatch.

Cloudwatch can get fucked. Everything about it is half arsed. Search? all of the speed of splunk, combined with its reliability, but none of the usefulness.

The standard answer is "you should use Cloudformation" I do, it too is distilled shart. (anything to do with ECS can cause a 3 hour, uninterruptible hang, followed by another timeout as it tries to roll back.)

It also lazy evaluates the acutal CF, which means that parameter validation happens 5 minute in. Good fucking job there kids.

What I really want is a QT app in the style of the VMware fat client (you know with an inbuilt remote EC2 console, that'd be great...) that talks to AWS. The GUI is desgined by the same team, and is _tested_ before a release by actual QAs who have the power to block things until the change is released.

[calcifer]

> anything to do with ECS can cause a 3 hour, uninterruptible hang, followed by another timeout as it tries to roll back

This is the single largest problem with ECS and the fact that neither the containers team, nor the CloudFormation team have paid any attention to the problem after who knows how many years is incredibly frustrating.

And 3 hours is actually one of the better cases. 10+ hour hangs that can only be cancelled / rolled back by contacting support are joyous occasions.

[mysterydip]

Agreed on the VMware fat client. At the time I was a VCP and used it daily as a consultant. It wasn't just not wanting to change; the old client was so much more responsive.

[lostmyoldone]

When I was messing with CF, AWS, and the kitchen sink to make sure I could track/retrieve the state of every single resource we used, I came across the JSON equivalent of Cthulhu. It had JSON as a string in a JSON attribute, recursively 2 to 4 times. I don't recall exactly. Sat there laughing, and cursing, as one might when you stare down into the purest of horrors ...

[kristianpaul]

You know that nothing stops you from using aws apis and making you own UI right?

[omni]

In many cases AWS's absurd rate limits would make it hard to build a functional UI even if we wanted to. I imagine this is one major reason why list views and filtering/searching them is a disaster in every major AWS service.

[cthalupa]

If you're building your own management tools, I'd probably suggest persisting the data in your own system as well, rather than constantly hitting the AWS APIs. 10 users going to your tool to look at EC2 instances at the same moment don't need 10 different calls to AWS. Have your management tool query the API once, and persist the data for a period of time. It all being json responses makes this a fairly reasonable and easy use case for mongodb or postgres.

[omni]

A management UI showing me stale data sounds like a terrible experience, honestly

[cthalupa]

It works well enough for Netflix - https://medium.com/netflix-techblog/edda-learn-the-stories-o... - and Target ( https://tech.target.com/2017/04/07/how-and-why-we-moved-to-s... ) :). I've only ever used Edda as part of a Spinnaker setup, but there's no reason it couldn't be used with something else, or the same idea in general reused.

You don't have to cache it for very long, but you get two benefits here: Being able to query the data and search through it ways you simply can't do when making an API call to AWS, and having primarily only one system munching through your API throughput limits. If you've got a large account with a lot of resources and a lot of people or systems that are querying the API frequently, you'll probably have more consistently available data, rather than having systems sitting around doing retries and getting throttled there, on repeat.

[omni]

Just wanted to say thanks for replying with these links!

[doliveira]

Yeah because AWS is free and we don't have any right to complain.