AWS Copilot

My question is a bit less targeted at this specifically and more about how AWS approaches all of these various tools.

We have probably 95% of our infrastructure in CloudFormation one way or another (either directly or with something like SAM).

As more of these tools come out there is going to be crossover (and there already is with Amplify and SAM for example).

There will also be questions about how we pass exports around so we don't have to hard code endpoints that were created by another tool. (Say a Lambda created by SAM needs to be called by a service in ECS).

So my question is a couple things:

1. Does AWS have a requirement or a goal in mind of how to always ensure we can pass these exports around ideally in a consistent way (this and any future tools that may come out)? I worry about having too many different ways that things work from a code standpoint that we just introduce more bugs into our system.

2. Is the thought that a given repo should ideally be using a single tool (I ask since I see you mention S3 buckets, and databases as a coming soon) and not mixing things? Like not using this plus some native CloudFormation for example?

3. Finally, I would love to see a... "deployment tools" page or something from AWS. A page that is a table of every deployment tool for columns and every service for rows and can easily see at a glance what tool can do which services. Right now I am considering if I need to build a page like this for internal use so a developer can easily look and see what fits their use case the best. But a page managed by AWS would be great.

Ultimately what I struggle a bit with tools like this, are what does it get me long term over just using straight CloudFormation where my only limitation is CloudFormation lagging behind.

We learned this lesson the hard way with XML back in the early naughts when behind everything was a nauseating morass of xml with overcomplicated designed-by-committee schemas.

People moved out of development and tried hard to forget it, but neglected to instruct the next generation about the pitfalls of shitty configuration files that get out of control.

Now we got json and yaml. No more 's, yay, but somehow worse, less maintainable and less understandable.

Employees there usually don't have depth of technical expertise or experience to draw from, and are incentivized to make the product sound as easy to use as possible.

This combination results in {really complicated thing} -> {simple abstraction}. Ultimately, everyone internalizes this and starts forgetting that {simple abstraction} is actually {really complicated thing}.

Happens with any popular technology. Networking, DB, cloud, ML.

Unfortunately, this flies because the primary buyers are also non-technical.

I've been an AWS customer for over 10 years, and have been asking them for this (on behalf of my enterprise customers). I'm always told "they're working on getting better" but they never really do.

Cloud formation features are inconsistent across products. Documentation is formatted and structured differently depending on the tool. The AWS web console is an ever changing grab-bag of new and old. Some products integrate well, other products feel like you're using an abandoned hack-week prototype.

Part of the reason that AWS is so great is how much it can do, and I think that's been made possible by the apparent level of autonomy the teams have. However, it's at the expense of the customer's experience.

I guess its more, if I had to choose one area of AWS that I wish there was a but more consistency it would be their deployment tools. It really just comes down to, when I start something it's almost an agonizing choice of what do I use since I am worried that I could get stuck in a box.

I don't know what the answer is, that is just my view of all of these tools.