Slashdot Mirror
Comparing Cloud-Based Image Services For Developers
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?"
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?
world was created 5 seconds before this post as it is.
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 foocdn.com.
The only thing that seems to have changed is the buzz words. Cloud my ass.
Oh, and Beta still sucks.
Scruting the inscrutable for over 50 years.
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.
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.
http://www.hanselman.com/blog/... 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.
call me back when you get up to the several peta bytes stage
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.
Table-ized A.I.
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 'Googleusercontent.com'. Most big sites do it. If you care about your users, you would do it too...
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.
Doesn't this already exist? Its called a content delivery network. Akamai comes to mind.
Thanks for the link, I hadn't realized Azure had anything like WebJobs - that could be really useful.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley