9 ms·

These comments are fascinating to me. I was responsible for designing, leading, and building the frontend for an AWS service. One of the challenges was with ob

These comments are fascinating to me. I was responsible for designing, leading, and building the frontend for an AWS service. One of the challenges was with obtaining useful feedback from a diverse range of people. During the product definition phase, the majority of the feedback, input, and feature priority was for customers who were planning to dedicate a large budget towards using said service. I often felt that stakeholder decisions sacrified usability for feasibility. Regardless, it was the responsibility of my service team to seek and obtain feedback, input, and data points that could help us inform our decisions. But from what I witnessed, it only went as far as to validate our exisiting concepts and user personas of how people use AWS services. Going beyond that was seen as unnecessary. The universal thinking within AWS is that people will ultimately use the API/CLI/SDK. So, investment into the console is on a case by case basis. Some services have dedicated engineers or teams to focus on the console, but most don’t. I’m proud of what I built. I hope that my UI decisions and focus on usability are benefiting the customers of that service that I helped build. A little known fact, in the AWS console exists a feedback tool (look in the footer) that will send feedback straight to the service team. I encourage you to submit your thoughts, ideas, and feedback through that tool. There are people and service teams who value that feedback.

SomeHacker44 7y ago
I personally dislike the CLI until I am very familiar with the AWS service I am learning or in early phase if using. Even then the CLI is usually a last resort. The Web UI is much more discoverable and understandable than having three terminal windows and a web browser open to figure out what to do with whatever random long ID on the CLI. Assuming everyone, even extremely experienced AWS users like me, will just use the CLI seems like a mistake.
- scarface74 7y ago
  I use the console for discoverability, proof of concepts, and quickly reviewing what’s going on. But for any real resource creation, I will then duplicate the steps with CloudFormation or a Python script (or both) and once I verify it, tear down the manually created resources. The only time I find the CLI useful is for S3.
scarface74 7y ago
The only part of the console that I absolutely hate is dealing with the Parameter Store. But I hate everything else about the parameter store too so there is that. CodePipeline is pretty bad too. There is no way you can create a cross account code pipeline from the console.
- baseballMan 7y ago
  CloudWatch log filters are pretty bad too. I basically just use ctrl + f now in cw logs to find what I'm looking for.
  - scarface74 7y ago
    Oh yeah. They are horrible. I agree completely. For C#, I use Serilog for logging to both a Cloudwatch sink and a ElasticSearch sink. Before I’ve used a Mongo sink.
  - eropple 7y ago
    Emit your logs in JSON for structural search and use CloudWatch Logs Insights. It's actually really very good these days--we have an ELK cluster because the team is used to the Kibana interface but I rarely if ever use it.
  - cloakandswagger 7y ago
    I haven't had this problem. For simple string searches CloudWatch returns exactly what I'm looking for, even for partial word matches, and for more complicated queries there is the excellent Insights feature.
- nostrebored 7y ago
  Cross account setups from the console are generally not allowed.
  - scarface74 7y ago
    You can assign cross account permissions for S3, sharing AMIs, sharing KMS keys, SNS permissions, etc.
notimetorelax 7y ago
Can you address user complaints about resets to the root view and non functioning sorting? Both seem to be bugs and single user report should be sufficient to identify and fix the issue. I think you make it look more complicated than it is.
postit 7y ago
> universal thinking within AWS is that people will ultimately use the API/CLI/SDK ( ͡° ͜ʖ ͡°) - But still 99% of tutorials and documentation refer to the UI.
- lentil 7y ago
  To be fair, the AWS documentation nearly always covers both.
  - rolltiide 7y ago
    an outdated version of both. Here's a bunch of buttons! What do you mean you didn't install the CLI, discover your system has mixed up versions of the package manager, and finally get around to running this convoluted command, after you learn how to get a list of IDs from your organization with the CLI
    - nostrebored 7y ago
      The AWS cli is a simple pip install and the CLI documentation nearly universally includes samples. Input and output can be JSON. There are a lot of legitimate complaints about AWS but the CLI is pretty decent.
      - rolltiide 7y ago
        It has a steep learning curve. Every time something new roles out and AWS doesn't have a button for that one thing, your static site trying to follow the best practices now needs to know this and have python package managers installed and updated. I would say it is a legitimate complaint, it is a horrible user experience amongst people who aren't even considering what other people would think of it.
        jasonlotito 7y ago
        > It has a steep learning curve. I mean, I guess if you are new to AWS entirely. I find the documentation for most things accessible and easy. For the things I want more information on or I'm not clear, support is fairly quick to help and point to the documentation. Most of the time it's the documentation I skipped because I assumed I knew it.
