Scribd developed a cost model for their infrastructure migration to AWS

We only get one shot at this migration

We’ve been running our app in a managed datacenter and now need to move to AWS. We’re only going to do this migration once and we want to get it right the first time without burning through cash as we do it. When you’re talking about millions of dollars a year in investment in AWS, making mistakes is expensive. Plus, we only have the capacity to pull away engineers from product development for this migration for a very limited time, so that means we have to know what the hell we’re doing pretty clearly ahead of time.

Internally, Scribd didn’t have the skills or exposure to AWS architecture to do this on our own, so we engaged Duckbill to help us plan our migration. They have the expertise in advanced AWS architecture and the understanding of what it should look like for big companies like ours to help us avoid making expensive mistakes.

Duckbill started with an assessment of what we have in the datacenter. They spent a ton of time with us on-site and remotely to understand our application and all the unique constraints we have with it, ultimately assessing its cloud readiness and pointing out where we needed to focus improvement efforts. Based on their assessment of the data, Duckbill developed a cost model for us (on a per-team basis and even down to the machine) so we could see what the cost was going to look like in AWS when we migrate and as we grow over the next few years. 

When your labor costs are 5x your infrastructure spend

We’re now ready to proceed with the migration and feel confident that we’ve gotten it right. Without Duckbill’s involvement, we would not have been able to get to this point, certainly not this year. That has a huge monetary impact on us.

As part of the cost modelling, Duckbill came up with a meaningful unit economic KPI for us to use: cost per thousand document views. It’s helped bridge the gap between how Finance perceives what we’re doing and how Engineering and Product perceives it. Finance can tie that metric to their annualized budget, while I can come from the other direction to identify how infrastructure changes we plan to make will impact that number. It just gives us a meeting place in the middle as we talk about costs.

If, for example, you present an engineer or engineering lead with a choice of the myriad ways in which containers can be deployed in AWS, they may not have a full appreciation of why you would choose one of the other, not just in the raw cost impacts of each but also the labor impacts of scaling and managing each one. With Duckbill, it’s like we’re timesharing an AWS Architect. They’ve got that experience to tell us the cost impacts—including the undocumented costs—and why we should choose one over the other.

We’re keeping Duckbill on retainer for our migration and it’s going to continue to pay dividends. As we move forward with the migration and have to make architectural changes for some of our applications, we have someone more experienced that we trust to go to with questions when we’re not sure if we’re missing something. Having them confirm “yes, that’s how you have to do it” or “no, you don’t want to use that service because of these hidden costs”, it gives us tremendously valuable confidence and moral support.