Welcome to part two of a three part blog series: How to choose an SPI (SaaS, PaaS, IaaS) service provider? If you haven’t read the first posting, you can find it here. We are going to pick up where we left off in addressing both the ROI and culture of a prospective SPI provider.
When evaluating ROI for your SPI provider, keep in mind that just because you can get a service from an SPI provider doesn’t mean that you should. I’ve read a number of articles on companies that have left cloud providers simply because it just wasn’t cost effective. You can find one of those articles here.
Additionally, think of the performance implications. Unless you are bare metal, it’s likely that your virtual host is thin-provisioned amongst a number of other virtual hosts, and at capacity, you can only access about sixty percent of your perceived processing power. Something else you should keep in mind is that if you are successful, truly successful, at some point, hosting in a public cloud just will no longer make any fiduciary sense. As mentioned in the previously referenced article, some companies just outgrow the cloud.
The culture of an SPI provider says a lot about the type of company they are. Recently, I was working with a startup in Manhattan that provided a SaaS based offering. The company had a solid product, a decent team, but ultimately, was missing the mark as an SPI. They targeted the DevOps community, however, they didn’t understand the term at all, nor did they practice DevOps in the evolution of their own application; they operated with a no-ops mentality. With almost two dozen developers, they employed only one operations engineer, and only a nine to five support structure. That says to me that they are never going to be truly successful because they were not willing to employ the assets to become an enterprise class SPI. Additionally, this was a situation that we are seeing more and more, where a SaaS is housed in a IaaS. Beyond the issues this company had in-house with their ability to maintain an operations and support team, they contracted with an IaaS for a bare-metal cloud. Unfortunately, their IaaS was making similar mistakes. The SaaS company paid for complete redundancy of their systems, but only received virtual redundancy. The IaaS had a single router that began having serious issues that caused a need for a nightly reboot, and each night during that reboot, the SaaS company lost access to their application stack for about 15 minutes. Needless to say, this definitely isn’t achieving the ever sought five nines (99.999%) uptime.
In closing, I will say that situations as mentioned in this article are more common than you think. When looking for a new home for your application stack, please keep in mind that there is a lot more to think of than just hardware, but you must think of the cost, personnel, and culture that is managing that hardware. Please check back to read part three of this series that will give recommendations based on my personal experience and what I see in the industry.