4 ms·

Yes, you get rid of devops. You gain vendor lock-in. You are now tied to the Amazon platform. If they shut down or suspend your account, for any reason, you ar

by maratd 11y ago

Yes, you get rid of devops. You gain vendor lock-in. You are now tied to the Amazon platform. If they shut down or suspend your account, for any reason, you are out of business. You are also paying premium for the platform, with the cost of devops built in. I'll take an open ecosystem that gives me options to migrate my business anytime over a proprietary solution.

curiousjorge 11y ago
pretty much this. amazon can at any point shut down any of these services or nerf it. if you built everything up to this point on amazon and they shut it down, it's more work.
- maratd 11y ago
  To add to your point, they have done this before and are still doing it. There is no guarantee of continued service. http://recode.net/2015/03/18/amazon-will-shut-down-amazon-webstore-its-competitor-to-shopify-and-bigcommerce/ http://recode.net/2015/03/18/amazon-will-shut-down-amazon-we...
  - duskwuff 11y ago
    Amazon Webstore wasn't part of AWS, though. It was part of their commerce wing - very different.
    - curiousjorge 11y ago
      remember PiCloud? they shut down after I spent a quarter building around their API calls. I never want to repeat that mistake and you also get the bonus of being able to sell your source code or deploy local cloud if an enterprise are willing to pay extra for it.
andyidsinga 11y ago
There's always this tension, its really interesting. I think the open ecosystem approach will work well for apps/systems that are more established and have a predictable and sustainable user base and related revenue stream to maintain the system. But for new ideas, early stage startups, the open eco-system approach will be a lot more work than using the high-level services providers like amazon are developing ...basically a no-stack approach can help one quickly find some product / market fit. Once some level of baseline level of utilization is understood then switching to a more difficult, but less-locked in approach would be smart. all that said, there's probably a middle ground here too (but arguably not) -- where one deploy's using docker containers, private registry & image repo, s3 for static immutable storage and some open database like PostgreSQL on RDS. All that could be layered on top of AWS and other providers -- but it will still be a PITA to move the whole thing. BTW -- take a look at the elasticbox product -- they really have an interesting approach to cloud that sort of obviates the lock-in issue by allowing one to build apps across clouds from the start using their "boxes" metaphor.

by maratd 11y ago

curiousjorge 11y ago

pretty much this. amazon can at any point shut down any of these services or nerf it. if you built everything up to this point on amazon and they shut it down, it's more work.

maratd 11y ago
To add to your point, they have done this before and are still doing it. There is no guarantee of continued service. http://recode.net/2015/03/18/amazon-will-shut-down-amazon-webstore-its-competitor-to-shopify-and-bigcommerce/ http://recode.net/2015/03/18/amazon-will-shut-down-amazon-we...
- duskwuff 11y ago
  Amazon Webstore wasn't part of AWS, though. It was part of their commerce wing - very different.
  - curiousjorge 11y ago
    remember PiCloud? they shut down after I spent a quarter building around their API calls. I never want to repeat that mistake and you also get the bonus of being able to sell your source code or deploy local cloud if an enterprise are willing to pay extra for it.

andyidsinga 11y ago

There's always this tension, its really interesting. I think the open ecosystem approach will work well for apps/systems that are more established and have a predictable and sustainable user base and related revenue stream to maintain the system. But for new ideas, early stage startups, the open eco-system approach will be a lot more work than using the high-level services providers like amazon are developing ...basically a no-stack approach can help one quickly find some product / market fit. Once some level of baseline level of utilization is understood then switching to a more difficult, but less-locked in approach would be smart. all that said, there's probably a middle ground here too (but arguably not) -- where one deploy's using docker containers, private registry & image repo, s3 for static immutable storage and some open database like PostgreSQL on RDS. All that could be layered on top of AWS and other providers -- but it will still be a PITA to move the whole thing. BTW -- take a look at the elasticbox product -- they really have an interesting approach to cloud that sort of obviates the lock-in issue by allowing one to build apps across clouds from the start using their "boxes" metaphor.