“Content Ignite successfully migrated to DigitalOcean in 2017.”

Ef73b7bc8ed9916a07843c11e60d55f93c608134 content ignite
Industry
Native Advertising
Year Founded
2015
HQ
Bournemouth, UK
Try DigitalOcean

How Content Ignite successfully migrated to DigitalOcean in 2017

Who We Are

We are Content Ignite, a native advertising platform based in Bournemouth, United Kingdom. Native advertising is the practice of publishing adverts that are designed to follow the style of the platform on which they are published, and our goal is to connect buyers and sellers of native advertising in a single marketplace where they can bid on advertising opportunities. This helps to foster competition between many different advertisers in the marketplace, maximizing revenue for publishers.

Content Ignite was founded in 2015, and we have since developed a suite of products that facilitate relationships between advertisers and content makers. Our company's accelerated growth compelled us to take steps toward enhancing the scalability and stability of our platform, which led us to make the switch from our previous managed hosting provider to DigitalOcean in 2017. Since then, our hosting costs have decreased by over 90%, we've been managing an average of 500 requests per second, and we estimate that we're running at about 25% of our capacity, which is good news as this will allow our platform to scale up very quickly.

Before Moving to DigitalOcean

Prior to switching to DigitalOcean, we relied on a managed hosting provider to oversee our web infrastructure. Our initial infrastructure architecture looked like this:

This setup featured a load balancer at the top which distributed traffic between seven nodes, which would then send and receive data to one of our MySQL databases. Our development team used GitHub to store code, DeployHQ to automate deployments, and a cloud backup service to keep all of Content Ignite's data secure.

This setup was not optimal, however, as our original hosting service was unable to provide us with a CDN, an object store, or adequate monitoring data, all of which we needed to measure performance and provide a high level of availability for our content and services. The lack of a CDN meant that this infrastructure setup was prone to high latency times, often around 200ms. Relying on managed hosting also stymied our workflow, as our development team regularly found themselves issuing support tickets and then having to wait for the hosting provider to resolve issues, resulting in costly stretches of downtime.

As Content Ignite grew, so did our need for highly-scalable infrastructure, our CTO Ben Spencer and Technical Lead Jamie Druce began researching options for where we could migrate our servers. Because we did not have the support of a dedicated DevOps team to rely on, it was important that whichever hosting provider we chose could make the migration manageable for our in-house development team.

With some inter-department experience working with DigitalOcean to host some personal projects, our team appreciated its user-friendly interface and feature rich offerings. With the launch of Spaces object storage last fall, we saw that DigitalOcean could handle Content Ignite's hosting needs and began building a strategy for us to migrate over to DigitalOcean.

Migrating to DigitalOcean

The biggest concern that our team had about switching to DigitalOcean was the need to move our databases, as it was difficult to estimate how much downtime we would face before actually starting the migration. Any amount of downtime would get in the way of our ability to track ad impressions, one of Content Ignite's key services, so minimizing it was essential.

After reading through some of DigitalOcean's Community tutorials and speaking with the Customer Support team, our development team, led by Jamie switched our MySQL databases into primary and secondary replication and copied the original primary over to the secondary on DigitalOcean using rsync. We were then able to pull the primary down and put the secondary into primary mode to complete the migration and, thanks to the team's due diligence for best practices, we experienced only a small amount of total downtime.

After completing the database migration, our developers revamped Content Ignite's web infrastructure to look like this:

Function Memory Dedicated CPUs SSD Transfer
DB Droplets Standard 8 GB 4 vCPUs 160 GB 5 TB
GitLab Runner Droplet Standard 2 GB 1 vCPU 50 GB 2 TB
Web Droplets Standard 16 GB 6 vCPUs 320 GB 6 TB
MicroApp Droplet Flexible 2 GB 2 vCPUs 60 GB 3 TB

Our current setup is a fairly typical highly-available stack. At the top is a load balancer that distributes traffic between web nodes which then send and receive data to one of three MySQL databases (each of which are hosted on their own Droplet). The load balancer distributes traffic between floating IP addresses which point to each of the web nodes, making it easier to switch out which Droplet is providing services at that IP address. This ensures a far greater level of redundancy, because if one of the nodes fails for any reason the others will be able to take on its workload easily.

Our engineers added a CDN77's content delivery network stack in front of the object store which has custom domains pointing directly to the relevant Space. Within this setup, a CDN-served script on the client's site initiates a call to the primary nodes, which in turn processes the request and fetches ad content to deliver. The process of choosing an ad utilizes a bespoke bidder layer that is able to make a number of asynchronous calls to ad partners for content. Doing it this way means each ad partner gets a fair shot at every bid, while maximising income for our clients. Thrown into the mix is our clients' own campaigns, which perform impressively well thanks to assets stored in Spaces.

This architecture gives us the freedom to purge files on the fly in order to keep our sites up to date. Content Ignite now uses nearly all of DigitalOcean's product offerings, but the object storage provided by DigitalOcean Spaces and the ease of use of the DigitalOcean API are two qualities that our team has come to value in particular.

The stack allows for one-click updates to live files, and we have observed significantly faster load times and impressive inter-communication speeds between Droplets on our private network. We inspect and keep track of our network speeds through Chrome DevTools. Thanks to the CDN, we can now load an entire ad in as little 500ms (a speed increase of 80%), and serve cached files in as little as 20ms. We've also moved some logo image files and all our CSS assets into the CDN, which produced a further 30% speed increase with latency dropping from 200ms down to 20ms.

Despite not having a dedicated DevOps team, our engineers developed an auto-devops workflow since the move. This has allowed them to manage the Content Ignite infrastructure without spending any more time on DevOps than they did when we relied on a managed hosting service. They use DigitalOcean's Droplet tagging feature to perform a number of tasks automatically which would otherwise be repetitive and time-consuming, like creating new Droplets, adding them to clusters, and connecting them to our DigitalOcean Cloud Firewalls. Tagging also makes it easy for our developers to group hosts and quickly make changes to them.

Our team had previous experience in using Ansible to deploy code, and found it to be an intuitive tool to deploy infrastructure as well. The development team now uses Ansible in conjunction with the DigitalOcean API to automate many of their infrastructure deployments and GitLab for continuous integration. Our auto-devops workflow has proven to be extremely scalable for the development team, and new staff have been quick to pick it up during their onboarding.

Takeaways

Before moving over to DigitalOcean, we felt hampered by our infrastructure. In spite of the benefits offered by our previous managed hosting service, the fact that we couldn't add a CDN or an object store to our setup made it difficult to scale things up, and without direct control over our infrastructure there was little we could do to ensure our platform's stability. Since moving to DigitalOcean, though, our setup is ultimately more capable than what we had before the migration and our hosting costs have decreased by more than 90%. We've experienced much more reliable service with DigitalOcean, and downtime has become a rarity.

Although a self-managed hosting infrastructure places all the system administration responsibilities squarely on engineering teams, it provides far greater flexibility to scale up infrastructure in line with organizational growth. As daunting as migrating our infrastructure seemed at first, we found the task to be much more straightforward than we'd anticipated, thanks to DigitalOcean's support and documentation. All in all, our team is very happy with our decision to migrate over to DigitalOcean, and we're eager to continue to scale up our infrastructure as our hosting needs grow.

Have questions before you deploy?

Contact our Customer Success team to get answers.