> 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
Wow, this speaks to me.
The best that I've found, in general, is to:
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)
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 fantastic 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.
Highly, highly recommend AWS Copilot for any teams build on AWS; dramatically simplified deployment and infra for us at previous startup.
This critique feels similar to the “agile was a bad idea” articles lately.
Here’s what I think is really happening:
A new, radical way of work is developed and introduced to the world.
Most large organizations are incapable of radical change, but they also don’t want to be left behind.
So, they adopt pieces of the new thing, up to the change tolerance of the organization. Existing processes that they are unwilling to change get renamed to mirror the new thing.
This hodgepodge of processes underperforms expectations based on what would have happened on full adoption.
Employees grow cynical and resist adopting any new hotness/flavor of the day practice, when in reality the organization hasn’t ever changed much.
The best that I've found, in general, is to:
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)
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 fantastic 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.
Highly, highly recommend AWS Copilot for any teams build on AWS; dramatically simplified deployment and infra for us at previous startup.
[0] https://aws.github.io/copilot-cli/
Here’s what I think is really happening: A new, radical way of work is developed and introduced to the world.
Most large organizations are incapable of radical change, but they also don’t want to be left behind.
So, they adopt pieces of the new thing, up to the change tolerance of the organization. Existing processes that they are unwilling to change get renamed to mirror the new thing.
This hodgepodge of processes underperforms expectations based on what would have happened on full adoption.
Employees grow cynical and resist adopting any new hotness/flavor of the day practice, when in reality the organization hasn’t ever changed much.