This post and the cover image was inspired by this tweet by Corey Quinn and his blog post.

AWS has nearly 100’s of services that helps to address different kinds of challenges in designing, building and managing workloads in AWS. While choices are a good thing, too many is also going to be a problem because it makes the decision complex.

Some of the challenges that I have faced personally in no specific order :

1. Similar services with overlapping features makes it hard to choose the right one for the job

For example, there are many different ways to deploy containers in AWS. In 2017, there were two options. In 2021, we have way too many options.

There are many different CI-CD services each targeting a specific use-case while leaving out the rest of the use-cases. Not a single service attempting to address the broad set of feature to make it a complete service in itself.

2. Too many services and spreading thin thereby making for low adoption

There are more ways to address the same problem. This leads to fragmentation. No large community support as a result of spreading too thin.

For example, CloudFormation, SAM, CDK - all these options are available for infrastructure as code. Choosing amongst them has become super difficult now. And when any help or support is required for a very unique use-case or edge case, due to no single standard being followed and lack of wide spread community adoption, there is always a chance of getting stuck and workaround becomes way too challenging or impossible at times.

3.Priotiziating for building new services instead of plugging feature gaps in existing service

For instance, AWS CodePipeline may not have the entire feature set of popular CI tools. And even before CodePipeline reaches feature parity, there are yet another set of new CI-CD services with overlapping features.

4. Easy to get started, but difficult for complex use-cases

Some services help in getting started easily, but the more difficult and complex use-cases are not well thought out. There are always need for workarounds and having to rely on different service to address the problem. So if the service does not offer any solution to edge cases or complex use-cases, it needs to be called out upfront.

There may be more documentation on the web with examples in detail on how this has become a persistent problem.

What should AWS do?

I’m pretty sure that AWS is already aware of this, but here are some of the suggestions to help the process less painful, if not super easy and seamless.

Here is what I think should AWS do.

1. AWS must provide a comprehensive set of documentation comparing services that have similar overlapping functionalities attempting to solve the same problem by listing down the pros and cons for each service.

2. AWS must have better targetting of services based on the customer profile. A citizen lone developer building apps in AWS may have different requirements vs a small startup with 10-20 developers vs a large enterprise having 100+ developers. I would urge better targetting of services and supporting necessary documentation based on the user profile. Every service should communicate how they are different and make it more obvious to the people who are tasked with choosing the right service for the job. If they are already available , it must be highlighted better.

3. AWS must actively plug feature gaps on existing services and build new features in existing services where ever possible, instead of building something from the scratch all the time. New features in existing services mean less cognitive overload rather than following up on new AWS service day-in and day-out. Prioritising to improve existing AWS services instead of building new ones that try to solve an overlapping problem should be encouraged.

4. AWS must ensure the limitations of service are well documented. In some cases, service limits are not clearly or explicitly called out. Corner edge cases and known unknowns have to be well documented so that users understand what they are getting into. And this information should be highlighted and not hidden deep inside the documentation. I hope AWS comes up with some governance model around the way how every service should state all of this information in a pretty standard way across services so that it becomes easy to locate and make decisions accordingly.

Many times I see the AWS community reply back to problems that people have with a simple comment: “The wrong solution for the problem”. While in some cases this may be true, AWS must have some kind of shared responsibility when it comes to helping customers to choose the right service. While a lot of choices at the end of the day is a matter of ‘It depends’, I would still expect AWS to provide as much documentation as possible, be transparent in terms of comparison and evaluation of different services so that it becomes more easy and obvious for the customer to choose from.

AWS must understand this challenge and need to address this problem. It needs to keep in mind that customers at the end of the day are looking to solve business problems and would choose products or services that help them in this regard. No one other than AWS employees or AWS consultants would keep following on the latest and greatest from AWS day-in and day-out. Hence it becomes super important to ensure while choices are a good thing, they should not become overwhelming.