Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Comparing Cloud-Based Image Services For Developers

samzenpus posted about 7 months ago | from the compare-and-contrast dept.

Cloud 28

Nerval's Lobster writes "As Web applications grow in number and capability, storing large amounts of images can quickly become a problem. If you're a Web developer and need to store your client images, do you just keep them on the same server hosting your Website? What if you have several gigabytes worth of images that need to be processed in some way? Today, many developers are looking for an easy but cost-effective solution whereby images can be stored in the cloud and even processed automatically, thus taking a huge load off one's own servers, freeing up resources to focus on building applications. With that in mind, developer and editor Jeff Cogswell looks at a couple different cloud-based services for image storage and processing. At first glance, these services seem similar—but they're actually very different. He examines Cloudinary and Blitline, and encourages developers to take a look at ImageResizer, an open-source package that does a lot of what proprietary services do (you just need to install the software on your own servers). 'If you're not a programmer but a web designer or blogger, Blitline won't be of much use for you,' he writes. 'If you are a developer, both Cloudinary and Blitline work well.' What do you think?"

cancel ×


Sorry! There are no comments related to the filter you selected.

I'm joining the Slashdot boycott (-1)

Anonymous Coward | about 7 months ago | (#46210791)

This site is ruined.

here is a workaround (-1, Offtopic)

joss (1346) | about 7 months ago | (#46210825)

Just encountered this fucking beta monstrosity. I agree with the boycott, but for people who actually want a usable slashdot under beta: []

Re:here is a workaround (-1)

Anonymous Coward | about 7 months ago | (#46210953)

Outstanding! Thanks! Want!

oh man (1)

gl4ss (559668) | about 7 months ago | (#46210809)

you mean there's free tools to resize images? reaaally?

they're also just files as any other so uh why use just image hosting solution? any reason? to get crappy re-encodes of your jpegs delivered? are they so much cheaper than just s3?

Re:oh man (0)

Anonymous Coward | about 7 months ago | (#46217175)

Don't be too harsh, this is an article by "Jeff the retard".

He seems to be someone Slashdot is paying for regular developer features, which would be great, if he ever actually had any clue what the fuck he is on about. Beta is Slashdot's quick death. Cogswell is it's slow death by dumbing down. Both sets of nonsense need to be binned to keep it alive.

I first became aware of this guys special level of retardedness when he tried comparing performance of Java vs. .NET using servlets (lightweight dumb HTTP responders) against ASP.NET MVC actions (request mapping, automatic binding required etc.) and then showed amazement that his .NET solution performed worse - no shit, it was doing much more work.

So each time I see his name in a summary, I know that it's Slashdot's amateur hour.

Once again, he has managed to meet expectations.

Ask Mister Pr0n (1)

some old guy (674482) | about 7 months ago | (#46210821)

It isn't as if adult websites haven't been using 3rd-party hosting of images and media for ages. You can't play a video without permission to

The only thing that seems to have changed is the buzz words. Cloud my ass.

Oh, and Beta still sucks.

I get the idea, but is it really necessary? (4, Informative)

corychristison (951993) | about 7 months ago | (#46210935)

As a veteraned web developer, I understand the idea... but is it really necessary?

The biggest issue I see is if the cloud service has a blip, or is simply slower than serving from your own servers.

In the past I've set up nginx strictly for serving static content (as it does it better than most) under a subdomain. This method is probably a good "in the middle" when it comes to serving the files. And, lets face it, storage is cheap. A couple of servers with a load balancer would be less prone to problems than running your own site on your own server(s) then subbing ouy the image hosting, storage and manipulation to some cloud services.

Unless you're dealing in resolutions higher than 20,000 px (X or Y) and they can manipulate the files and serve them faster I really don't see the need.

Re:I get the idea, but is it really necessary? (1)

mveloso (325617) | about 7 months ago | (#46211005)

I assume that the problem is that at some point you'll be serving out gigs of images a second, and storing terabytes of them. If you want to do that in a redundant, cost-effective way the cloud ones may be a solution.

Or, you could just get a few dedicated servers that are on a provider that provides unlimited bandwidth. It'd be cheaper, but it'll be a bit more work for your operations people, since you have to manage them in DNS and make sure they're mirrored/redundant. That shouldn't cost more than a couple of hour's worth of thought.

Re:I get the idea, but is it really necessary? (1)

Lennie (16154) | about 7 months ago | (#46213711)

Really ? What is wrong with doing your own resizing and then letting a CDN handle the rest ?

I think there are services out there for video recoding and resizing, those to me seems like the kind of service much more likely to be outsourced then doing it yourself.

Anyway, speed of development and outsourcing is big business.

Lots of developers outsource sending email for example.

It seems kind of crazy, but that's what the world is coming to.

The reason is, if you have very few people in your start up, you can focus on just building your application.

You can always stop outsourcing parts of what you outsource when you grow larger.

Re:I get the idea, but is it really necessary? (1)

gl4ss (559668) | about 6 months ago | (#46228985)

yeah but why would you pay a 3rd party service to buy space from amazon and run a resizer script when you can just buy the space from amazon?

if you're serving out gigs of images a second then it should be worth your time to buy the cloud time at the cheapest rate..

Re:I get the idea, but is it really necessary? (1)

Hohlraum (135212) | about 7 months ago | (#46211447)

Storage is cheap but backup services in a datacenter sure isn't. Not when you are gigs of data. Terebytes? Time to get out your checkbook brother.

Re:I get the idea, but is it really necessary? (1)

mveloso (325617) | about 7 months ago | (#46211855)

Re: I get the idea, but is it really necessary? (1)

corychristison (951993) | about 7 months ago | (#46225613)

Personally I build my own servers and colocate them into datacenters.

With that said, I have both enterprise grade servers (600GB SAS drives) and non-enterprise grade (2TB SATA drives). Storing things for serving up on the SATA drives is fine in most cases. The server automatically caches the popular files in RAM, reducing bottlenecks and slowdowns. RAM is also very cheap. 64GB minimum in my machines.

Proper servers, in proper datacenters, with load balancing, and a proper DNS setup and it starts to look like a Cloud solution. I'm still of the mind the "cloud" is just a buzzword.

The processing is more the issue (1)

SuperKendall (25149) | about 7 months ago | (#46212263)

Even just phone images now are 8-15 megapixels. That doesn't seem like much but over tens or hundreds or thousands of users, that is a huge processing load - and at the very least I can see many sites wanting to make thumbnail versions of images to reduce network traffic.

So to me looking at the problem in the light of not just storage but processing is a very useful take.

Re: The processing is more the issue (1)

corychristison (951993) | about 7 months ago | (#46225549)

I can see that, yes. But those same phones also support client side image scaling via the HTML5 Canvas tag. (See here: [] )

The fact is screen resolutions simply aren't there yet. There is no reason to upload and store the whole 15MP photo when you can only see 1/4 of it (if that).

With the canvas tag you can actually generate a thumbnail client side as well, and upload it alongside the main image, completely offloading the imag processing and reducing bandwidth (inbound and outbound upon re-serving up the file)

But you do NOT want to lean on that (1)

SuperKendall (25149) | about 7 months ago | (#46225623)

I can see that, yes. But those same phones also support client side image scaling via the HTML5 Canvas tag.

That is pretty much useless. From the server side you want as large an image as possible. You also want to distribute as small an image as possible at any given moment to reduce network use - that means scaling the input, sometimes in multiple ways.

Re: But you do NOT want to lean on that (1)

corychristison (951993) | about 7 months ago | (#46225769)

12MP is roughly 4000x3000px. High end mainstream screens cant even display half of that. A 100% quality JPEG you're looking around 2.5MB. That's pretty trivial, really. If you can halve your bandwidth and completely eliminate image processing by reducing down to, say, 8MP, would you not do it?

I wasn't saying to resize it down to 800x600 pixels, that would be crazy. 8MP ought to be enough for anyone ;-)

Re: But you do NOT want to lean on that (1)

SuperKendall (25149) | about 7 months ago | (#46225963)

If you can halve your bandwidth and completely eliminate image processing by reducing down to, say, 8MP, would you not do it?

Not if you might print it. But even if you did want to go down to 8MP, that still means the server needs much smaller thumbnails.

Re:I get the idea, but is it really necessary? (0)

Anonymous Coward | about 7 months ago | (#46219865)

Unless you're dealing in resolutions higher than 20,000 px (X or Y) and they can manipulate the files and serve them faster I really don't see the need.

Hipster coders always think they're gonna be the next snapchat. They'll pay 100x as much for transit as long as it can scale 10000x. It's not real money, anyway, because they're so smart they're going to have lots of VC's pouring money on them in a few months.

Just like the gold rush: get into the shovel business.

indeed a problem (0)

Anonymous Coward | about 7 months ago | (#46210991)

I help run a photography website with over 2 TB of photos. We've had our host/plan for over 5 years and here recently they are telling us we need to reduce the size of our site to under 100 GB. This doesn't make sense because we're on the biggest "unlimited" plan, and the smaller plans have a limit of 10GB and 100GB. Obviously I know it's not truly "unlimited" but you think it would at least be north of 100 GB.

Hanselman posted a good example of this a couple w (1)

Blyry (817193) | about 7 months ago | (#46211003) [] azure storage comes with a cdn AND you can process / transform uploads with very little boilerplate using WebJobs. See the link for a code example.

Re:Hanselman posted a good example of this a coupl (1)

SuperKendall (25149) | about 7 months ago | (#46212191)

Thanks for the link, I hadn't realized Azure had anything like WebJobs - that could be really useful.

Several Gigabytes the horror the horror (1)

mjwalshe (1680392) | about 7 months ago | (#46211019)

call me back when you get up to the several peta bytes stage

Standardization? (1)

Tablizer (95088) | about 7 months ago | (#46211065)

That sounds like a great idea, but integrating it with existing WCMS may be tricky. Uploading and user (author) image browsing should be seamless and sufficiently flexible for the different needs of individual shops. For example, some shops may allow or want sub-folders and some may not. Coordinating author permissions itself can be a sticky issue. A webmaster doesn't want to maintain two different "login" services for authors (local WCMS authentication versus image cloud service authentication). Some kind of standard "file service" protocol would be nice so WCMS add-ons wouldn't have a moving target or multiple targets.

Never host user images on your domain... (3, Insightful)

Wierdy1024 (902573) | about 7 months ago | (#46211521)

If you care about security, you would never host user provided images on your own domain.

Browsers ignore the file extension, and in many cases ignore the mime type when deciding how to process a URL. A malicious user could upload a dodgy swf file, but then rename it .jpg. Then the attacker gets the victim to load the malicious jpg from your domain. The swf can now read your domains cookies (same origin policy) and then return them to the attacker.

Thats why google uses ''. Most big sites do it. If you care about your users, you would do it too...

no brainer (0)

Anonymous Coward | about 7 months ago | (#46211849)

Google. Microsoft, and others provide free imagery so I guess I would go there. For paid you have the likes of digital globe and others that will do the heavy lifting. I surely wouldn't host my own large data sets, but, that is just me, especially if I am a start up unless a business case can be made that you imagery is cheaper and better or unique to your application for particular reasons, cause hosting is going to cost a lot, imagery as well, and the hardware and imagery will depreciate over time and your IT and data engineers and scientists may not be up to speed and then there is the cost of human capital. Let someone else have the headaches.

CDN Anyone? (0)

Anonymous Coward | about 7 months ago | (#46212131)

Doesn't this already exist? Its called a content delivery network. Akamai comes to mind.

Cloudinary (1)

Fallout2man (689436) | about 7 months ago | (#46218691)

My company uses Cloudinary to host user submitted images for some of our websites. It's easy to work with and provides options to process images in many different ways if you need to crop or apply other effects. We've found them to be very reliable and their support libraries really easy to work with. I'd definitely recommend them.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>