> What about blaming the companies who decided to depend upon a service that they have no control over?
Unless you're advocating against any kind of *aaS, this is kind of a silly argument.
A lot of these services are not "a few days of development" worth of work. The value in these is that they have dedicated teams of people who's entire job is to run that specific targeted thing. Unless you're willing to also invest in major development, it's going to be difficult to match that functionality.
Obviously when you make your product/company depend upon these things, you're taking a risk that they could go away, but you protect yourself against that by having robust contracts.
Outages are different, but for a significant outage you expect to see some kind of RFO and explanation of how they're going to mitigate it.
Deliberately withdrawing service for all customers with 30 minutes notice? That's entirely the fault of whomever is in charge at Smyte.
Even 30 days, while it'd probably ruin some existing plans, would at least allow people to have a chance to migrate without things just breaking.
>A lot of these services are not "a few days of development" worth of work. The value in these is that they have dedicated teams of people who's entire job is to run that specific targeted thing. Unless you're willing to also invest in major development, it's going to be difficult to match that functionality.
For the cases I was involved in, there were options of buying the service but hosting it internally with some update pipeline. So even if the updates were suddenly turned off, you have a far longer time to swap to a different system. Generally deploying these aren't to much time, but what is really the issue to me isn't that the options that were chosen were the ones which were chosen, but that the process of choosing them did not evaluate the risks of creating such a strong external dependency at all. Its one thing if it is a risk taken with full knowledge of the potential costs and benefits, it is another when people do it because they think there is no possible downside.
Unless you're advocating against any kind of *aaS, this is kind of a silly argument.
A lot of these services are not "a few days of development" worth of work. The value in these is that they have dedicated teams of people who's entire job is to run that specific targeted thing. Unless you're willing to also invest in major development, it's going to be difficult to match that functionality.
Obviously when you make your product/company depend upon these things, you're taking a risk that they could go away, but you protect yourself against that by having robust contracts.
Outages are different, but for a significant outage you expect to see some kind of RFO and explanation of how they're going to mitigate it.
Deliberately withdrawing service for all customers with 30 minutes notice? That's entirely the fault of whomever is in charge at Smyte.
Even 30 days, while it'd probably ruin some existing plans, would at least allow people to have a chance to migrate without things just breaking.