Why You Should Care About the Infrastructure Behind Your Podcast
…and all the right questions to ask about it.
Why should you care about the infrastructure behind your podcast?
There are a lot of things to think about when choosing a podcast host, but one that probably doesn’t get talked about enough is reliability–can you trust your podcast hosting provider to deliver your audio content, to anyone, anywhere, anytime. One of the main ways you can see the reliability of your host is by looking at their infrastructure. If you don’t know what infrastructure is (and at this point are too afraid to ask), fear not–we’ll lay it all out for you.
What do we actually mean when we say “infrastructure”? How does it relate to your podcast?
When we talk about infrastructure, we’re talking about the underlying tech that delivers everything you as a customer see — your Dashboard, your analytics, your saved shows, etc. — and what your listeners and prospective listeners see and hear — your website, your players, your show notes, and, of course, your show available for download or streaming on all of the different listening platforms (Apple Podcasts, Google Podcasts, Spotify, iHeartRadio, etc.). At its most basic level, our “infrastructure” is servers sitting somewhere in the world holding information and then, when requested, delivering the proper content to the proper device at the proper time. But when we’re discussing it, we’re really talking about all the different pieces, services, methodologies and implementations of that infrastructure that make Simplecast work.
Think of it like this: You, the Simplecast Show Owner, making your show available to your listeners is just like you buying a gift online to send to your mom. (Your mom listens to your podcast, right?) The host/infrastructure is all of the hundred little things that happen in the background to make sure that when you pick the perfect present for mom online and place the order, the exact gift you picked actually arrives at mom’s house on time with a lovely note from you. The reality is that when things are working perfectly, you don’t even notice all of those little things happening in the background. You use a website to find and purchase that perfect gift. Besides picking how quickly the present gets to mom, you really don’t care about all the little steps–you just want it delivered on time and in perfect condition.
Likewise, the Simplecast Show Owner creates their podcast on the website to be delivered to their listeners. Besides a few settings for how they want it delivered (Apple Podcasts, Stitcher, etc.) they really don’t care about how it gets delivered–but you do expect it to be delivered when you specified and in perfect condition.
The infrastructure is, in part, the delivery method. When a package gets shipped somewhere, it passes through a bunch of different hands and travels via many different methods, but it eventually gets to the end user. Some methods of delivery are faster or more reliable–think about the difference between USPS and UPS. Just saying those two names conjures up certain thoughts about speed and reliability!
What’s the doomsday scenario for unreliable hosts? What happens when things go wrong?
An infrastructure doomsday scenario would be if a piece of the content delivery infrastructure breaks. There could be many reasons for this–a bug in the code, too much traffic to a server with small resources, or major server providers like AWS having interruptions in their service. The goal of really good infrastructure is to eliminate as many potential breaking points as possible, while also using the most reliable and scalable infrastructure.
Remember that present you were buying for your mom earlier? This would be like if that present gets lost in the mail and never shows up. Or natural disaster happens and none of the mail can go through it’s usual route. Or your delivery airplane breaks down!
If we think about how an audio file gets delivered to an end user, every host’s audio is sitting on some kind of storage service (like servers in a room), but there are many, many differences between where the file originates from and its final destination. This is the same for all things internet related–while all implementations get the job done, not every implementation is optimized for speed and reliability.
What questions should you ask when evaluating your podcast host’s infrastructure?
It’s difficult to know exactly what hosts are doing with their infrastructure. This is not always talked about or fully obvious. The biggest “gotcha” is that it’s easy to put up a website that looks great, while having an underlying infrastructure that is frail. At some point, the smaller hosts will have to figure out scalability–how to balance cost and keep their servers running, while also delivering content for thousands of customers and thousands of shows, getting tens of millions of listens every month.
At Simplecast, we went through this phase a few years ago and it’s not an easy thing to do. It forces the issue of whether a host built their system on the right infrastructure–and most of the time they have not. Our goal has always been to keep Simplecast scalable, cost effective and reliable, and every decision we’ve made moving forward, from an infrastructure standpoint, has to be able to fit those goals.
When you’re looking at a host, there are a few questions you can ask about their infrastructure:
- If your host were to take on a large show, could their infrastructure handle it or would it become unreliable or slow? We already host multiple large shows and our system can handle any number of high-traffic clients without having any effect on speed or the ability to serve up content.
- Who or what shows are on a particular host? If you know that multiple high-trafficked shows are on a specific host, then you can be assured that the host has solved the scalability and delivery problem. We host high-trafficked shows like US Weekly, Athletes Unfiltered by Strava, Mission to Zyxx and many, many more.
- What has been the historical track-record for a hosts uptime? Does the host make this transparent? Simplecast does! You can always check what’s going on at: https://status.simplecast.com. Moreover, we’re constantly improving our uptime.
- What underlying infrastructure are they using (CDN providers, server providers, codebase, etc.)?
- What does their infrastructure team look like? Some hosts are bootstrapping their company with very small teams and, consequently, wearing all the hats. We have 2 dedicated infrastructure folks with combined experience running other large sites like Bankrate and Namecheap. Between the two of them, have a combined experience of over 22 years.
What does Simplecast do that’s different?
When we stepped back and took a look at how we wanted to build out the new Simplecast, we went into it seeing how we could make the critical parts of our service the most redundant and bomb-proof. Would RSS and audio always deliver to the user no matter what? Will our audio players always load? Will show websites always load? Basically, can every listener-facing service stay up all the time? There’s never truly 100% uptime, but this is what we strive for.
We identified that if we could serve all of our RSS, Audio, Players, and Sites off of our CDN, then we would eliminate nearly every pain point in a delivery infrastructure, while also creating optimal speed. With CDN redundancy, our API could go down, our databases could explode, or our servers might implode, but everything would keep being served to our end users. AKA, your show could still be listened to! In terms of removing all the failure points, we have eliminated as many as we possibly can while boosting redundancy on the things we can’t.
In terms of our API, which interfaces with the Database and a lot of other volatile pieces, we are using Elixir/Erlang for optimal uptime and distributed computing with Kubernetes powering the server pods. This lets us infinitely scale our API globally and gives us the reliability we need to keep everything running properly.
Have more questions about infrastructure? Reach out on Twitter to @teevio!
