In my last post, I talked about moving pianos in a Yaris through 2 feet of snow, and the results you might expect from such an endeavor. I did my best to relate that effort to managed file transfer (MFT), and hope I didn’t lose you in the analogy. If you’ve gotten this far, I have another one to drop on you…
Let’s say for a moment that I like pizza…
Scratch that; let’s say I LOVE pizza. (Bear with me…) I have a problem, consisting of my need to retrieve my hot, fresh pizza back from my absolute favorite pizza place while it’s still hot and fresh (they don’t deliver) for dinner tonight. I’ve just phoned in the order from home, and the pizza shop is 2 miles away. Now, this problem has quickly turned into a transportation problem. I can walk over to the bus stop, catch a bus to the pizza place, and, if I’m lucky, catch another quick bus home, to be eating my pizza within 45 minutes. That’s reasonable, is it not? The bus schedule is fairly regular, depending on traffic, and I can more often than not successfully get my personal pizza fix by taking the bus.
Now let’s say my love affair with pizza evolves into something more substantial… I decide to start my own pizza delivery service. I’ve now made the leap from entertaining a personal pizza fetish to running a business. Hopefully, I’ll have many hungry people waiting on my pizza, ready to pay hard-earned cash for a slice or pie.
Clearly, depending on the bus to deliver my pizza to paying customers is not going to cut it. The bus may or may not show up when I need it. The fare isn’t reduced if the bus is late, but my tip and recurring business sure will be. I need dependable transportation, such as a 4×4 truck, to run my business. I need confidence that this truck will be waiting on me and can weather events (pun intended), such as a blizzard dropping two feet of snow. People get hungry in snowstorms too.
Rather than delve back into the MFT or EFSS decision, I want to talk about a critical distinguishing characteristic of your file transport solution, be it of either strain. This characteristic is the Service Level Agreement (SLA) offered by your service vendor, if one is offered at all. Just having one is not sufficient; you need to look for three key terms that will let you know if you might be left waiting at the bus stop. Unfortunately, it’s easy enough for service vendors to dress their bus up to look like a 4×4 truck, so let’s go over the key points of an SLA.
- Service Availability – This should consist of some number of nines (e.g., 99.9%) and most importantly, spell out service uptime targets and a credit schedule. This credit schedule should outline what the vendor will owe you if the service they contractually agree to falls below their target. Some vendors claim a high level of availability but don’t back that up with a credit schedule. If they miss their target, you have no recourse as a paying customer. In other words, you’ve already paid for the bus, but you’re stuck at the station.
- Recovery Point Objective (RPO) – This figure represents the vendor’s target for retrieving your data in the event of a disaster. If a reasonable objective is 30 minutes, the vendor is setting a target of losing no more data than that stored in the 30 minutes preceding an event. For example, while it’s unlikely that a service provider would create tape backups to achieve an RPO, if that were the case, a 30-minute RPO would require tape backups every 30 minutes! Imagine leaving your pizza on the bus for 5 minutes, only to have it disappear. Your bus should guarantee your pizza, if you’re relying on it to do business. Your pizza wouldn’t disappear if you left it in your truck, would it?
- Recovery Time Objective (RTO) – This figure represents the vendor’s target for being able to return access to your data and the service in the event of a disaster. Without an RTO, your service provider is not giving you any indication of how long the service might be down in the event of a disaster. For example, if the objective is 3 hours, the vendor is setting a target of no more than 3 hours to return access to your data via its service, following a disaster. This is effectively the equivalent of the bus service telling you by what time it will resume service. One consumer-grade EFSS service provider that doesn’t compensate users for outages – even paid subscribers – achieved an estimated 99.63 uptime for the second half of 2012, according to an independent news site covering cloud software for Australian and New Zealand businesses. It was down 16 hours in January of 2013, and another 90 minutes in May. Can you afford to be stuck at the station for 16 hours?
Service vendors may offer 100% network uptime, but it’s critically important to understand the stated application uptime. Premium cloud infrastructure environments can be up 100% of the time, but access to the hosted application is all that should matter to you. Are vendors really telling you that the application will never, ever, not even once, for a half-second, be unavailable? If it sounds too good to be true, make sure you understand the claim and have some recourse. If a service provider truly wants to be your business partner, it should be willing to share the pain in the case of an outage.