Terretta 7y 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.
- cloakandswagger 7y ago
  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.
  - lukev 7y ago
    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.
pmart123 7y ago
Interesting. I’ve always found it befuddling as a generalist with a relatively high learning curve. I gave it the benefit of the doubt until Google Cloud started rolling out its updates with far better documentation and interfaces. That said, AWS has way better customer support.
- jrochkind1 7y ago
  I bet GCS docs will not keep up with changes to GCS very well either, judging by other Google docs. Start out good, don't keep up with changes. AWS docs are relatively good at keeping up with changes.
  - cameronbrown 7y ago
    Google's docs are the most inconsistent. The newer the service the better the documentation in my experience. The App Engine docs are like a rats nest, but the Firestore docs are really well done.
    - pmart123 7y ago
      My guess is they now care a lot more about Google Cloud than previous product endeavors. I’d also guess that people at Google would put in a ton of effort on documentation to avoid having to speak to people on the phone.
afpx 7y ago
Approximately how much does one have to spend per month to get prioritized feature improvements? We spend about $200k per month, and AWS treats us like we’re unimportant. I would like to try Azure or Google a try, but neither seem to make it easy to transfer Petabytes.
- nkozyra 7y ago
  I wouldn't expect those services to offer you much more personal attention, honestly.
  - camtarn 7y ago
    Amazon does have vendor and seller managers who are allocated to specific vendors/sellers. I'm surprised that for a $2.4M/year AWS customer (presumably with the highest support level) that they wouldn't have a similar setup. That said, having personal attention from a manager is definitely not the same as getting features actually built for you.
    - taude 7y ago
      I agree, at 2.4M/year, i'm surprised you don't get more. we spend about 150k/month on Azure services, and it seems like we get a lot more service and roadmap influence....
      - cthalupa 7y ago
        In my experience a lot of it comes down to how effective their account team is. A good one will communicate with and work to influence the product management at AWS and set up meetings to discuss things as necessary. A bad one can get feedback from the customers they are assigned to and never do anything with it, or send off an email and never follow up.
    - nostrebored 7y ago
      With the highest support level you do receive TAMs and Solutions Architects within AWS. They can add feature requests and make sure that influence is added for you and follow up directly with Product Managers to explain why a feature is important. But, sometimes a high amount of spend on a service isn't really much more than the average. For instance, if you spend 200k/mo on a niche service then you'll get a ton of say in how things move forward, but if you spend 200k/mo on EC2 you might not be able to strongarm anything.
Sir_Cmpwn 7y ago
The API sucks, too, though, when used from the command line. Every non-automated way of interacting with AWS is like pulling teeth, and in reality most people do this all the time. You can't automate a process you've never done manually, and you don't necessarily want to invest in building out an automation which you only need to do a few times. It's like AWS's excuse is "we offload the problem of a good UI onto our users", which in my opinion is really stupid. All it would take is one UI team which made common tools and standards for UI design and applied them throughout. The API has a consistent design throughout, so why not the UI?
shepardrtc 7y ago
I think that the vast majority of UI's in AWS are perfectly fine. But there's one that drives my entire team insane: the AWS Parameter Store Holy mother of god, the search on it is horrific and simply doesn't work. Heartfelt begging through the feedback tool goes unanswered. I have offered money, firstborn children, sacrificial goats, virtually everything. But the search is still broken :( I've had to scroll through a hundred pages of parameters to find things.
- scarface74 7y ago
  Parameter Store is such a god awful experience via the UI. But everything about parameter store is awful. - severe unchangeable, undocumented limits before you get throttled. Throttling is so bad that if you have too many parameter store resources in your CloudFormation template it will start causing errors because CF is trying to call the API too quickly - the only way around it is to use DependsOn and chain the creation. - no way of creating an encrypted value with CF without a custom resource. We ended up just using DynamoDB for config anda Custom CloudFormation resource to create values in it. You should never depend on Parameter Store as a reliable key/value store for configuration.
  - shepardrtc 7y ago
    We've hit the throttling issue many, many times. Everything about Parameter Store is difficult. And its a shame. Its such a simple concept. They have enormous resources, so why not throw a couple of devs at it? In any case, we do also use redis. It might be worthwhile to pitch an idea to move over to that. But we pull the parameters in bash scripts using a custom tool called aws-env, so we'd probably have to make or find something similar for redis.
    - cthalupa 7y ago
      https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-store-throughput.html https://docs.aws.amazon.com/systems-manager/latest/userguide... I believe this is a new(ish?) feature, but someone from AWS Support recently pointed it out to me when dealing with throttling issues. Might be of interest to you.
