4 ms·

I do sincerely wished Amazon would have consider changing their AWS service management UI and workflow as well as epanding their servers around the globe. Curr

I do sincerely wished Amazon would have consider changing their AWS service management UI and workflow as well as epanding their servers around the globe. Currently it is an incredibly inefficient design of a service management trying to do everything yet many are dependent for using it.

ceejayoz 10y ago
If you're big enough that switching regions in the console is a regular pain, you're probably big enough to just automate stuff via the APIs.
- grif-fin 10y ago
  This maybe a fact but not an excuse for poor user experience.
  - ceejayoz 10y ago
    AWS initially launched API-only. At any significant scale, it's simply not intended to be managed via the console.
    - grif-fin 10y ago
      I found visualization very much helpful when complexity rises. APIs stays powerful but do not support a human admin for monitoring and server setups (including IAM users, Services, Tasks, Clusters, Launching EC2 instances, ECR setup for docker, AIM, Loadbalancing, Security groups, Roles etc all multiplied to X regions).
      - ceejayoz 10y ago
        Again, if you're large enough to be in multiple regions, all of this should be configured via the APIs using a configuration management system of some sort. Ansible, for example, can easily manage stuff like security groups (http://docs.ansible.com/ansible/ec2_group_module.html http://docs.ansible.com/ansible/ec2_group_module.html) , load balancing (http://docs.ansible.com/ansible/ec2_elb_lb_module.html http://docs.ansible.com/ansible/ec2_elb_lb_module.html), IAM users and roles (http://docs.ansible.com/ansible/iam_module.html http://docs.ansible.com/ansible/iam_module.html), etc., and it does them in repeatable, auditable, version-controllable, self-documenting fashion.
        grif-fin 10y ago
        " if you're large enough to be in multiple regions, all of this should be configured via the APIs" Is the suggestion to recreate what Amazon Console has done (using APIs) in every large organisation using AWS because Amazon Console is not good enough?
        tomcart 10y ago
        No, treat your infrastructure as code. Define it programatically, version it, have a standard, automated process for recreating it. If you're using AWS then Cloudformation (maybe with an abstraction like troposphere), will do what you need. If you are pressing the big blue 'launch instance' button, you are doing it wrong.
        grif-fin 10y ago
        "No, treat your infrastructure as code." Agreed. Advantage is clear and understood. My point here is: there exists something called 'Amazon Console'. I argue it is a good thing to have if done properly easing the service management as visualized management is more human friendly and APIs more computer friendly. If there exists a bad visualized service management (e.g. Amazon Console) it is the lack of skills of the humans developing it not because managing a vast complex clusters is easier through APIs/CLI and impossible/wrong via UI.
  - vacri 10y ago
    I'm not sure what a console that performs the current tasks and spans multiple regions at once would look like, or that it would make things feel simpler. What's your suggestion for improving the UX?
    - grif-fin 10y ago
      Extending the UX with "the current tasks and spans multiple regions at once" is definitely NOT the right way. I believe the current sub-categorizing of services: API Gateway, AppStream, AWS IoT, Certificate Manager, CloudFormation, CloudFront, CloudSearch, CloudTrail, CloudWatch, CodeCommit, CodeDeploy, CodePipeline, Cognito, Config, Data Pipeline, Device Farm, Direct Connect, Directory Service, DMS, DynamoDB, EC2, EC2 Container Service, Elastic Beanstalk, Elastic File System, Elastic Transcoder, ElastiCache, Elasticsearch Service, EMR, GameLift, Glacier, IAM, Inspector, Kinesis, Lambda, Machine Learning, Mobile Analytics, Mobile Hub, OpsWorks, RDS, Redshift, Route 53, S3, Service Catalog, SES, Snowball, SNS, SQS, Storage Gateway, SWF, Trusted Advisor, VPC, WAF, WorkDocs, WorkMail, WorkSpaces. is not helpful and confusing for new users. This is because all the mentioned services are a mix of dependent (e.g. ECS depends on EC2), independent(e.g. IAM & EC2), security, services acting like plugins. The documents for all of these services can be a sequel novel. If you have been with AWS since 2012 you may have gradually been updated by each service that was getting blindly added but for a new user or a startup aiming to setup something or test the scalability of their application ASAP it is a nightmare. The other day I found out (in a hard way) that you cannot launch an EC2 instance with an AWS container agent from the default launch page but you need to go to the launch page via the document link which puts extra parameters in the url... Having said all that I believe the improvement needs to be more fundamental than couple of bullet points.
