Cloud Resource Deprecation Risks

Introduction

This week, Amazon AWS announced (relatively quietly) that they were no longer allowing the creation of a handful of their lesser-used resources (the most prominent of which was CloudCommit, their source code repository product). Inevitably, the people using those resources have started to worry about their future - will Amazon withdraw the services completely? will they lose data? how much work is required? You name it.

In the interests of fairness, Amazon announced that customers can no longer create these resources, but they haven't announced anything to do with their complete withdrawal. So customers using those resources have some time to work out what they want to do.

The other important point here is that whilst it's Amazon doing this at the moment, all cloud providers will do this at some point. In fact, you can expect the same from SaaS providers as well. Things change, and so do the services provided by vendors.

Open Questions

This all leaves a few questions such as:

Ultimately, there are several risk decisions to be made here.

Quantifying Risks

It's always hard to quantify risks, and it's as good as impossible to know for sure what any given vendor will do in the future. However, we can certainly make some educated guesses:

  1. Likelihood of deprecation: If a resource or feature is not widely used, then the chances are higher that it could be deprecated. In contrast, if many customers use a given service, then the likelihood decreases.
  2. Time to deprecate: Some resources might be deprecated quickly (e.g., within months), while others might last for years. It depends on the resource and its usage.
  3. Migration effort: Depending on how tightly coupled your application is with the specific service being deprecated, the effort required to migrate might be significant or minimal.
  4. Cost impact: The cost impact will depend on whether there are alternative resources that can be used at a similar price point or if you need to switch to a more expensive solution. For example, Amazon have some overlapping services, so it may be possible to use a similar resource elsewhere.

We can also think about the "criticality" of a feature or resource to the vendor. Amazon is unliklely to deprecate S3 Storage because it's used in so many places. That's not to say they won't change it - indeed they have changed it a few times over the years to try to plug up some common misconfigration problems. They are deprecating their Git repository service though, possibly due to massive competition from a couple of other providers in the same space. As such, S3 is "critical", but Git is not so important to them - making it a candidate for deprecation.

Mitigation Strategies

With the risks in mind, there are a number of mitigation strategies we can use.

  1. Keep an eye on vendors: Monitoring vendors announcements can give you notification of something being deprecated, but also might give some clues about things that may come up in future.
  2. Simplify your architecture: By removing some of the more exotic resources from your architecture you reduce your 'surface' and lessen the chances of something beinf deprecated. Simplifying has lots of other beneifts too, in the cloud specifically there may be cost savings in simplification.
  3. Use Open Standards whenever possible: Open Standard resources are the most easily replaceable, and often may be the ones least likely to be deprecated.
  4. Consider multiple cloud providers: In some cases it may be possible to avoid using a niche resource in one cloud and use a core-feature in another. This isn't likely to work for all resources, but it might work for some of the more loosely coupled ones.

Ultimately though, the best mitigation is being able to respond quickly to any changes in the features available at your chosen cloud provider. You can take advantage of new features, whilst closing down the old ones comfortably within the timescales given to you by the provider.

Conclusion

In conclusion, while it's impossible to predict exactly when or if a particular resource will be deprecated, there are steps that can be taken to mitigate the risks associated with this eventuality. By regularly monitoring vendor updates, diversifying services, implementing robust backup strategies, planning for migration, and staying informed about industry trends, you can reduce the impact of resource deprecation on your business operations.

Conclusions

All vendors introduce and deprecate features, and they largely do so on their own timetable which you likely have little influence over. For any help migrating from one resource to another, around vendors or anything else, please contact us - we can help you figure out what you need and make it work for you.