Live data from Hacker News

Cost of serving billions of images per month

medium.com

101–110 of 138 posts

Re: Cost of serving billions of images per month

#101

The numbers being thrown around on this post are staggering. Not the bandwidth, storage or or the number of images —they're all pretty average for a small image host— but the casual tone that they're willing to throw money at services rather than engineering some quite simple problems. Seriously, I know I'm not in their shoes but I know what they do, I know popular options in these areas and I know they are literally…

Doing a cost benefit analysis and deciding that using a service instead of hiring and paying humans is a perfectly rational decision. I’ve downvoted because I see a lot of vitriol like this and it’s exhausting to argue each time that these decisions are carefully considered and work well for the people making them.

This is no different from saying people should be ashamed because they pay so much for food, then it’s much cheaper (almost free!) to grow it yourself in a pot.

Re: Cost of serving billions of images per month

#102

Earlier quoted context omitted.

How would Terraform help you move between cloud providers when all of the provisioners are specific to the cloud platform. If you’re a small startup, the least of your business risks are one of the major cloud providers shutting down.

> How would Terraform help you move between cloud providers when all of the provisioners are specific to the cloud platform You don't move. You load balance across the clouds prior to the disaster. You have your stuff work on both. I mentioned K8s because you could set up a managed cluster of that on a few cloud providers, and most of your TF will be the same in terms of setting up k8s, with some differences on how y…

You don't move. You load balance across the clouds prior to the disaster.

Again, this is a small struggling company, do you really think they should be spending resources having a backup plan just in case AWS has a multi AZ or multi region outage? Is that really their largest business risk?

Also do they really want to go from the simplicity of Heroku all the way to k8s?

The only things that a company at this level needs to be concerned about are reducing burn rate, finding a way to better monetize, and getting another round of funding.

But, I seriously doubt that a company spending 100K a month would be on their free support plan and not have a business or Enterprise support plan where they wouldn’t have someone to call at AWS with a much smaller SLA than 12 hours. We are a small company and I can just open a support ticket and get someone on the phone/chat immediately.

And if you are a small startup, you aren’t just using AWS with a few VMs. You’re probably also using a lot of other managed services that aren’t VM based. If you are hosting everything yourself. You might as well be at a colo. If you are using your cloud provider as an overpriced data center hosting VMs, you’re probably doing it wrong.

Re: Cost of serving billions of images per month

#103
post #53

Earlier quoted context omitted.

I do both at work, small sites on Heroku and big / compliance required ones on AWS, and the Heroku ones don’t need a devops team, while the AWS deployments do. Given the cost of building the devops teams and the time they spend, it is a big factor. Prefer to default to a Heroku unless there’s a clear cost benefit analysis that includes human and opportunity costs.

if it is a simple deployment that you could do with Heroku, it would be just as simple with Elastic Beanstalk. You just give it your zipped artifacts. If later on you need to do something more complex you have all kinds of extension points. If you want something cleaner and just to use a Github -> CodeBuild -> Code Commit/Lambda deployment and have something closer to traditional deployment pipeline, there are the Co…

I’ve done both, and many projects start on Heroku then move to AWS once they hit scale. And every single time I keep cursing at how many hidden man-hours are spent on AWS maintenance. If you’ve tracked the time spent on AWS that wouldn’t be spent on Heroku, and plotted that against the cost of your leads’ and devops team’s time, and your opportunity costs, and you still feel it’s worth it, by all means go straight to AWS.

The point is that costs on Heroku and AWS are two intersecting lines with different slopes and y-axis starting points. The dollar cost is the basic dimension, but once you add team hourly rate and opportunity cost you’ll see that Heroku is cheaper than AWS until you hit X000 req/sec or users. That number is varies from team to team, but it’s higher than you think.

Re: Cost of serving billions of images per month

#104

The numbers being thrown around on this post are staggering. Not the bandwidth, storage or or the number of images —they're all pretty average for a small image host— but the casual tone that they're willing to throw money at services rather than engineering some quite simple problems. Seriously, I know I'm not in their shoes but I know what they do, I know popular options in these areas and I know they are literally…