tootie 7y ago
Maybe I'm just being overly sympathetic, but having worked on UIs with complicated UX, I know how extremely hard it is to get right. Especially with something so complicated and sprawling as the AWS console. There's plenty of irritations, but the fact that it works as well as it does is amazing.
throwawaywego 7y ago
Persona of a person wanting to study AWS for commercial projects at one of AWS's biggest clients: - Create account. Enter credit card details, but verification SMS never shows up. Ask for help. - I get called at night (I'm abroad) by an American service employee, we do verification over the phone. - Try to get the hang of things myself. Lost in a swamp of different UI's. Names of products don't clarify what they do, so you first need to learn to speak AWS, which is akin to using a chain of 5 dictionaries to learn a single language. - Do the tutorials. Tutorials are poorly written, in that they take you by the hand and make you do stuff you have no idea what you are actually doing (Ow, I just spun up a load balancer? What is that and how does it work?). - Do more tutorials. Tutorials are badly outdated. Now you have a hold your hands tutorial, leading you through the swamp, but every simple step you bump your knee against an UI element or layout that does not exist in the tutorial. Makes you feel like you wasted your time, and that there is no one at AWS even aware that tutorials may need updating if one design department gets the urge to justify their spending by a redesign. - Give up and search for recent books or video courses. Anything older than 3-4 years is outdated (either the UI's have changed, deprecated, or new products have been added). - Receive an email in the middle of the night: You've hit 80% of your free usage plan. Log in. Click around for 20 minutes, until I find the load balancer is still up (weird, could have sworn I spun that entire tutorial down). Kill it, go back to sleep. - Next night, new email: You've gone 3.24 $ over your free budget. Please pay. 30 minutes later: We've detected unusual activity on your account. 1 hour later: Your account has been de-activited. AWS takes fraud and non-payment very seriously. Now I need a new phone number/name/address to create a new account. I am always anxious that AWS will charge for something that I don't want, and can't find the UI that shows all running tutorial stuff that I really don't want to pay for. I know the UI is unintuitive, non-consistent, and out-of-sync with the technical - and tutorial writers. And I know that learning AWS, consists of learning where tutorials and books are out-dated, or stumbling around until you find the correct set of sequences in a "3 minutes max." tutorial step. AWS has grown fat and lazy. The lack of design - and onboarding consistency is typical for a company of that size. Outdated tutorials show a lack of inter-team communication, and seems to indicate that no one at AWS reruns the onboarding tutorials every month, so they can know what their customers are complaining about (or why they, like me, try to shun their mega-presence). (EDIT: The order of my experiences may be a bit jumbled. Sorry. More constructive feedback: 1) I'd want a safe tutorial environment, with no (perceived) risk of having to pay for dummy services. 2) I want the tutorial writer to have the customer's best interest in mind: "For a smaller site, load balancing may be overkill, and can double your hosting costs for no tangible gains." beats "Hey Mark, we need more awareness and usage on the new load balancer. I need you to write a stand-alone tutorial, and add the load balancer to the sample web page tutorial." 3) Someone responsible for updating the tutorials (even if: "This step is deprecated. Please hold on for a correction") 4) A unified and consistent UI and UX. Scanning, searching, sorting, etc. should work without making me think, I don't want a different UI model for every service. Someone or some team to create the same recipes and boundaries for the different 2-pizza teams, so I don't get a pizza UI with all possible ingredients.)
thayne 7y ago
I primarily use the api to create and manage infrastructure, but I still use the console to view my infrastructure, and it is pretty painful.
robbyt 7y ago
I'm honestly surprised there was only one team in charge of UX for the AWS gui. It always felt like each product did their own UX because of all the various inconsistency between different areas. I don't have any examples off-hand, but anyone who's used it would probably agree with me. For the record, I think the AWS GUI is sufficient, but not very good. If you login to GCP, see that feedback button in the upper right on each page? Product managers have emailed me back asking for more information, or explaining features when I've used that feedback button.
- whoisjuan 7y ago
  It's definitely not a single team in charge of the UX. UX is a centralized department but each team can get UX Managers, UX Designers, and UX Researchers. The headcount for those roles come from each individual organization. Nowadays there's a workflow to ship new consoles and big features that require UI changes but there are still many consoles built on the legacy design system and designing or improving those is pretty hard. The right decision is to migrate those consoles to the design system but that is a painful process.
