Starting a new service was a path towards promotion at AWS, so they ended up launching 100s of services to the point where there were 10 different ways to do everything. I’m glad they’re culling them.
There were (are?) challenges in product placement and compatibility as well. Yes, some “services” are very niche and dont have a credible target market/adoption plan. My old service is one of those on this list.
But there are others where a “service” is really a _feature_ of another existing product offering. But for handwave reasons it can be extremely difficult to implement that way, and a new API and service name etc make the development tractable. To throw a stone Cloudwatch org is an interesting example of this, where its both too broad and too narrow, leading to an umbrella of undersized feature/services.
I guess this explains why AWS manages to run the whole gamut from the most generally applicable tooling such as EC2 to something I’ve never heard of and sounds specific enough to just be its own business, ‘AWS HealthOmics - Variant and Annotation Store’
Is the implication these services are used so little it isn't worth AWS continuing to invest in developing or maintaining beyond bare-minimum KTLO ops?
If you click the Glacier link, it seems like it's some sort of standalone service and API that's very old. The page says to use S3's Glacier storage tier instead, so no change for the majority of folks that are likely using it this way
They should get real and include App Runner on this list.
So much promise as a Heroku alternative with all the AWS integrations but it's basically dead now. Not a peep from them on their public roadmap over at github.
We're having to go back to Fargate with all the operational overhead that entails.
If you are fine with running lots of apps on one beefy machine, the project I am building https://github.com/openrundev/openrun provides a similar abstraction as App Runner and Cloud Run (automatically deploy web apps from source). It supports scaling down to zero, but does not yet scale an app beyond one container.
Yeah it's an Event Notification that triggers lambda that acts on the bucket, i had to give it permissions to the bucket so i guess it's outside it :). We'll see!
Yeah I agree. We're currently using it to dump images as originals into a bucket at a path.. then the aws lambda function attached generates all the thumbnails.
Glad to see this, but there’s a lot more cleanup to do. AWS went from
having a few core excellent services with a strong innovation pipeline to a chaotic “jack of all trades master of none” approach with no clear product strategy. Some of the recent panic trying to catch up on AI has resulting in even more slop thrown at the wall hoping something sticks.
We love you, but focus on the core infrastructure bits and stop chasing everything that moves! Your customers build better apps and services that you do… just build great building blocks and folks will be very happy.
That original Glacier API was infamous for being extremely cheap to write to but prohibitively expensive to read from. Something like 10 cents per list objects request or something ridiculous like that. Can't remember the specifics but I do remember reading blog posts from people that wanted to restore a couple files and had to pay several thousand dollars for that.
I believe that they did alter the pricing at some point. Regardless, the move to just a storage class on S3 made everything much simpler.
Starting a new service was a path towards promotion at AWS, so they ended up launching 100s of services to the point where there were 10 different ways to do everything. I’m glad they’re culling them.
Other cloud vendors aren't much better, every time I go back it is a new world in some fashion.
There were (are?) challenges in product placement and compatibility as well. Yes, some “services” are very niche and dont have a credible target market/adoption plan. My old service is one of those on this list.
But there are others where a “service” is really a _feature_ of another existing product offering. But for handwave reasons it can be extremely difficult to implement that way, and a new API and service name etc make the development tractable. To throw a stone Cloudwatch org is an interesting example of this, where its both too broad and too narrow, leading to an umbrella of undersized feature/services.
I guess this explains why AWS manages to run the whole gamut from the most generally applicable tooling such as EC2 to something I’ve never heard of and sounds specific enough to just be its own business, ‘AWS HealthOmics - Variant and Annotation Store’
Is the implication these services are used so little it isn't worth AWS continuing to invest in developing or maintaining beyond bare-minimum KTLO ops?
Some of them also ended up getting consolidated into other larger services
Amazon Glacier on the list is a pretty big surprise to me.
It was consolidated into S3 as a storage class: https://docs.aws.amazon.com/amazonglacier/latest/dev/introdu...
That's interesting, as Glacier was based on a completely different hardware implementation for a different use case.
If you click the Glacier link, it seems like it's some sort of standalone service and API that's very old. The page says to use S3's Glacier storage tier instead, so no change for the majority of folks that are likely using it this way
Same capability is now just a storage class in S3.
Read the header here for an explanation, it's not going away.
https://docs.aws.amazon.com/amazonglacier/latest/dev/introdu...
They should get real and include App Runner on this list.
So much promise as a Heroku alternative with all the AWS integrations but it's basically dead now. Not a peep from them on their public roadmap over at github.
We're having to go back to Fargate with all the operational overhead that entails.
If you are fine with running lots of apps on one beefy machine, the project I am building https://github.com/openrundev/openrun provides a similar abstraction as App Runner and Cloud Run (automatically deploy web apps from source). It supports scaling down to zero, but does not yet scale an app beyond one container.
genuinely curious, what would make you trust a PaaS-like platform again? are you looking for control/transparency? is it about pricing?
Amazon S3 Object Lambda seems like a massive category to deprecate
Yeah, that will greatly impact one of our products. As usual with AWS documentation it's not very clear what the update path seems to be.
https://docs.aws.amazon.com/AmazonS3/latest/userguide/amazon...
I wonder why they're going that direction too, if anything those lambdas must be making money for them.
At least it’s not S3 triggers for lambdas, just about gave me a heart attack.
oh maybe thats what were using. Made it months ago and im not 100% sure. Lambda on putObject
That sounds like it might be a lambda trigger to me. The feature being deprecated is lambdas that operate at the s3 API level.
Yeah it's an Event Notification that triggers lambda that acts on the bucket, i had to give it permissions to the bucket so i guess it's outside it :). We'll see!
Yeah I agree. We're currently using it to dump images as originals into a bucket at a path.. then the aws lambda function attached generates all the thumbnails.
Glad to see this, but there’s a lot more cleanup to do. AWS went from having a few core excellent services with a strong innovation pipeline to a chaotic “jack of all trades master of none” approach with no clear product strategy. Some of the recent panic trying to catch up on AI has resulting in even more slop thrown at the wall hoping something sticks.
We love you, but focus on the core infrastructure bits and stop chasing everything that moves! Your customers build better apps and services that you do… just build great building blocks and folks will be very happy.
Wow. I can’t believe Glacier is on that list.
Does not be accessible to new customers mean a new test account that rolls into the same parent org would no longer have access either?
It's the standalone Glacier service which I wasn't even aware existed - nothing changes for the s3 glacier storage class.
That original Glacier API was infamous for being extremely cheap to write to but prohibitively expensive to read from. Something like 10 cents per list objects request or something ridiculous like that. Can't remember the specifics but I do remember reading blog posts from people that wanted to restore a couple files and had to pay several thousand dollars for that.
I believe that they did alter the pricing at some point. Regardless, the move to just a storage class on S3 made everything much simpler.
Amazon following the lead of Google Cloud of shutting down AWS services is not a good sign.
Where will the money and resources to develop AWS AI come from? Not from Incident Manager, that is for certain.
Ironically that's a domain where AI could be genuinely helpful and reduce MTTR.
This is why you should never use niche aws services.
> This is why you should never use niche aws services.
Niche ? From who's perspective? Anyway if AWS are offering a service, why would you ever need to consider 'is this too niche for lts?'