The curious thing is that they don't pay the photographers. So that kills the stock photo business model for everyone else. You can't take nice pictures and expect that some day someone will pay you for the un-watermarked versions now UnSplash has taken that market away.

So money is now going to these CDN hosts and other software suppliers, spent like water with a business plan that is not in the article. I guess the likes of Adobe can bung them a few million a year as the service is worth that to them. Same with Squarespace, they can partner and pay a few million to keep unSplash's lights on.

So this has some interesting negative effects from local communities where people once had their own websites and their own local photography businesses. Although unSplash might not directly be reaming out every small town in the world making it impossible for anyone to make a living from stock photography, Squarespace kind of are. Web pages have made themselves complicated today, once you needed Notepad and an FTP program, nowadays you need a team of developers to spend months in order to put 'hello world' online. So people are nowadays going with Squarespace and other highly marketed services, that, in turn, rely on UnSplash.

The images initially look very impressive with UnSplash but I was once really impressed by a Pret A Manger cafe. Then I realised there were many Pret A Manger cafes in many towns and they all were the same inside. Quality stuff but identikit. At the same time, each outlet was not exactly identical, there could be a different amount of chairs, the counters could be laid out differently. (Readers outside the UK could swap Starbucks for Pret a Manger).

I see UnSplash as a photo version of a Pret a Manger cafe. After a while the images are all very much the same. This is good and it is bad. It is bad in that so much of the internet becomes predictable and generic. It is good in that it becomes quite easy to do better. Much like how you can do better than Pret a Manger at making a sandwich, just by making your own, so it is with UnSplash, you can get far better photos for your project by taking your own photos and doing your own editing.

I would not bet against the success of UnSplash any more than I would bet against the success of Pret A Manger. However, I will be making my own bread or visiting independent cafes, oh, and taking my own photos rather than using 'free' formulaic stock photos.

Enough of the analogies, a critique of UnSplash and what they are not doing. If you look at a Squarespace site that has some UnSplash banner then the image will be several thousand pixels by several thousand pixels. This is good but bad. Good in that native phone camera resolution images are nice to see, bad for bandwidth.

This bandwidth is mitigated by CDNs. The CDNs do the different resolutions but it is quite dated tech being used to do this. I think that for most website owners, e.g. one's small business, there is a performance benefit in using one's own hosting and running Google Pagespeed to optimise and serve the images. This can work with the low bandwidth browser flag and do responsive source sets.

This means putting the original image dimensions in the HTML for Pagespeed to write out the srcset images, putting in a picture element and so forth. The images also get sent as webp when needed.

Now if I did want to show some thousand pixel images then I would want to do that with OpenSeadragon. This takes the deep zoom aspect to a whole new level. It works fine for a small website without a complex CDN.

Now there is no reason why I could not 'steal' a few UnSplash images and serve them my own special way with Google Pagespeed doing all the work on my own server but I am not going to be running generic stock photos anyway.

Google's Pagespeed falls in between the gaps between large compartmentised teams so nobody is using it. Why would you when for the same reasons as nobody ever got fired for buying IBM, nobody gets fired for spending a fortune on a CDN? However, if Squarespace and other UnSplash clients decide they can actually offer a better, faster product due to improved tech for serving images then they can start doing their own stock photography.

Re: Cost of serving billions of images per month

#105

The numbers being thrown around on this post are staggering. Not the bandwidth, storage or or the number of images —they're all pretty average for a small image host— but the casual tone that they're willing to throw money at services rather than engineering some quite simple problems. Seriously, I know I'm not in their shoes but I know what they do, I know popular options in these areas and I know they are literally…

Doing a cost benefit analysis and deciding that using a service instead of hiring and paying humans is a perfectly rational decision. I’ve downvoted because I see a lot of vitriol like this and it’s exhausting to argue each time that these decisions are carefully considered and work well for the people making them. This is no different from saying people should be ashamed because they pay so much for food, then it’s…

