3 ms·

I find the biggest source of lock-in is that it's really hard to move a bunch of data. The longer you stay, the harder it is to leave, because the impact (downt

I find the biggest source of lock-in is that it's really hard to move a bunch of data. The longer you stay, the harder it is to leave, because the impact (downtime, slowness, resources allocated to moving data instead of building your business) on your product/service is likely to be bigger. As you research this, don't neglect the cost of attempting to remain vendor agnostic. Every level of abstraction adds new costs (for some people it's worth it, no doubt!). Sometimes it's more efficient to just go all-in with a vendor.

bombcar 4y ago
Inertia is a huge lock-in. Almost willing to say if you’re not moving cloud every five years or maintaining two clouds at all time you will get so much inertia you’ll be stuck.
tech_tuna 4y ago
This, of course, isn't new. I once worked at a company that was tasked with migrating data out of a CM system built by a company where I had also worked about 10 years earlier. I ended up pinging one of the founders at the old company and asked him how we'd go about extracting the data using the platform's data (we were wondering because we kept running into stability issues doing this). He basically told me what I suspected, there was no good way to do that. Because of the way the cache worked in the product, it would never stay up if every single data record were fetched via the API. We ended up pulling it all out of the database directly, which was a bit of a pain. tl;dr no vendor really wants to make it easy to pull ALL of your data out of their system.
- tech_tuna 4y ago
  >extracting the data using the platform's data Meant to type (and can't edit apparently) "extracting the data using the platform's API"
__derek__ 4y ago
Not just hard, but expensive. The Acquired podcast episode on AWS[1] highlighted a particularly ironic angle of this: > David: I can do you one better. Another example. Amazon.com used Oracle databases when it was started. Amazon.com did not finish their migration off of Oracle databases and onto AWS products until 2019. > Ben: Oh, my God. > David: Thirteen years after AWS launched. > Ben: That is insane. > David: It took that long for Amazon itself to migrate off of Oracle. [1]: https://www.acquired.fm/episodes/amazon-web-services https://www.acquired.fm/episodes/amazon-web-services
- ajkjk 4y ago
  Anecdotally, from when I worked there in ~2015, there were a few good reasons: (a) a lot of Amazon's software was so old that it connected directly to the databases. We had to finish all of the SOA migrations that were long overdo -- all the misc random tools no one had gotten around to migrating -- before we could even contemplate moving off Oracle. (b) it wasn't done as a simple port; instead, the systems were re-architected in the process to no longer share backing databases as at all, which basically meant it needed a complete rewrite, which took a long time to get funded and then a long time to deliver.
  - ltbarcly3 4y ago
    These are just reasons, not good reasons.
    - ajkjk 4y ago
      True. I felt like they were good reasons at the time, or rather that they were basically the best you could do given that the can had been kicked down the road for far too long. As usual putting off solving tech debt ends up costing >10x in total.
    - scarmig 4y ago
      Is the implication here that it was a bad engineering choice to not start with a full SOA? It seems AWS made the right trade offs when it was starting, given its current position. The proof is in the pudding.
      - ltbarcly3 4y ago
        So since AWS is successful, every decision they made was perfect? I don't even know how to respond to that kind of logic.
  - __derek__ 4y ago
    No doubt. This was an amusing aside, not a critique, intended to illustrate the long-term impact of storage choices. That's part of the bull-case for AWS long-term, and why we see projects like AWS Snowball.

bombcar 4y ago

Inertia is a huge lock-in. Almost willing to say if you’re not moving cloud every five years or maintaining two clouds at all time you will get so much inertia you’ll be stuck.

tech_tuna 4y ago

This, of course, isn't new. I once worked at a company that was tasked with migrating data out of a CM system built by a company where I had also worked about 10 years earlier. I ended up pinging one of the founders at the old company and asked him how we'd go about extracting the data using the platform's data (we were wondering because we kept running into stability issues doing this). He basically told me what I suspected, there was no good way to do that. Because of the way the cache worked in the product, it would never stay up if every single data record were fetched via the API. We ended up pulling it all out of the database directly, which was a bit of a pain. tl;dr no vendor really wants to make it easy to pull ALL of your data out of their system.

tech_tuna 4y ago
>extracting the data using the platform's data Meant to type (and can't edit apparently) "extracting the data using the platform's API"

__derek__ 4y ago

Not just hard, but expensive. The Acquired podcast episode on AWS[1] highlighted a particularly ironic angle of this: > David: I can do you one better. Another example. Amazon.com used Oracle databases when it was started. Amazon.com did not finish their migration off of Oracle databases and onto AWS products until 2019. > Ben: Oh, my God. > David: Thirteen years after AWS launched. > Ben: That is insane. > David: It took that long for Amazon itself to migrate off of Oracle. [1]: https://www.acquired.fm/episodes/amazon-web-services https://www.acquired.fm/episodes/amazon-web-services

ajkjk 4y ago
Anecdotally, from when I worked there in ~2015, there were a few good reasons: (a) a lot of Amazon's software was so old that it connected directly to the databases. We had to finish all of the SOA migrations that were long overdo -- all the misc random tools no one had gotten around to migrating -- before we could even contemplate moving off Oracle. (b) it wasn't done as a simple port; instead, the systems were re-architected in the process to no longer share backing databases as at all, which basically meant it needed a complete rewrite, which took a long time to get funded and then a long time to deliver.
- ltbarcly3 4y ago
  These are just reasons, not good reasons.
  - ajkjk 4y ago
    True. I felt like they were good reasons at the time, or rather that they were basically the best you could do given that the can had been kicked down the road for far too long. As usual putting off solving tech debt ends up costing >10x in total.
  - scarmig 4y ago
    Is the implication here that it was a bad engineering choice to not start with a full SOA? It seems AWS made the right trade offs when it was starting, given its current position. The proof is in the pudding.
    - ltbarcly3 4y ago
      So since AWS is successful, every decision they made was perfect? I don't even know how to respond to that kind of logic.
- __derek__ 4y ago
  No doubt. This was an amusing aside, not a critique, intended to illustrate the long-term impact of storage choices. That's part of the bull-case for AWS long-term, and why we see projects like AWS Snowball.