Vimeo ipo price12/5/2023 ![]() A "view" can be anywhere from 1 to 50 Mbps depending on quality, and if you're paying for transit then your costs are also proportional to the length of that view. IP transit is typically charged by bytes sent, and peering costs are typically some large fixed cost to get a pipe of a specific capacity to a given network. ![]() Of course, this one case could also just be an outlier, and perhaps Vimeo is hosing everyone else with high-margin custom plans. But Vimeo is almost certainly larger than you, so they almost certainly have better bandwidth deals than you. I don't know what your bandwidth arrangements are, and I suspect you are not at liberty to explain them. I have no idea how you guys would be even breaking even, at $59/mo plus $1 for every 1k views over 50k. If you're uploading very long videos (multiple hours) and have a use case (art tutorials) that demands watching at 1080p or 4K, then even a few hundred views will breach 10TB+ of bandwidth per video. If the creator in question were to self-host their own video on AWS or Fastly, they'd be paying about what Vimeo wants to charge them. I'm not sure Vimeo is miscalculating, at least in the specific case listed in the article. Vimeo is actually correct and you're about to become the next niche online creator subsidy vehicle Vimeo doesn't have the scale necessary for peering and is thus getting a raw deal on bandwidth that you've managed to avoid somehow Vimeo is very wrong about how they calculate their bandwidth costs per user Everything I know about how networks pay each other for this would suggest that you're charging a blended rate for a good whose cost is highly variable. I have to wonder how your pricing model of "views" is going to fare when Vimeo is dumping what they consider to be their worst customers onto you. They are so big that every ISP absolutely has to peer with them, and that drives down their costs significantly. This is the particular reason why Google is able to provide YouTube at all. Vimeo's cited custom plan pricing in the article is basically assuming a video per month on average at those rates. ![]() Delivering that over 800 views will run about $320 per video. Given that I can't find hosting providers with lower bandwidth costs, DO/Vultr either have very specific peering agreements or are subsidizing their bandwidth charges either of which would be utterly broken by the amount of bandwidth that the person from the article appears to need for their multi-hour art tutorials.Įven if they had an amazing deal on transit, or were peered with everyone, and were able to provide $0.01/GB to video hosting at scale, we're still talking 20-40GB/view (assuming 45Mbps delivery of multi-hour video content). I looked at AWS EC2 and Fastly and they both cited outgoing bandwidth that was twice as high. The $0.05/GB pricing cited is for CDN delivery, which implies having a bunch of servers in different areas of the world ready to deliver your files wherever they need to be. (All this gets upended if you're on something like SFDC or Dynamics, though, where costs looks nice and forecastable until you get to disk storage, where their pricing models appear to be put together by the kind of guys who usually present their invoices alongside a menacingly-brandished lead pipe.) ).ĭepending on what your application is, this may never be an issue, or, if you're pushing heavy file and content traffic, it could form a huge chunk of variable costs that you need to figure out cost recovery for in your business model. ![]() (The ever-invaluable Duckbill does a nice job of laying out all the places where AWS levies its bandwidth tax. Bandwidth and network services, however, are insanely expensive for what you get, show up all over your service architecture, and are hard to forecast, so they like to jump out of dark corners at the end of your billing cycle and mug you. Yeah, it's really just a way to talk through cloud architectural choices when you're designing for cost: committing to reserved instances for VMs (goodbye, eternal soul - for at least the next three years), minimizing your data retention or migrating through storage classes for bucket data, and ruthlessly optimizing your use of per-usage services (bucket ops, API calls, serverless functions, and charge-per-op databases like Firebase, to name a few).
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |