3 ms·

I'd cloud vendor lock-in a serious concern for most businesses? It always feels like a requirement that originates from the technical side rather than the busin

I'd cloud vendor lock-in a serious concern for most businesses? It always feels like a requirement that originates from the technical side rather than the business side. But it never feels like it's that important actually.

ddorian43 9y ago
It is important for those not on the cloud: dedicated servers and colo.
- rconti 9y ago
  You should pluralize that 'colo' then. I've been through datacenter power outages, refusal to renew, and difficulty in getting circuits in a timely manner in multiple Tier 4 datacenters. Self-hosting is only as good as your planning, strategy, and execution, which is much the same as the cloud world. You're probably safer running a single EC2 instance than running a single dedicated server in some random colo, but certainly running your own geographically distributed infrastructure is likely better than relying on a single AWS availability zone (for example). However, it's a great idea to open up peoples' eyes to the idea of how being on a major cloudy provider can make you collateral damage of an attack that never would have targeted you if you were in DIY mode.
manigandham 9y ago
It's a overblown concern for many, considering that the major clouds are massive companies that will likely be around far longer than most of their customers (or will acquire them). Every new client actually contributes to the longevity of a cloud provider. There's also lots of competition to offer similar features and many services can be mixed/matched easily (eg: we run on GCP but use Azure event hubs).
scaryclam 9y ago
We have a bunch of work that requires large, process heavy, calculations, so yes, vendor lock-in is a concern for us as it can mean either huge cost increases, if the vendor changes pricing for the required instances upwards, or huge savings if a competitor can do the same computations for less. We solve this problem by making sure we can trash servers and spin them up elsewhere if needs be (mostly via terraform etc). I don't think this should apply to anyone running some hosts for web applications though.
- movedx 9y ago
  Just out of interest, when have AWS increased their prices?
  - manigandham 9y ago
    Never.
e12e 9y ago
My main concern with vendor lock-in in hosting (not just cloud), is that it'll easily turn business problems into ops problems. Credit card suspended because of (possibly spurious) "suspicious activity"? Cloud account suspended for non-payment. Trouble with hosting company x invoicing? Same result. Spurious DMCA takedown filed? Maybe a TOS violation - account suspended. Etc... It's not so much that most of these would be permanent - but it does add risk of downtime from the "not ops domain" to the ops domain. And multiple providers isn't a universal fix - but it might mitigate some risk.
caleblloyd 9y ago
I think that vendor lock-in on a cloud is more about reliance on technologies designed for a specific cloud. AppEngine, DynamoDB, or Cloud Formation being examples. To avoid lock in, use technologies like Kubernetes, MongoDB, or Terraform instead. That way jumping clouds is at least possibly without a rewrite.

ddorian43 9y ago

It is important for those not on the cloud: dedicated servers and colo.

rconti 9y ago
You should pluralize that 'colo' then. I've been through datacenter power outages, refusal to renew, and difficulty in getting circuits in a timely manner in multiple Tier 4 datacenters. Self-hosting is only as good as your planning, strategy, and execution, which is much the same as the cloud world. You're probably safer running a single EC2 instance than running a single dedicated server in some random colo, but certainly running your own geographically distributed infrastructure is likely better than relying on a single AWS availability zone (for example). However, it's a great idea to open up peoples' eyes to the idea of how being on a major cloudy provider can make you collateral damage of an attack that never would have targeted you if you were in DIY mode.

manigandham 9y ago

It's a overblown concern for many, considering that the major clouds are massive companies that will likely be around far longer than most of their customers (or will acquire them). Every new client actually contributes to the longevity of a cloud provider. There's also lots of competition to offer similar features and many services can be mixed/matched easily (eg: we run on GCP but use Azure event hubs).

scaryclam 9y ago

We have a bunch of work that requires large, process heavy, calculations, so yes, vendor lock-in is a concern for us as it can mean either huge cost increases, if the vendor changes pricing for the required instances upwards, or huge savings if a competitor can do the same computations for less. We solve this problem by making sure we can trash servers and spin them up elsewhere if needs be (mostly via terraform etc). I don't think this should apply to anyone running some hosts for web applications though.

movedx 9y ago
Just out of interest, when have AWS increased their prices?
- manigandham 9y ago
  Never.

e12e 9y ago

My main concern with vendor lock-in in hosting (not just cloud), is that it'll easily turn business problems into ops problems. Credit card suspended because of (possibly spurious) "suspicious activity"? Cloud account suspended for non-payment. Trouble with hosting company x invoicing? Same result. Spurious DMCA takedown filed? Maybe a TOS violation - account suspended. Etc... It's not so much that most of these would be permanent - but it does add risk of downtime from the "not ops domain" to the ops domain. And multiple providers isn't a universal fix - but it might mitigate some risk.

caleblloyd 9y ago

I think that vendor lock-in on a cloud is more about reliance on technologies designed for a specific cloud. AppEngine, DynamoDB, or Cloud Formation being examples. To avoid lock in, use technologies like Kubernetes, MongoDB, or Terraform instead. That way jumping clouds is at least possibly without a rewrite.