How We Built a Cloud Agnostic SaaS
Tim Child
February 23, 2021

Back when we started designing iconik we knew that we wanted to have a media management system that was massively scalable, beyond anything our experienced team had seen before.

Deciding What Our SaaS Needed

Deciding what our SaaS needed - image

We quickly realized that we would need to meet constantly changing demands on individual parts of the system and that we needed to be able to scale up and down capabilities at a granular level. We wanted to have thousands of customers, each with potentially millions of assets on the same instance— which could result in billions of files being managed. We also wanted to have the flexibility to run private instances for customers if they so demanded.

With these needs in mind, we knew our service had to be architected and built to run in the cloud, and that we would run the business as a SaaS solution.

Mapping Our Architecture

Mapping our architecture - image

Upon looking at this challenge we settled on using a microservices architecture, with each functional unit broken up and then run in Docker Containers. This current map of iconik’s architecture is nearly identical to what we planned from the start.

image of the iconik architecture

To manage these units while also providing for the scaling we sought, the architecture required an orchestration layer. We decided upon Kubernetes, as it was:

  • A proven technology with a large influential community supporting it.
  • A well-maintained open-source orchestration platform.
  • A system that functionally supported what we needed to do while also providing the ability to automatically scale, distribute, and handle faults for all of our containers.

During this development process, we also invested time in working with leading cloud IaaS and PaaS providers, in particular both Amazon AWS and Google Cloud, to discover the right solutions for production systems, AI, transcode, CDN, Cloud Functions, and compute.

Choosing a Multi-Cloud Approach

Planning our multi-cloud approach - image

Based upon the learnings from working with a variety of cloud providers, we decided that our strategy would be to avoid being locked into any one cloud vendor, and instead pursue a multi-cloud approach—taking the best from each and using it to our customers’ advantage.

As we got closer to launching iconik.io in 2017, we started looking at where to run our production systems, and Google Cloud was clearly the winner in terms of their support for Kubernetes and their history with the project.

Looking at the larger picture Google Cloud had:

  • A world-class network, with a presence of 93+ points in 64 global regions.
  • BigQuery, with its on-demand pricing, advanced scalability features, and ease of usability.
  • Machine learning and AI tools. We had been involved in beta testing these tools before they were built in. These tools would be an important element in our offering to give deep insights into media.
  • APIs that were best in class.

These important factors became the deciding points on launching with Google Cloud. But, moving forward, we knew that our architecture would not be difficult to shift to another service if necessary as there was very little lock-in for these services. In fact, the flexibility provided allows us to run dedicated deployments for customers on their cloud platform of choice and even within their own virtual private cloud.

Offering Freedom of Choice for Storage

freedom for storage - image

With our multi-cloud approach in mind, we wanted to bring the same flexibility we developed in production systems to our storage offering. Google Cloud Services was a natural choice because it was native to our production systems platform. From there, we grew options in line with the best fit for our customers, either based on their demands or based on what the vendor could offer.

From the start, we supported Amazon S3 and quickly brought Backblaze B2 Cloud Storage on board. We also allowed our customers to use their own Buckets to be truly in charge of their files. We continued to be led by the search for maximum scalability and flexibility to change on the fly.

Many iconik customers choose to have a multiple vendor approach when it comes to cloud storage. This chart from our 2021 Media Stats shows which storage providers users have chosen to store their original hi-res assets.

where iconik customers store their hi-res assets

As we have grown, our multi-cloud approach has allowed us to onboard more services from Amazon—including AI, transcode, CDN, Cloud Functions, and compute for our own infrastructure. In the future, we intend to do the same with Azure and with IBM. We encourage the same for our customers as we allow them to mix and match AWS, Backblaze, GCS, IBM, and Microsoft Azure to match their strategy and needs.

Reaping the Benefits of a Multi-Cloud Solution

benefits of multi-cloud - image

To date, our cloud-agnostic approach to building iconik has paid off.

  • This year, when iconik's asset count increased by 477% to over 55 million assets, there was no impact on performance.
  • As new technology is available, we have been able to improve a single section of our architecture without impacting other parts.
  • By not limiting cloud services that can be used in iconik, we have been able to establish many rewarding partnerships and accommodate customers who want to keep the cloud services they already use.

Hopefully, our story can help shed some light to help any others who are venturing out to build SaaS of their own. We wish you luck!

Author bio: Tim Child is the co-founder at iconik Media where he also leads UI development. He has 13 years of experience in the media management space which he has used to help create iconik and meet the changing needs of companies of every size and industry as they work with more video.

This post was originally posted on the Backblaze blog. Head over there for drive stats and insights on cloud storage and services.