ken 7y ago
I've had to use AWS in the past professionally. The general categories of problems I've seen with AWS are threefold: 1. Each individual service in AWS may be perfectly well designed, but there are now about 5000 services in AWS, which means there's 5000^2 possible interactions between services. Services interact in strange ways, and there's no visibility (and no documentation) into exactly how. You can write 5000 bug-free functions, but that doesn't mean you'll end up with a bug-free program. 2. The craftsmanship that goes into each element of the AWS console is poor. Controls don't work like I expect, and don't work like similar controls elsewhere. Error messages are terrible, or missing, and don't give any clue what is actually going on, or what secret AWS-specific trick I need to use to fix it. I've wasted hours of my life on those spinners because it's not even clear if an action will occur right away, in 30 seconds, or 30 minutes. What is one supposed to do when they click a button, wait a few minutes, go to lunch, and come back to see "at least one of the environment termination workflows failed"? 3. The documentation and support is lousy. I've asked a few questions on AWS's own forums, and never gotten any response at all. The above error message appears in exactly one forum post, and AWS finally got back to them after 2 weeks, and it was all done via PM so I learned nothing from it. I've used the 'Feedback' button, and when I get a reply, it feels like some combination of "it's your fault" and "you should have googled harder". > designing, leading, and building the frontend for an AWS service Designing the frontend for an AWS service doesn't help with the biggest problems. It's like designing a city by designing apartments and offices, with no thought given to roads or signs. > The universal thinking within AWS is that people will ultimately use the API/CLI/SDK. I can't understand this. If someone can't get the web console to work, they're not going to say "I know, I'll just write everything by hand with the API instead". The web console is essentially your landing page and your trial combined. Do all your "personas" consist of people who build for the web but never use the web? Or who try a service, and when they can't get it to work, they double down on it?
- deleted 7y ago
  [deleted]
- sakisv 7y ago
  > I can't understand this. If someone can't get the web console to work, they're not going to say "I know, I'll just write everything by hand with the API instead". The web console is essentially your landing page and your trial combined. As a personal anecdote, my first interaction with AWS was to try and adjust the size of some elasticsearch disks. Not knowing better I tried to do it through the UI, only to find some crazy inconsistencies were the tooltip would say to type any size between 5 and 50 GB while the current value was 100GB. Even if you clicked "apply" with the current value of 100 you'd get an error message. I tried different browsers and it seemed to be a browser-specific issue. After that I delved into the terraform that was used to provision all our AWS resources and I haven't looked back since. Apart from the obvious benefits of keeping your infrastructure as code and automation etc, terraform actually helped me understand how all the different services we had worked together and allowed me to get a grasp of our infrastructure layout quicker. I would seriously discourage anyone from using the console for anything other than searching logs or managing DNS records (terraform is a bit flaky on that regard)
