Cloudinary Blog

Why we moved from an in-house image management system to Cloudinary

By Adam Cox
Build VS. Buy
At Build.com, where I’m a software architect, we manage hundreds of millions of images. Our site offers more than 1 million home improvement products, such as tubs, toilets, cabinets, fireplaces – really any thing homeowners need for their improvement projects. And for each item, there are multiple images – product and gallery images, action shots, close-ups and thumbnails – that our visitors view from a variety of devices, including mobile phones, tablets, their desktop computers and our native app. In addition, these images are used in many view templates – on the landing page, via search, by category and in the cart.
 
Since our inception, we were using a homegrown system to manage and manipulate our images. We relied on Apache rules and proxies to a Java resizer app. But we ran into several problems with the system as our site grew, including:
  • Speed – It was slow and we were unable to do image transformations on-the-fly.
  • Limited features – We could only resize the height and width, proportionately, and crop for thumbnails.
  • Data consistency – We would upload new images to the site, but they wouldn’t be visible to customers.
  • Storage – With capacity problems and back-up issues, our IT operations staff was always having to help us deal with the images in our system.
  • Scaling – Uploading thousands of images caused a cascading set of issues, resulting in the system crashing and maxing out CPOs.
  • Image management – All images were managed through FTP, without any user interface (UI).
As our company evolved and expanded, we knew we had to find a better way to manage and deliver the best possible images to our buyers. We were spending too much time and too many resources maintaining the legacy system. That led us to a crossroads: Do we build a new system in-house, or should we look for a solution from a third-party vendor?
 
To aid in the decision-making process, we created a matrix that enabled us to evaluate the pros vs. cons of in-house vs. third-party, and identify the requirements any new system must meet:
  • Performance – Time to transform and the ability to create multiple variants, on-the-fly, from the original.
  • Optimization – Ability to reduce image weight by stripping metadata, set JPEG levels and use progressive JPEGs, leverage WebP for Chrome and other actions that speed page-load time.
  • Rich Feature Set – Multiple transformation options, including cropping capabilities, face detection, applying watermarks and delivering higher resolution images for retina display.
  • Accuracy – Proper cache purges to resolve data consistency issues and deliver new images to customers immediately.
  • Ease of Use – Should be easy to implement, integrate and migrate the large existing media library from the legacy system in order to minimize impact on operations.
As we narrowed down our decision to build or buy, we also debated key points, including cost, both in terms of dollars and man hours. These costs included: 
  • Common costs that would be incurred with either option (managing files, integration/migration to a new system, storage, back-up costs and training for the new system).
  • Opportunity costs (particularly in terms of the roadmap and functionality that may be required in the future).
  • Man hours required (for either building and maintaining the system or integrating and managing a third-party solution). 
Other considerations included:
  • Number of files we would need to manage
  • Total storage
  • Bandwidth usage 
  • Growth expectations
  • Potential scalability and reliability of each model to support a global audience or unexpected traffic spikes.
Ultimately, we realized that buying was our best option. We have a talented group of developers, but felt their time would be better spent working on new features for Build.com, rather than the tasks that an outsourced image management service should easily be able to handle.
 
We looked for a vendor that had experience serving companies that were larger than Build.com, which showed that it was capable of scaling, was considered reliable and offered high availability. If these companies were using a vendor and satisfied with its performance, we knew it would be a good fit for us. In addition, we wanted to ensure that the vendor’s performance was faster than our legacy system. Before making our decision, we ran side-by-side WebPageTest comparisons, which enabled us to test whether the vendor’s system offered significant speed increases and performance improvements. 
 
After considering a number of third-party vendors, we selected Cloudinary because it met – or exceeded – all our requirements. Since our move to Cloudinary in May 2016, we’ve seen a number of benefits:
  • Easy implementation – Available code libraries, upload widgets and ability to fetch images from remote locations made our start-up and transition a snap.
  • Greater productivity – Because we didn’t have to maintain and troubleshoot problems, like in our legacy system, our development team became more productive, saving use an average of 10 to 20 hours a month to re-focus on other important aspects.
  • Instant access to new features – As Cloudinary introduced new features, such as art-directed cropping and optimal format selection based on the browser, we could immediately take advantage of them.
  • Better utilization – There was less CPU usage on our servers, better CDN purging when files changed and improvements in back ups.
  • Improved performance – All web pages loaded on Chrome now use WebP for optimal performance, and we generally lowered the page size and reduced loading time.
The decision to build vs. buy a new image management system was not one we took lightly, since the success of our site – and our business – relies so heavily on images. Every company needs to take careful stock of its current challenges, what it wishes to accomplish, expectations for the future, and the risks and rewards of each option, before taking that next step.
 
Here I’ve shared our decision-making process, and the overall benefits from moving to Cloudinary. In my next blog, I’ll go into more detail about how we’re using Cloudinary and the results we have achieved.
 

Recent Blog Posts

Maya Shavin: How I Built My Website

Besides working as a senior front-end developer at Cloudinary, I'm also a content creator, a blogger, and an open-source developer. Follow me at @mayashavin and on mayashavin.com.

In the beginning, my website, mayashavin.com, was mainly for showcasing the status of my development projects and keeping me organized with my speaking schedule. Initially, I built it with Vue.js, later on switching to Nuxt.js (aka Nuxt) for a higher SEO score, and deployed it with Netlify. After some time, I added a blog section with Netlify CMS as the content management system (CMS). Everything was fine until I added more content and features, which led to a significant decline in the site’s performance. Also, the site design needed a modern look. So, I gave the site a makeover.

Read more
Automation Frees Up PetRescue’s Staff to Help Pets Find Their Forever Homes

As we spend more time at home, many of us are adopting pets for the joy, companionship and a surprising range of health benefits. In Australia, where our nonprofit customer PetRescue is located, there’s a shortage of pets to adopt. Last August, the Guardian reported that dog shelters in Australia emptied and adoption fees for puppies were running as high as $AUS1800.

Read more
Cloudinary and Contentful Make Modern Content Management Easier

I am pleased to share that Cloudinary and Contentful have joined forces to further streamline the creation, processing, and delivery of online content through Cloudinary’s digital asset management (DAM) solution and advanced transformation and delivery capabilities for images and video. What’s more, the partnership delivers a headless approach to DAM. By leveraging APIs for media management tasks, marketers and developers alike benefit from an integrated stack of optimized assets for optimization and automation. As a result, page loads are fast and beautiful, and at scale—with less overhead and effort.

Read more
Introducing Cloudinary's Nuxt Module

Since its initial release in October 2016 by the Chopin brothers as a server-side framework that runs on top of Vue.js, Nuxt (aka Nuxt.js) has gained prominence in both intuitiveness and performance. The framework offers numerous built-in features based on a modular architecture, bringing ease and simplicity to web development. Not surprisingly, Nuxt.js has seen remarkable growth in adoption by the developer community along with accolades galore. At this writing, Nuxt has earned over 30K stars on GitHub and 96 active modules with over a million downloads per month. And the upward trend is ongoing.

Read more
How Quality and Quantity can go Hand in Hand

When it comes to quality versus quantity, you’ll often hear people say, “It’s the quality that counts, not the quantity”. While that’s true in many situations, there are also cases where you want both quality and quantity. You may have thousands of images on your website and you want them all to look great. This is especially important if your website allows users to upload their own content, for example, to sell their own products or services. You don't want their poor quality images to reflect badly on your brand.

Read more