29 ms·

A company with Amazons resources could keep these fringe services around as long as there are paying customers. Just increase the price of the service to match

A company with Amazons resources could keep these fringe services around as long as there are paying customers. Just increase the price of the service to match the costs of keeping the legacy service around.

culturestate 2y ago
I mean this is a 20-month notice, that's already fairly generous by modern standards.
Dunedan 2y ago
From all what I've heard over the years, they have a problem staffing the service teams. I imagine with the AI craze that just got worse, as they certainly shifted resources to work on that. If they really have staffing problems, it'd make sense in the short-term to shut down services which don't bring in much revenue. In the long-term that might fire back if AWS customers loose trust in the services they're using still being there in the future. The obvious solution to a possible staffing problem would of course be not fire a certain percentage of your employees every year.
- hnlmorg 2y ago
  I have a lot of grips with AWS, but long term support isn’t one of them. They’ve given nearly 2 years notice here (more than double what a lot of other SaaS providers offer) and there will be an army of AWS engineers available to help customers migrate too. AWS do actually discontinue services all the time. It just doesn’t make the headlines because their depreciation process is so good. Now, if you wanted to discuss their billing, difficultly to navigating the literally thousands of products they offer, contradicting documentation, half baked implementations, cryptic error messages (assuming you’re even lucky enough to get an error) when deployments fail, or the dozen other hurdles that make using AWS a highly paid specialty, then I’d agree with you. But depreciation of services is one of their strengths.
  - killingtime74 2y ago
    Nit (since you typed it wrong twice): it's deprecation not depreciation
- scarface_74 2y ago
  > In the long-term that might fire back if AWS customers loose trust in the services they're using still being there in the future. Where are they going to go to get higher guarantees of services not being abandoned? Google? > The obvious solution to a possible staffing problem would of course be not fire a certain percentage of your employees every year. Have you worked for a BigTech company and seen their promo doc? No developer would want to work on a dead end service who was interested in their career.
- AtlasBarfed 2y ago
  Really? I've heard Amazon is so understanding of the difficulty in new hires picking up legacy code, even with the extremely diligent help of the other "mates" on their "team". I'm sure with the excellent work life balance, supportive atmosphere, nurturing organization, and upbeat attitude, Amazon's staffing issues are just a short blip. One thing Amazon is known for us a good place for a long term stable career! It's a good thing that organizations employment is so stable with so many foundational services that so much of our economy depends upon.
DVassallo 2y ago
It's an opportunity cost. Since they can't have infinite employees, their current employees are better allocated to other things.
- usr1106 2y ago
  For them it's 0.00...1% of their business. For a small customer who deployed on their service it might be 30% or more of their development budget. Of course that's the way corporations do business. But that's why as a small one you can't really trust any of them. You can just place bets and sometimes you lose.
  - adamc 2y ago
    To put it another way, it is an implicit cost of using AWS: You have to have contingency plans to cope with discontinued services, and you need to be able to realistically execute those plans. I think it is just another reason that AWS isn't as good a deal as it might initially appear to be for small businesses. (Larger organizations may have a better chance of amortizing these costs over many projects.)
donavanm 2y ago
Three problems with this approach. 1. The ongoing “ktlo” (keep the lights on) maintenance cost for a minimal public aws service is on the order of 6 SDEs. Theres a constant stream of security and integration improvements like new IAM policy features, KMS handling, billing & metering, console chrome, docs, etc. These are generally nonnegotiable to keep _any_ sort of consistency across AWS. This is discounting most operations/operational support, as you cant practically scale on oncall rota that small and your example is probably referring to a small customer base and a very infrastructure light service. You _could_ move that to a cheaper dev center & more shared ops, but that in itself is a lot of work. 2. Theres a lot of overlap between these services. Its often not complete, and theyll have different approaches. But fundamentally Amazons distributed nature means multiple orgs will solve similar problems that are adjacent but outside their focus, and then realize that “product” is someones elses better owned feature. Culling needs tk happen at that user experience level sooner or later. The linked blog post is a good example. 3. “Pay the average cost” is going to be shocking to see how much some of these cost to run. This cost increase is going to feel like extortion for customers who _already use other service_ and probably pay a lot more. Earning ongoing negative feedback over a minor service is not worth it. Nearly all services are priced based on a multi year forward looking marginal cost model. I would very much expect the average cost to be 10x the customer price for a small service like app mesh that never “reached scale” or got their P&L together. Then add in those dev salaries I mentioned. Most importantly those ktlo dev hours in point #1 are an opportunity cost for AWS. They should be spent on new revenue generating work, not cost reduction, and certajnly not a dead end. More than 10 years ago the rough rule of thumb was that a dev year of work should be targeting $12M/yr in revenue generation. I know we didnt consistently hit that, but thats the kind of benchmark that would be used to evaluate staffing. In AWS today if the overall product doesnt have a line of sight to $500M its not a viable innestment.
- pluto_modadic 2y ago
  explaining that KTLO requires 6 SDEs is something I wish every executive knew.
  - donavanm 2y ago

culturestate 2y ago

I mean this is a 20-month notice, that's already fairly generous by modern standards.

Dunedan 2y ago

From all what I've heard over the years, they have a problem staffing the service teams. I imagine with the AI craze that just got worse, as they certainly shifted resources to work on that. If they really have staffing problems, it'd make sense in the short-term to shut down services which don't bring in much revenue. In the long-term that might fire back if AWS customers loose trust in the services they're using still being there in the future. The obvious solution to a possible staffing problem would of course be not fire a certain percentage of your employees every year.

hnlmorg 2y ago
I have a lot of grips with AWS, but long term support isn’t one of them. They’ve given nearly 2 years notice here (more than double what a lot of other SaaS providers offer) and there will be an army of AWS engineers available to help customers migrate too. AWS do actually discontinue services all the time. It just doesn’t make the headlines because their depreciation process is so good. Now, if you wanted to discuss their billing, difficultly to navigating the literally thousands of products they offer, contradicting documentation, half baked implementations, cryptic error messages (assuming you’re even lucky enough to get an error) when deployments fail, or the dozen other hurdles that make using AWS a highly paid specialty, then I’d agree with you. But depreciation of services is one of their strengths.
- killingtime74 2y ago
  Nit (since you typed it wrong twice): it's deprecation not depreciation
scarface_74 2y ago
> In the long-term that might fire back if AWS customers loose trust in the services they're using still being there in the future. Where are they going to go to get higher guarantees of services not being abandoned? Google? > The obvious solution to a possible staffing problem would of course be not fire a certain percentage of your employees every year. Have you worked for a BigTech company and seen their promo doc? No developer would want to work on a dead end service who was interested in their career.
AtlasBarfed 2y ago
Really? I've heard Amazon is so understanding of the difficulty in new hires picking up legacy code, even with the extremely diligent help of the other "mates" on their "team". I'm sure with the excellent work life balance, supportive atmosphere, nurturing organization, and upbeat attitude, Amazon's staffing issues are just a short blip. One thing Amazon is known for us a good place for a long term stable career! It's a good thing that organizations employment is so stable with so many foundational services that so much of our economy depends upon.

DVassallo 2y ago

It's an opportunity cost. Since they can't have infinite employees, their current employees are better allocated to other things.

usr1106 2y ago
For them it's 0.00...1% of their business. For a small customer who deployed on their service it might be 30% or more of their development budget. Of course that's the way corporations do business. But that's why as a small one you can't really trust any of them. You can just place bets and sometimes you lose.
- adamc 2y ago
  To put it another way, it is an implicit cost of using AWS: You have to have contingency plans to cope with discontinued services, and you need to be able to realistically execute those plans. I think it is just another reason that AWS isn't as good a deal as it might initially appear to be for small businesses. (Larger organizations may have a better chance of amortizing these costs over many projects.)

donavanm 2y ago

Three problems with this approach. 1. The ongoing “ktlo” (keep the lights on) maintenance cost for a minimal public aws service is on the order of 6 SDEs. Theres a constant stream of security and integration improvements like new IAM policy features, KMS handling, billing & metering, console chrome, docs, etc. These are generally nonnegotiable to keep _any_ sort of consistency across AWS. This is discounting most operations/operational support, as you cant practically scale on oncall rota that small and your example is probably referring to a small customer base and a very infrastructure light service. You _could_ move that to a cheaper dev center & more shared ops, but that in itself is a lot of work. 2. Theres a lot of overlap between these services. Its often not complete, and theyll have different approaches. But fundamentally Amazons distributed nature means multiple orgs will solve similar problems that are adjacent but outside their focus, and then realize that “product” is someones elses better owned feature. Culling needs tk happen at that user experience level sooner or later. The linked blog post is a good example. 3. “Pay the average cost” is going to be shocking to see how much some of these cost to run. This cost increase is going to feel like extortion for customers who _already use other service_ and probably pay a lot more. Earning ongoing negative feedback over a minor service is not worth it. Nearly all services are priced based on a multi year forward looking marginal cost model. I would very much expect the average cost to be 10x the customer price for a small service like app mesh that never “reached scale” or got their P&L together. Then add in those dev salaries I mentioned. Most importantly those ktlo dev hours in point #1 are an opportunity cost for AWS. They should be spent on new revenue generating work, not cost reduction, and certajnly not a dead end. More than 10 years ago the rough rule of thumb was that a dev year of work should be targeting $12M/yr in revenue generation. I know we didnt consistently hit that, but thats the kind of benchmark that would be used to evaluate staffing. In AWS today if the overall product doesnt have a line of sight to $500M its not a viable innestment.

pluto_modadic 2y ago
explaining that KTLO requires 6 SDEs is something I wish every executive knew.
- donavanm 2y ago