sl1ck731 7y ago
"The universal thinking within AWS is that people will ultimately use the API/CLI/SDK." What is odd is that during the Chicago summit one of the presenters explicitly said that most of their customers use the UI instead of API/automation. I don't recall the percentage but it was higher than I imagined.
Waterluvian 7y ago
Purely from speculation: AWS console looks and feels like it was designed and built by a ton of different teams that did a poor job working with and empowering each other. When services intermingle the console gets really confusing. Like "why am I in EC2? I'm making security groups and have zero EC2 systems." Any truth to this sense I get?
- cthalupa 7y ago
  >Like "why am I in EC2? I'm making security groups and have zero EC2 systems." Security Groups were initially an EC2 only concept. You couldn't write security groups for SQS or S3, and they came about alongside EC2. Obviously EC2 is no longer the only service that utilize security groups, but it's an artifact of when they were. (I'm not saying this is how it should be, just answering the 'why' part of the question ;))

SomeHacker44 7y ago

I personally dislike the CLI until I am very familiar with the AWS service I am learning or in early phase if using. Even then the CLI is usually a last resort. The Web UI is much more discoverable and understandable than having three terminal windows and a web browser open to figure out what to do with whatever random long ID on the CLI. Assuming everyone, even extremely experienced AWS users like me, will just use the CLI seems like a mistake.

scarface74 7y ago
I use the console for discoverability, proof of concepts, and quickly reviewing what’s going on. But for any real resource creation, I will then duplicate the steps with CloudFormation or a Python script (or both) and once I verify it, tear down the manually created resources. The only time I find the CLI useful is for S3.

scarface74 7y ago

The only part of the console that I absolutely hate is dealing with the Parameter Store. But I hate everything else about the parameter store too so there is that. CodePipeline is pretty bad too. There is no way you can create a cross account code pipeline from the console.

baseballMan 7y ago
CloudWatch log filters are pretty bad too. I basically just use ctrl + f now in cw logs to find what I'm looking for.
- scarface74 7y ago
  Oh yeah. They are horrible. I agree completely. For C#, I use Serilog for logging to both a Cloudwatch sink and a ElasticSearch sink. Before I’ve used a Mongo sink.
- eropple 7y ago
  Emit your logs in JSON for structural search and use CloudWatch Logs Insights. It's actually really very good these days--we have an ELK cluster because the team is used to the Kibana interface but I rarely if ever use it.
- cloakandswagger 7y ago
  I haven't had this problem. For simple string searches CloudWatch returns exactly what I'm looking for, even for partial word matches, and for more complicated queries there is the excellent Insights feature.
nostrebored 7y ago
Cross account setups from the console are generally not allowed.
- scarface74 7y ago
  You can assign cross account permissions for S3, sharing AMIs, sharing KMS keys, SNS permissions, etc.

notimetorelax 7y ago

Can you address user complaints about resets to the root view and non functioning sorting? Both seem to be bugs and single user report should be sufficient to identify and fix the issue. I think you make it look more complicated than it is.

postit 7y ago

> universal thinking within AWS is that people will ultimately use the API/CLI/SDK ( ͡° ͜ʖ ͡°) - But still 99% of tutorials and documentation refer to the UI.

lentil 7y ago
To be fair, the AWS documentation nearly always covers both.
- rolltiide 7y ago
  an outdated version of both. Here's a bunch of buttons! What do you mean you didn't install the CLI, discover your system has mixed up versions of the package manager, and finally get around to running this convoluted command, after you learn how to get a list of IDs from your organization with the CLI
  - nostrebored 7y ago
    The AWS cli is a simple pip install and the CLI documentation nearly universally includes samples. Input and output can be JSON. There are a lot of legitimate complaints about AWS but the CLI is pretty decent.
    - rolltiide 7y ago
      It has a steep learning curve. Every time something new roles out and AWS doesn't have a button for that one thing, your static site trying to follow the best practices now needs to know this and have python package managers installed and updated. I would say it is a legitimate complaint, it is a horrible user experience amongst people who aren't even considering what other people would think of it.
      - jasonlotito 7y ago
        > It has a steep learning curve. I mean, I guess if you are new to AWS entirely. I find the documentation for most things accessible and easy. For the things I want more information on or I'm not clear, support is fairly quick to help and point to the documentation. Most of the time it's the documentation I skipped because I assumed I knew it.

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

cloakandswagger 7y ago
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.
- lukev 7y ago
  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.

pmart123 7y ago

Interesting. I’ve always found it befuddling as a generalist with a relatively high learning curve. I gave it the benefit of the doubt until Google Cloud started rolling out its updates with far better documentation and interfaces. That said, AWS has way better customer support.

jrochkind1 7y ago
I bet GCS docs will not keep up with changes to GCS very well either, judging by other Google docs. Start out good, don't keep up with changes. AWS docs are relatively good at keeping up with changes.
- cameronbrown 7y ago
  Google's docs are the most inconsistent. The newer the service the better the documentation in my experience. The App Engine docs are like a rats nest, but the Firestore docs are really well done.
  - pmart123 7y ago
    My guess is they now care a lot more about Google Cloud than previous product endeavors. I’d also guess that people at Google would put in a ton of effort on documentation to avoid having to speak to people on the phone.

afpx 7y ago

Approximately how much does one have to spend per month to get prioritized feature improvements? We spend about $200k per month, and AWS treats us like we’re unimportant. I would like to try Azure or Google a try, but neither seem to make it easy to transfer Petabytes.

nkozyra 7y ago
I wouldn't expect those services to offer you much more personal attention, honestly.
- camtarn 7y ago
  Amazon does have vendor and seller managers who are allocated to specific vendors/sellers. I'm surprised that for a $2.4M/year AWS customer (presumably with the highest support level) that they wouldn't have a similar setup. That said, having personal attention from a manager is definitely not the same as getting features actually built for you.
  - taude 7y ago
    I agree, at 2.4M/year, i'm surprised you don't get more. we spend about 150k/month on Azure services, and it seems like we get a lot more service and roadmap influence....
    - cthalupa 7y ago
      In my experience a lot of it comes down to how effective their account team is. A good one will communicate with and work to influence the product management at AWS and set up meetings to discuss things as necessary. A bad one can get feedback from the customers they are assigned to and never do anything with it, or send off an email and never follow up.
  - nostrebored 7y ago
    With the highest support level you do receive TAMs and Solutions Architects within AWS. They can add feature requests and make sure that influence is added for you and follow up directly with Product Managers to explain why a feature is important. But, sometimes a high amount of spend on a service isn't really much more than the average. For instance, if you spend 200k/mo on a niche service then you'll get a ton of say in how things move forward, but if you spend 200k/mo on EC2 you might not be able to strongarm anything.

Sir_Cmpwn 7y ago

The API sucks, too, though, when used from the command line. Every non-automated way of interacting with AWS is like pulling teeth, and in reality most people do this all the time. You can't automate a process you've never done manually, and you don't necessarily want to invest in building out an automation which you only need to do a few times. It's like AWS's excuse is "we offload the problem of a good UI onto our users", which in my opinion is really stupid. All it would take is one UI team which made common tools and standards for UI design and applied them throughout. The API has a consistent design throughout, so why not the UI?

shepardrtc 7y ago

I think that the vast majority of UI's in AWS are perfectly fine. But there's one that drives my entire team insane: the AWS Parameter Store Holy mother of god, the search on it is horrific and simply doesn't work. Heartfelt begging through the feedback tool goes unanswered. I have offered money, firstborn children, sacrificial goats, virtually everything. But the search is still broken :( I've had to scroll through a hundred pages of parameters to find things.

scarface74 7y ago
Parameter Store is such a god awful experience via the UI. But everything about parameter store is awful. - severe unchangeable, undocumented limits before you get throttled. Throttling is so bad that if you have too many parameter store resources in your CloudFormation template it will start causing errors because CF is trying to call the API too quickly - the only way around it is to use DependsOn and chain the creation. - no way of creating an encrypted value with CF without a custom resource. We ended up just using DynamoDB for config anda Custom CloudFormation resource to create values in it. You should never depend on Parameter Store as a reliable key/value store for configuration.
- shepardrtc 7y ago
  We've hit the throttling issue many, many times. Everything about Parameter Store is difficult. And its a shame. Its such a simple concept. They have enormous resources, so why not throw a couple of devs at it? In any case, we do also use redis. It might be worthwhile to pitch an idea to move over to that. But we pull the parameters in bash scripts using a custom tool called aws-env, so we'd probably have to make or find something similar for redis.
  - cthalupa 7y ago
    https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-store-throughput.html https://docs.aws.amazon.com/systems-manager/latest/userguide... I believe this is a new(ish?) feature, but someone from AWS Support recently pointed it out to me when dealing with throttling issues. Might be of interest to you.

tootie 7y ago

Maybe I'm just being overly sympathetic, but having worked on UIs with complicated UX, I know how extremely hard it is to get right. Especially with something so complicated and sprawling as the AWS console. There's plenty of irritations, but the fact that it works as well as it does is amazing.

throwawaywego 7y ago

Persona of a person wanting to study AWS for commercial projects at one of AWS's biggest clients: - Create account. Enter credit card details, but verification SMS never shows up. Ask for help. - I get called at night (I'm abroad) by an American service employee, we do verification over the phone. - Try to get the hang of things myself. Lost in a swamp of different UI's. Names of products don't clarify what they do, so you first need to learn to speak AWS, which is akin to using a chain of 5 dictionaries to learn a single language. - Do the tutorials. Tutorials are poorly written, in that they take you by the hand and make you do stuff you have no idea what you are actually doing (Ow, I just spun up a load balancer? What is that and how does it work?). - Do more tutorials. Tutorials are badly outdated. Now you have a hold your hands tutorial, leading you through the swamp, but every simple step you bump your knee against an UI element or layout that does not exist in the tutorial. Makes you feel like you wasted your time, and that there is no one at AWS even aware that tutorials may need updating if one design department gets the urge to justify their spending by a redesign. - Give up and search for recent books or video courses. Anything older than 3-4 years is outdated (either the UI's have changed, deprecated, or new products have been added). - Receive an email in the middle of the night: You've hit 80% of your free usage plan. Log in. Click around for 20 minutes, until I find the load balancer is still up (weird, could have sworn I spun that entire tutorial down). Kill it, go back to sleep. - Next night, new email: You've gone 3.24 $ over your free budget. Please pay. 30 minutes later: We've detected unusual activity on your account. 1 hour later: Your account has been de-activited. AWS takes fraud and non-payment very seriously. Now I need a new phone number/name/address to create a new account. I am always anxious that AWS will charge for something that I don't want, and can't find the UI that shows all running tutorial stuff that I really don't want to pay for. I know the UI is unintuitive, non-consistent, and out-of-sync with the technical - and tutorial writers. And I know that learning AWS, consists of learning where tutorials and books are out-dated, or stumbling around until you find the correct set of sequences in a "3 minutes max." tutorial step. AWS has grown fat and lazy. The lack of design - and onboarding consistency is typical for a company of that size. Outdated tutorials show a lack of inter-team communication, and seems to indicate that no one at AWS reruns the onboarding tutorials every month, so they can know what their customers are complaining about (or why they, like me, try to shun their mega-presence). (EDIT: The order of my experiences may be a bit jumbled. Sorry. More constructive feedback: 1) I'd want a safe tutorial environment, with no (perceived) risk of having to pay for dummy services. 2) I want the tutorial writer to have the customer's best interest in mind: "For a smaller site, load balancing may be overkill, and can double your hosting costs for no tangible gains." beats "Hey Mark, we need more awareness and usage on the new load balancer. I need you to write a stand-alone tutorial, and add the load balancer to the sample web page tutorial." 3) Someone responsible for updating the tutorials (even if: "This step is deprecated. Please hold on for a correction") 4) A unified and consistent UI and UX. Scanning, searching, sorting, etc. should work without making me think, I don't want a different UI model for every service. Someone or some team to create the same recipes and boundaries for the different 2-pizza teams, so I don't get a pizza UI with all possible ingredients.)

