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.
A huge portion of AWS services are really annoying in my opinion to grassroots developers and platform managers because they are basically executive demoware.
You know the kind where the salesman comes in and in front of the CIO builds some whiz-bang demo and like 20 minutes and has a CEO asking why it takes a month or more to do equivalent stuff by real it workers.
And sometimes it's worse to customize the out-of-the-box solution than just creating your own solution. For some AWS products, it's pure pain to get it up and running in the configuration you require. There are edge cases and bugs to worry about.
That whiz-bang demo? Maybe that's the only functionality that works right. Maybe it's all using default values that won't pass your internal security and compliance policies.
And lets not forget the pain of integrating something new with existing systems. It's easy to show a demo of something that doesn't integrate with existing systems, and just show a slide or two of what things it integrates with.
If you get rid of chime you also get rid of slack huddles (built on Chime). Like many AWS services the backend of Chime is good, the UX/UI is terrible.
It was a business decision because slack's old /call command was built on a startup they aquired. I don't know the details but I'm sure Amazon gets deep discounts on slack and slack get's the same for chime.
Thanks for the interest in Talos Linux! I work at Sidero (creators of Talos) and there are lots of “secure, immutable, and minimal” Linux distos out there.
Something that Talos does differently is everything is an API. Machine configuration, upgrades, debugging…it’s all APIs. This helps with maintaining systems way beyond the usual cloud-init and systemd wrappers in other “minimal” distros.
The second big change is Talos Linux is only designed for Kubernetes. It’s not a generic Linux kernel+container runtime. The init system was designed to run the kubelet and publish an API that feels like a Kubernetes native component.
This drastically reduces the Linux knowledge required to run, scale, and maintain a complex system like Kubernetes.
I’ve been doing a set of live streams called Talos Linux install fest walking new users through setting up their first cluster on Talos. Each install is in a new environment so please check it out.
