4 ms·

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 wor

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.

kristianpaul 7y ago
You know that nothing stops you from using aws apis and making you own UI right?
- doliveira 7y ago
  Yeah because AWS is free and we don't have any right to complain.
- omni 7y ago
  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 7y ago
    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 7y ago
      A management UI showing me stale data sounds like a terrible experience, honestly
      - cthalupa 7y ago
        It works well enough for Netflix - https://medium.com/netflix-techblog/edda-learn-the-stories-of-your-cloud-deployments-ade4f4edd9cd 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-spinnaker.html 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 7y ago
        Just wanted to say thanks for replying with these links!
mysterydip 7y ago
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.
calcifer 7y ago
> 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.
lostmyoldone 7y ago
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 7y ago

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

doliveira 7y ago
Yeah because AWS is free and we don't have any right to complain.
omni 7y ago
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 7y ago
  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 7y ago
    A management UI showing me stale data sounds like a terrible experience, honestly
    - cthalupa 7y ago
      It works well enough for Netflix - https://medium.com/netflix-techblog/edda-learn-the-stories-of-your-cloud-deployments-ade4f4edd9cd 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-spinnaker.html 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 7y ago
        Just wanted to say thanks for replying with these links!

mysterydip 7y ago

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.

calcifer 7y ago

> 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.

lostmyoldone 7y ago

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 ...