thayne 7y ago

I primarily use the api to create and manage infrastructure, but I still use the console to view my infrastructure, and it is pretty painful.

robbyt 7y ago

I'm honestly surprised there was only one team in charge of UX for the AWS gui. It always felt like each product did their own UX because of all the various inconsistency between different areas. I don't have any examples off-hand, but anyone who's used it would probably agree with me. For the record, I think the AWS GUI is sufficient, but not very good. If you login to GCP, see that feedback button in the upper right on each page? Product managers have emailed me back asking for more information, or explaining features when I've used that feedback button.

whoisjuan 7y ago
It's definitely not a single team in charge of the UX. UX is a centralized department but each team can get UX Managers, UX Designers, and UX Researchers. The headcount for those roles come from each individual organization. Nowadays there's a workflow to ship new consoles and big features that require UI changes but there are still many consoles built on the legacy design system and designing or improving those is pretty hard. The right decision is to migrate those consoles to the design system but that is a painful process.

ken 7y ago

I've had to use AWS in the past professionally. The general categories of problems I've seen with AWS are threefold: 1. Each individual service in AWS may be perfectly well designed, but there are now about 5000 services in AWS, which means there's 5000^2 possible interactions between services. Services interact in strange ways, and there's no visibility (and no documentation) into exactly how. You can write 5000 bug-free functions, but that doesn't mean you'll end up with a bug-free program. 2. The craftsmanship that goes into each element of the AWS console is poor. Controls don't work like I expect, and don't work like similar controls elsewhere. Error messages are terrible, or missing, and don't give any clue what is actually going on, or what secret AWS-specific trick I need to use to fix it. I've wasted hours of my life on those spinners because it's not even clear if an action will occur right away, in 30 seconds, or 30 minutes. What is one supposed to do when they click a button, wait a few minutes, go to lunch, and come back to see "at least one of the environment termination workflows failed"? 3. The documentation and support is lousy. I've asked a few questions on AWS's own forums, and never gotten any response at all. The above error message appears in exactly one forum post, and AWS finally got back to them after 2 weeks, and it was all done via PM so I learned nothing from it. I've used the 'Feedback' button, and when I get a reply, it feels like some combination of "it's your fault" and "you should have googled harder". > designing, leading, and building the frontend for an AWS service Designing the frontend for an AWS service doesn't help with the biggest problems. It's like designing a city by designing apartments and offices, with no thought given to roads or signs. > The universal thinking within AWS is that people will ultimately use the API/CLI/SDK. I can't understand this. If someone can't get the web console to work, they're not going to say "I know, I'll just write everything by hand with the API instead". The web console is essentially your landing page and your trial combined. Do all your "personas" consist of people who build for the web but never use the web? Or who try a service, and when they can't get it to work, they double down on it?

