3 ms·
Just a reminder that, if you critically depend on a IaaS/PaaS/SaaS, you should be able to trivially replace it, sometimes as quickly as overnight. Having the se
by kenhwang 8y ago
Just a reminder that, if you critically depend on a IaaS/PaaS/SaaS, you should be able to trivially replace it, sometimes as quickly as overnight. Having the service be completely open source so you can self-host generally helps, as does open protocols and standards.
Especially important when it's a Google service given their historical speed of deprecation and abruptness in announcement.
- WA 8y agoIf you can trivially replace it with something else overnight, the SaaS might be a bit too simplistic to use in the first place, no?
- kenhwang 8y agoI guess the nuance of my statement would be, trivially replaceable doesn't mean build a better product. Good examples of what I consider trivially replaceable would be services like Pingdom, DNS, S3, Cloud SQL since you can either easily build a "good enough" version, switch to another provider, or deploy your own from source. Good examples of services that are very hard to switch off of are things like Cloud Firestore or AWS Lamba.
- henryfjordan 8y agoOr there is healthy competition in the space. I think OP means you should write your interfaces with SaaS such that changing to a different provider is relatively easy (just rewrite a little client code or something to fit the new provider to your abstractions).
- skybrian 8y agoThat seems a little exaggerated. It looks like Google Cloud terms of service promise a year's notice for products in general availability. I don't think they've broken that promise? Though of course, even with notice, migration can still be annoying.
- kenhwang 8y agoIn my opinion, a year is not a lot of time for any complex integration with a service. Compare that to AWS which still support effectively-retired products indefinitely.