jeffbarr 10y ago
Do you have some specific feedback that I can share with the team? Which aspects of the console and the workflow are not working for you?

ceejayoz 10y ago

If you're big enough that switching regions in the console is a regular pain, you're probably big enough to just automate stuff via the APIs.

grif-fin 10y ago
This maybe a fact but not an excuse for poor user experience.
- ceejayoz 10y ago
  AWS initially launched API-only. At any significant scale, it's simply not intended to be managed via the console.
  - grif-fin 10y ago
    I found visualization very much helpful when complexity rises. APIs stays powerful but do not support a human admin for monitoring and server setups (including IAM users, Services, Tasks, Clusters, Launching EC2 instances, ECR setup for docker, AIM, Loadbalancing, Security groups, Roles etc all multiplied to X regions).
    - ceejayoz 10y ago
      Again, if you're large enough to be in multiple regions, all of this should be configured via the APIs using a configuration management system of some sort. Ansible, for example, can easily manage stuff like security groups (http://docs.ansible.com/ansible/ec2_group_module.html http://docs.ansible.com/ansible/ec2_group_module.html) , load balancing (http://docs.ansible.com/ansible/ec2_elb_lb_module.html http://docs.ansible.com/ansible/ec2_elb_lb_module.html), IAM users and roles (http://docs.ansible.com/ansible/iam_module.html http://docs.ansible.com/ansible/iam_module.html), etc., and it does them in repeatable, auditable, version-controllable, self-documenting fashion.
      - grif-fin 10y ago
        " if you're large enough to be in multiple regions, all of this should be configured via the APIs" Is the suggestion to recreate what Amazon Console has done (using APIs) in every large organisation using AWS because Amazon Console is not good enough?
        tomcart 10y ago
        No, treat your infrastructure as code. Define it programatically, version it, have a standard, automated process for recreating it. If you're using AWS then Cloudformation (maybe with an abstraction like troposphere), will do what you need. If you are pressing the big blue 'launch instance' button, you are doing it wrong.
        grif-fin 10y ago
        "No, treat your infrastructure as code." Agreed. Advantage is clear and understood. My point here is: there exists something called 'Amazon Console'. I argue it is a good thing to have if done properly easing the service management as visualized management is more human friendly and APIs more computer friendly. If there exists a bad visualized service management (e.g. Amazon Console) it is the lack of skills of the humans developing it not because managing a vast complex clusters is easier through APIs/CLI and impossible/wrong via UI.
- vacri 10y ago
  I'm not sure what a console that performs the current tasks and spans multiple regions at once would look like, or that it would make things feel simpler. What's your suggestion for improving the UX?
  - grif-fin 10y ago
    Extending the UX with "the current tasks and spans multiple regions at once" is definitely NOT the right way. I believe the current sub-categorizing of services: API Gateway, AppStream, AWS IoT, Certificate Manager, CloudFormation, CloudFront, CloudSearch, CloudTrail, CloudWatch, CodeCommit, CodeDeploy, CodePipeline, Cognito, Config, Data Pipeline, Device Farm, Direct Connect, Directory Service, DMS, DynamoDB, EC2, EC2 Container Service, Elastic Beanstalk, Elastic File System, Elastic Transcoder, ElastiCache, Elasticsearch Service, EMR, GameLift, Glacier, IAM, Inspector, Kinesis, Lambda, Machine Learning, Mobile Analytics, Mobile Hub, OpsWorks, RDS, Redshift, Route 53, S3, Service Catalog, SES, Snowball, SNS, SQS, Storage Gateway, SWF, Trusted Advisor, VPC, WAF, WorkDocs, WorkMail, WorkSpaces. is not helpful and confusing for new users. This is because all the mentioned services are a mix of dependent (e.g. ECS depends on EC2), independent(e.g. IAM & EC2), security, services acting like plugins. The documents for all of these services can be a sequel novel. If you have been with AWS since 2012 you may have gradually been updated by each service that was getting blindly added but for a new user or a startup aiming to setup something or test the scalability of their application ASAP it is a nightmare. The other day I found out (in a hard way) that you cannot launch an EC2 instance with an AWS container agent from the default launch page but you need to go to the launch page via the document link which puts extra parameters in the url... Having said all that I believe the improvement needs to be more fundamental than couple of bullet points.

jeffbarr 10y ago

Do you have some specific feedback that I can share with the team? Which aspects of the console and the workflow are not working for you?