Being able to come to the decision that in-housing isn't good value, is of course possible. But they do it for everything. And they've been exhaustive enough in their breakdown here that it's trivial to any experience developer that they're spaffing money away.

They're not in an all-or-nothing situation. There are so many individual elements that they could improve efficiency on and they're just not.

And I think cooking your own food vs going to a restaurant is a better analogy (because it focuses on a service provision, not resource gathering). They're currently eating out, seven days a week.

Re: Cost of serving billions of images per month

#106
I'm using unsplash for a while, They have the best quality free to use pictures on the internet.

As someone who appreciate creative marketing i like how they generate millions of backlinks by asking you to link back to their site and credit the author.

In few years they became among the most popular sites in their niche, a lot thanks to their creative growth approach.

Re: Cost of serving billions of images per month

#107

Earlier quoted context omitted.

if it is a simple deployment that you could do with Heroku, it would be just as simple with Elastic Beanstalk. You just give it your zipped artifacts. If later on you need to do something more complex you have all kinds of extension points. If you want something cleaner and just to use a Github -> CodeBuild -> Code Commit/Lambda deployment and have something closer to traditional deployment pipeline, there are the Co…

I’ve done both, and many projects start on Heroku then move to AWS once they hit scale. And every single time I keep cursing at how many hidden man-hours are spent on AWS maintenance. If you’ve tracked the time spent on AWS that wouldn’t be spent on Heroku, and plotted that against the cost of your leads’ and devops team’s time, and your opportunity costs, and you still feel it’s worth it, by all means go straight to…

I’m mostly a developer but I am also the person they trot out as the representative of our (nonexistent) infrastructure team to clients and lead most of the “cloud native” initiatives.

We do a lot more with AWS’s managed services that would go beyond what Heroku could do.

That being said, if we were just a simple database+website. How would AWS maintenance be any more than going through the VPC creation wizard one time and using Elastic Beanstalk for deployments? I’m very much an advocate of managed services so it’s not that I’m anti Heroku - that would be hypocritical if I’m saying using EB - But how is it easier?

With Elastic Beanstalk if later on if you do need to add complexity, you easily can through startup scripts and .ebextensions (cloud formation).

Re: Cost of serving billions of images per month

#108
Everyone here seems to be screaming about how high their Heroku bill is, but I’m more interested in how they keep their New Relic bill so low. I find that New Relic are fine early on, and then the costs explode as you scale up and there’s no way to justify spending huge amounts of money on their platform.

Re: Cost of serving billions of images per month

#109

Earlier quoted context omitted.

And some projects really are just simple. Scale makes no difference to their services, it's a basic OLTP + search with resizing image proxy. This doesn't have any SLAs nor is it critical software either. 24/7 oncall is completely unnecessary.

I just had a look at your b2b site Do you actually run pay-per-action campaigns, or do you provide a dashboard for the customer data ?

We started as a native ad network and have pivoted to B2B with our own proprietary B2B data, which then powers a platform to run campaigns for marketers, and intel for sales teams. We also have a legacy adnetwork business for publishers.

Re: Cost of serving billions of images per month

#110

I like Unsplash. They and Pixabay are what I use for apps I have developed in the past. But simply, this floors me. I looked at their costs and with some developer muscle, you could find savings such as: - Move Fastly to Cloudflare. They don't expressly say what the cost is for that. But moving to CF would eliminate it. - Move Heroku to Digital Ocean. It's not difficult to create a fully redundant solution. - Move fr…

Resizing images in Golang is not as trivial as you might imagine at first. You need to be able to handle all sorts of formats and color spaces. You'd be surprised by the kind of weird garbage your users will upload. Then you need to use SIMD, not pure Golang solutions, or performance will suffer. So you end up adopting a wrapper around libvips or similar, at which point you will start to ponder if you should have stuck with C/C++ in the first place. (It all depends on how much of Go's features you use or if it's just a nicer, safer C for you.)
Post reply on HN