I was early container adopter at a large RHEL shop and they absolutely required us to use their forked version of docker for the daemon and RHEL based images with systemd.
This was mostly so containers could register with systems manager and count against our allowed systems.
We ignored them because it was so bad and buggy. This is when I switched to CoreOS for containerized workloads.
Everything trends upwards. Even the services they killed in the past year I’m sure were getting new customers.
But Amazon isn’t interested and doesn’t have capacity to support hundreds of services that don’t make a lot of money.
I would be fine if they built a new tool with 2024 IaC experience and control. But I think trying to evolve CFN into a new thing would take far too long and have a lot of edge cases that they should just start over and stop trying to paper over it with CDK, Proton, ACK, etc.
CDK seems like it could support multiple backends, and in fact there’s cdk8s already (having never used cdk8s, I can’t comment more on it). The CF data model seems fine enough though, so I think overall CF just needs a lot of love. Not holding my breath though.
Shoot, looks like just a me problem after disabling some extensions. Currently narrowing down which one is misbehaving. Sorry for the false alarm, should have tried this first.
EB has languished for 1 reason. The team that built/maintained EB was reorged to build AppRunner (as EB v2) and they never had enough cycles to maintain both and weren't allowed to deprecate v1.
Any amount of evolving would require a lot of breaking changes to rearchitect and not be bogged down by keeping compatibility. I think they should make a v2 and sunset v1 and not keep any old compatibility.
In the last year they've deprecated 14+ services/features and they've been really bad. They will email existing customers but they won't announce it publicly to avoid the bad press. Documentation pages are updated quietly with banners or removed.
reply