<p><pre><code> > Now, DevOps teams build internal tooling designed more to restrict than to empower. They wrap every API in layers of homegrown abstractions...Originally, DevOps was about trusting developers with production. But modern DevOps teams operate on the belief that developers can’t be trusted with production
</code></pre>
Wow, this speaks to me.<p>The best that I've found, in general, is to:<p>1. Keep the system architecture as simple as possible to meet the needs of the application; don't add infra where you do not absolutely need it. I like GCP for this because Pub/Sub and Task Queues can both operate on "free" HTTP push which is really, really nice for simplifying architecture (make everything HTTP endpoints if you can)<p>2. If you must add infra, do it using the highest level abstraction possible. For example, on AWS, (the unfortunately named) Copilot CLI[0] is <i>fantastic</i> and feels like the "just right" level of abstraction for a lot of use cases and also feels incredibly ergonomic in daily use while offering enough flexibility to plugin custom CDK or CF if needed.<p>Highly, highly recommend AWS Copilot for any teams build on AWS; dramatically simplified deployment and infra for us at previous startup.<p>[0] <a href="https://aws.github.io/copilot-cli/" rel="nofollow">https://aws.github.io/copilot-cli/</a>