deleted 7y ago
[deleted]
sakisv 7y ago
> I can't understand this. If someone can't get the web console to work, they're not going to say "I know, I'll just write everything by hand with the API instead". The web console is essentially your landing page and your trial combined. As a personal anecdote, my first interaction with AWS was to try and adjust the size of some elasticsearch disks. Not knowing better I tried to do it through the UI, only to find some crazy inconsistencies were the tooltip would say to type any size between 5 and 50 GB while the current value was 100GB. Even if you clicked "apply" with the current value of 100 you'd get an error message. I tried different browsers and it seemed to be a browser-specific issue. After that I delved into the terraform that was used to provision all our AWS resources and I haven't looked back since. Apart from the obvious benefits of keeping your infrastructure as code and automation etc, terraform actually helped me understand how all the different services we had worked together and allowed me to get a grasp of our infrastructure layout quicker. I would seriously discourage anyone from using the console for anything other than searching logs or managing DNS records (terraform is a bit flaky on that regard)

sl1ck731 7y ago

"The universal thinking within AWS is that people will ultimately use the API/CLI/SDK." What is odd is that during the Chicago summit one of the presenters explicitly said that most of their customers use the UI instead of API/automation. I don't recall the percentage but it was higher than I imagined.

Waterluvian 7y ago

Purely from speculation: AWS console looks and feels like it was designed and built by a ton of different teams that did a poor job working with and empowering each other. When services intermingle the console gets really confusing. Like "why am I in EC2? I'm making security groups and have zero EC2 systems." Any truth to this sense I get?

cthalupa 7y ago
>Like "why am I in EC2? I'm making security groups and have zero EC2 systems." Security Groups were initially an EC2 only concept. You couldn't write security groups for SQS or S3, and they came about alongside EC2. Obviously EC2 is no longer the only service that utilize security groups, but it's an artifact of when they were. (I'm not saying this is how it should be, just answering the 'why' part of the question ;))