Congratulations to EPIX on the successful launch of their cable channels and EpixHD.com site! We’re thrilled to be a partner and look forward to helping deliver tons of HD quality movies to your audiences.
By the way, nice to meet you!
Now that we’ve been in business for almost a year, a proper introduction is overdue.
Goldberg Technology assists clients with their technology vision, strategy and implementation. As your silent partner behind the curtain, we take care of all your technology issues so you can focus on the important mission: running your business.
With over 20 years of combined experience in the technology sector, we offer a drop-in CTO service. Whether you are a sole proprietor or a global powerhouse, GT offers scalable solutions tailored to your company’s specific needs and goals.
And we do more than just strategize. From soup to nuts, we will architect, implement, and monitor your entire system. Here are some of the services we offer.
Check back here frequently as Paul and I blog about technology and technology management issues that are near and dear to our hearts.
CDN billing: Mbps or GB transferred?
In a couple of weeks, I’ll be speaking on a panel at Streaming Media East about CDN best practices from the customer perspective. Since the CDN can be a significant cost, managing that relationship is important to the bottom line. You’re hopefully not surprised that management means measurement, which makes this article all about measurement. Let’s examine implementing a CDN for the Super Productive Uber Destination (SPUD) webserver.
First, here are the 2 prevailing CDN billing methods defined:
Total GB transferred in a month - every singly byte served is metered and billed for.
95th Percentile Mbps - megabit-per-second (Mbps) bandwidth usage throughout the entire billing month is measured in 5 minute chunks and then rank ordered. The top 5% values are discarded and the largest remaining value (the 95th percentile) is used for billing.
Ok, now that’s out of the way, which one should SPUD opt for? Let’s say House-of-Bits (HoB) CDN is offering your choice of the following rates:
$0.20 per gigabyte transfered
or
$30 per Mbps at the 95th percentile for the month
These are not equivelent.
Putting aside whether or not HoB’s rates are competitive, understanding the behavior of the SPUD website is critical to making an informed decision.
For reasons that are beyond the scope of this article, many organizations don’t have Mbps measurements at hand, and they can be difficult to reconstruct after the fact. Total bytes served, on the other hand, are as easy as having your friendly neighborhood sysadmin add up the bytes logged in the webserver log files.
It turns out that SPUD’s webservers pumped about about 20,000 GB last month, and had been growing about 2,000 GB every month leading up to last month. Armed with this information, we can make some fairly sane estimates around how much traffic will be transferred in the coming months:
Month 1: 22,000 GB x $0.20/GB, monthly cost $4,400
Month 2: 24,000 GB x $0.20/GB, monthly cost $4,800
Month 3: 26,000 GB x $0.20/GB, monthly cost $5,200
Total for the next 3 months: $14,400.
Great, now that we’ve wrapped a box around the GB pricing at HoB’s CDN, let’s try to do the same for their Mbps pricing. Since the SPUDs servers don’t have the Mbps data we’re looking for, let’s use some rules-of-thumb that I’ve observed for a while plus some basic math:
- Most web apps follow a daily usage pattern that approximates a sine wave, with lots of use when people in the US are awake and far less when they’re sleeping.
- The ratio between the Peak Mbps and the Average Mbps are typically in the range of 1.3 to 2.2. We’re going to use 1.7 for our estimates with SPUD’s webservers, and tweak it when we get some real measurements.
- We can come up with the average Mbps transfer rate for the entire month by converting gigBytes to megabits: just multiply GB x 1024 to convert to megaBytes and then multiply THAT by 8 to get the total number of megabits transferred. To convert that to the average bits per second, just divide by 86,400 (the number of seconds in a day) and divide again by 30 (the number of days in a month).
- It turns out that all the math above simplifies to a conversion factor of about 316.4 which means that you can just divide GB transferred by 316.4 to come up with your average Mbps for the 30 day month.
Armed with this knowledge and a calculator, let’s see what our traffic expressed in Mbps looks like:
Month 1: 22,000 GB / 316.4 = Avg of 69.5 Mbps, Peak of 118.2 Mbps.
Month 2: 24,000 GB / 316.4 = Avg of 75.9 Mbps, Peak of 129.0 Mbps.
Month 3: 26,000 GB / 316.4 = Avg of 82.2 Mbps, Peak of 139.7 Mbps.
Now before we congratulate ourselves too much for backing out these figures, let’s remember that this is based on some educated observations that may or may not be relevant to SPUDs. Mathematical models are fine, but we’ll be billed on actual behavior and measurements. With that in mind, here are the costs for the above estimated peak Mbps rates:
Month 1: 118.2 Mbps x $30 per Mbps, monthly cost $3,546.
Month 2: 129.0 Mbps x $30 per Mbps, monthly cost $3,870.
Month 3: 139.7 Mbps x $30 per Mbps, monthly cost $4,191.
Total for the next 3 months: $11,607.
That’s almost 20% off of the total GB-transferred pricing… definitely worth validating the model, and probably worth picking the Mbps pricing in this case. In fact, we could co through the entire model again using a more aggressive Peak to Average ratio to see exactly where the crossover point is, but I’ll leave that as an exercise for the reader + Excel.
Issues not explored here include flash traffic events, measuring regularity and periodicity of website traffic, and the effects these and other factors can have on the month-end bill.
Bottom line, yet again: measure to manage!
Thoughts on email and status meetings
For the record: I have nothing against meetings. There is something about face-to-face communication that can’t be replicated in any medium. The two-way real-time exchange of ideas and perspectives can be invigorating.
Something that is NOT communication is a group of people sitting in a room with people taking turns providing status of the individual areas for which they’re responsible. The serialized monologue has a name and it is a broadcasting. While sometimes appropriate in person, it’s almost never appropriate as a weekly event. Email can be great for status, more on that in a bit.
Also, meetings have a cost; several people in a room, ostensibly unplugged from the world so that they can pay attention, means that there’s a definite opportunity cost and lots of other things are not being accomplished while we’re all together. So any face to face communication needs to have a well understood purpose if it’s to be an efficient and effective use of everyone’s time.
Back to email: it’s a wonderful broadcast medium. Anyone can drop one to the right audience, hopefully after collecting their thoughts into a coherent message. It also is helpful that I can get caught up on status from those who share on my own schedule.
Email is not well suited to discussions, however. Picking up the phone or walking over to a colleague for a brief hallway discussion avoids misinterpretation and provides immediate results. “But what about a record of what was said? Email is the tool I use to hold people accountable!” That’s fine; followup your discussions with a short summary to your colleague and copy whomever else is appropriate (note that defining appropriate is an exercise left to the reader). That’s a good idea to do anyway, as it gives you both an opportunity to sanity check what you met about.
So to sum up: Email: great for status broadcast, not great for discussion.
Meetings: great for discussions, not great for status broadcast.
Data -> Information -> Direction
Want a way to reclaim hours of your time spent in followup meetings and emails explaining the latest data that you sent around? It’s super easy:
Don’t send data to anyone. Ever.
Instead, send around your latest conclusions based on the data you have. Apply some of that good judgement that got you hired in the first place and turn the data into information. By anticipating the questions from those who aren’t immersed in your application or business or context, you can proactively answer them up front, and probably avoid several unproductive tangents in doing so.
Oh, and ever have a boss or colleague incorrectly infer something from some data they had available? It can result in hours or days of chasing a phantom problem or fixing something that’s not broken.
Thoughtful analysis turns data into information. Powerful stuff! Now don’t hate me; part of the information in your report is the data.
“Dang it, Marc. You’re contradicting yourself!”
Yes, but here’s the thing: by using judgement and analysis to provide context you’ve changed the data into information. Also, others will want to be able to follow your train of thought, verify your conclusions, and maybe even catch a mistake from time to time.
Now that you’re comfortable applying your expert analysis to the data to transform it into information, you can do the same thing to the information and turn it into direction. Here’s an example of what I mean:
- The Data
- Our webserver transaction measurement is at 80 per second.
- Analysis makes it Information
- Hrm, 6 months ago we were doing 20 per second and we thought we’d be at 35 per second around now, so we’ve seen more growth than we thought. Also, we have enough hardware to support 95 per second.
- More analysis makes it Direction
- After checking with the Bis Dev guy, I found out that we’ve just signed a deal to send most of our traffic to our new partner. So even though we’re approaching the capacity limits of our hardware, we should NOT purchase any more right now.
Turning data into information and then direction is a process that is vital to every successful organization.
Management prerequisite: Measurement
“How can we make the website faster?”
“How can we get stronger volume through the process?”
“Is this bigger than last quarter?”
None of the above questions can be answered without knowing something critical: what’s the current measurement value? After all, to make something bigger, stronger, or faster the current ability for each has to be understood.
Just like a scale without a display, a webserver (or any application) without measurements is just a box that HOPEFULLY won’t break when stood upon. Feeding code to the webserver may make it leaner… or maybe it’s fatter now, who knows?
Now check this out: management of the webserver isn’t the only reason to measure it. Sure, it’s good to know how many transactions per femtosecond the server can gobble up (operational metrics help manage, uh, operations), but there are actual BUSINESS applications to some of those as well. How many visitors to the website came back in the past week? How did their visit patterns change after that cool new feature was turned on? Oh, and what are those visit patterns anyway?
Thoughtful measurement can provide all kinds of great data. Next, it needs to become information.
