4 ms·

The root of this particular issue was Vimeo's failure to do this migration for their customers. Vimeo OTT has a codebase written in Rails, whereas the main PHP

by muglug 4y ago

The root of this particular issue was Vimeo's failure to do this migration for their customers. Vimeo OTT has a codebase written in Rails, whereas the main PHP application is written in PHP. At the time Vimeo acquired Vimeo OTT's codebase, the Vimeo OTT codebase was small — around 10,000 lines of Ruby. Rewriting that codebase inside the Vimeo PHP application would have been a tough technical challenge for the all-Ruby team, and they'd have likely lost some people along the way and missed out on some content deals, so they decided instead to maintain two separate codebases and two separate login systems. The video-playback and video-storage infra has since been unified, but all the business logic is still siloed.

macspoofing 4y ago
>The root of this particular issue was Vimeo's failure to do this migration for their customers. Yes and No. At the end of the day, you as a business have to insulate yourself from your infrastructure provider.
- notyourday 4y ago
  Vimeo is the only infrastructure provider providing that service. It is impossible to insulate a business from it.
  - macspoofing 4y ago
    You're saying it's impossible to not accidentally delete 7TB of videos, and when you do, to blame it on Vimeo?
conductr 4y ago
He wasn’t asking them to refactor their internal code bases. But they should be able to whip up the 20 lines of code needed to do this between APIs (or just directly on their servers). Essentially what author was trying to do when he screwed up. For the author this was disposable code, for Vimeo this would have been a reusable utility. I know how these things happen. Support ticket queues and all. And while I don’t fully know the difference in cost, I would assume a customer upgrading to an Enterprise plan would get a better support experience. Whoever within authors company negotiated the upgrade to Enterprise (or didn’t) and failed to embed some agreement around OTT to Enterprise transition assistance was the one who made the first mistake.
chernevik 4y ago
Per the post, Vimeo DID do it -- without telling the customer! And then wouldn't help uncluster the situation.

by muglug 4y ago

macspoofing 4y ago

>The root of this particular issue was Vimeo's failure to do this migration for their customers. Yes and No. At the end of the day, you as a business have to insulate yourself from your infrastructure provider.

notyourday 4y ago
Vimeo is the only infrastructure provider providing that service. It is impossible to insulate a business from it.
- macspoofing 4y ago
  You're saying it's impossible to not accidentally delete 7TB of videos, and when you do, to blame it on Vimeo?

conductr 4y ago

He wasn’t asking them to refactor their internal code bases. But they should be able to whip up the 20 lines of code needed to do this between APIs (or just directly on their servers). Essentially what author was trying to do when he screwed up. For the author this was disposable code, for Vimeo this would have been a reusable utility. I know how these things happen. Support ticket queues and all. And while I don’t fully know the difference in cost, I would assume a customer upgrading to an Enterprise plan would get a better support experience. Whoever within authors company negotiated the upgrade to Enterprise (or didn’t) and failed to embed some agreement around OTT to Enterprise transition assistance was the one who made the first mistake.

chernevik 4y ago

Per the post, Vimeo DID do it -- without telling the customer! And then wouldn't help uncluster the situation.