Do SLA's Make the Internet More Attractive? | Joe Marion | Healthcare Blogs Skip to content Skip to navigation

Do SLA's Make the Internet More Attractive?

June 7, 2010
| Reprints

In my last blog I explored aspects of the cost-benefit of cloud storage. One key aspect I was hoping would generate some comments was whether people perceive the Internet as an effective link to cloud services.

I am guessing from the lack of comments that (a) this isn’t a very exciting topic, or (b) people haven’t given it much attention yet since it may not yet be a priority. I am hoping it is the latter! In any event, there is much interest in cloud services, so how one connects to those services should be of some interest. In a recent conversation on the subject, a colleague raised the question of whether concerns with performance could be addressed by means of SLA’s (Service Level Agreement).

If one were to implement an SLA for network interface performance using the internet, does that assure the user of a certain level of performance, and provide a means of rectification if that level of performance is not achieved? And, more importantly, does this offset the need for a private connection that is inherently more expensive?

As I previously discussed, overall performance can be dependent on both the ISP as well as the cloud application provider. The network connection could be great, and yet performance could suffer if the cloud application server bandwidth were inadequate. If the cloud application provider is confident enough of their application to offer an SLA, then they are putting their faith in the ISP to provide adequate performance levels to meet the user expectation.

So once again I ask, is this a non-issue? Or, are we so early on the application of cloud computing and storage that no one has given it much thought? I would really like to have both users and cloud storage providers weigh in on this. There are a number of players that have either been providing remote storage services or are looking to get into the market. I am curious as to how the price point of such services will be impacted by internet connectivity versus private connections. Would SLA’s make it more attractive to use the internet?

Does anyone care to share their opinion?



I think it is an issue, but an issue that we don't have much experience with. Your mixing connectivity, storage and transactional services, which makes it hard to respond simplistically .

Perhaps since the beginning of Google, we've been offered the response time of this cloud service, often around a quarter of a second.

For example, I was recently sitting next to an Airbus executive who mused that the human body will soon have "BITE"s, just like jet aircraft. When commercial jets land, the technicians know what to replace or repair, often before the pilot or crew, and do the repair during a typical turnaround, without impacting the flight schedule. BITEs make this possible. I hadn't realized.

When I asked Google what was a BITE, I found:

BITE - Built-in test equipment.

And it told me, without asking, the performance and response time.

About 347,000 results (0.40 seconds)

As a result of this ubiquitous experience, I don't worry about, ask about or perhaps even value the SLA of sub-second response times with Google search.

Would I pay more if I was used to 10 second response times? Would I value the service more if it was delivered slower? Or with significantly more or less results? I'm fairly insensitive.

How about the same for reliability, getting any result or the useful one?

I think Internet end-users have been come to expect very high service levels, both for paid services, as well as ad sponsored services. And, within reason, we're not sensitive to SLAs, as individuals. As we scale up to thousands of users, there's clearly a responsibility to assure that end users continue to experience good enough performance.

It's not a problem until it becomes a problem...

Back in the early days of HIS many vendors ran their systems on a 'cloud'. It was called remote processing or shared service. It worked great until the apps were deployed to mission critical departments (lab, Rx, etc.) where response times are absolutely critical. When the response times decayed they moved the apps to local mini-computers, either as front end processors, or the core of the system.

Then along came the micros and away went the minis. Now we are getting tired of managing local server farms so we want to go back to the 'cloud'. Truth is there is room for all these architectures. Vendors who promote just one don't understand the really complex nature of the HIS /EMR world.

...and that's a real problem!