When the subject of public cloud computing comes-up, it is inevitable that the concept of ‘risk’ soon follows. Often, the ‘risk’ of public cloud is associated with data security and availability. The greatest risk to an organization considering public cloud is not security, it is cost. This is a parallel story with VDI (Virtual Desktop Infrastructure). Initially, the use of both public cloud and VDI were viewed primarily as cost-saving strategies. David K. Johnson (Forrester) makes a very good case that there is a reset in the VDI market.
When considering public cloud, anecdotal reasons against adoption that I hear time and again include:
1) Public cloud is less secure
3) Data security
Rarely do I hear that cost is a concern. As with VDI, cost is generally cited as a gain. This is, unfortunately, wrong.
Before we get to that, let’s tackle each of the public cloud adoption concerns.
Public Cloud is Less Secure
Frankly, if an organization is not capable of providing secure end-user experiences on their own infrastructure, they will be equally incapable of securing end-user experiences in the cloud. Unless there is an overriding concern, such as PCI or HIPAA, there really is not a security excuse to shun public cloud. Even with those concerns, there are niche providers that provide value-added offerings.
The largest public cloud provider, Amazon, has had some highly publicized outages. Their outages are likely less frequent, and certainly more publicized, than the typical datacenter. The organizations that operate most datacenters simply cannot afford to build-out full redundancy, and cannot react to problems as quickly as a large provider. This has led to outsourcing, co-location, and other strategies that put the burden of infrastructure uptime on a provider. Simply put, if back-hoes cut two fiber lines, to which datacenter will the repair truck scramble first; the mid-sized business, or Amazon?
This relates to the first point. If your organization is not very good at protecting data in a datacenter that is owned and operated by the organization, it is not likely that the organization will be either better or worse at protecting data that is hosted by a public cloud provider. Amazon has recognized that encryption is important, and continues to provide more services.
If we wrap these three points together, public cloud does look very risky. However, these points don’t capture the greatest risk. That risk is not security-centric; it is operations-centric.
When making the decision to adopt public cloud computing as part of a strategy, many of the early adopters are looking to gain flexibility. For example, a Software-as-a-Service company needs to deal with peaks and troughs of user activity, and sudden increases or drops in end-user numbers. For a SaaS, the automation capabilities – spin-up instance for peak, spin-down for valleys – are very attractive. Of course, the potential cost savings result from usage-based billing, and relief from the risks of capital expenditures on hardware.
However, this ideal is easy to proclaim as a goal, but a little more difficult to achieve in practice. Just as public cloud providers are really good at running complex infrastructure, to point that they make it look easy, SaaS providers are really good at running complex software and making it look easy. That’s how they make their money, after-all. Building a SaaS can involve mixing out-of-the-box software, which isn’t always built for multi-tenancy, with in-house software to add the ‘as-a-Service’ part. Start with the software that is being sold, add billing, monitoring… you get the picture. For SaaS providers, virtualization has been fantastic because they can quickly spin-up new instances for a new customer, so long as they have the hardware to run them.
Moving that pile of software from a private, virtualized datacenter, to a public cloud is not exactly easy. On the technology side, the ancillary tech (billing, monitoring) needs to be accommodated. Also, if customers are tied to instances, spinning-up or spinning-down instance on-demand isn’t going to be very helpful. You need to do some heavy tweaking to get your solution to be truly multi-tenant.
There is also a human component. Simply put, automating a public cloud based SaaS to respond to peaks and valleys in demand isn’t easy, and it is on an infrastructure, and using tools, that aren’t familiar. It’s tempting to say, “Just hire an AWS wizard”, but we all know that the reality isn’t so simple. Such people are rare, and therefore expensive, and they don’t know anything about your solutions. Instead, you need the existing team. Since you can’t flip a switch between the private and public infrastructure, you’ll need to a balanced approach, which is a challenge considering that most IT teams are at peak utilization simply keeping the ship afloat.
Along with the human component is corporate knowledge. There can be tremendous cost risk in moving from private to public. A SaaS provider who knows their business has a very, very good idea of the short- and long-term costs of setting-up a piece of iron, and how much return they’ll get. Of course, those capital expenditures create risk; if you sign a big customer one day, and lose another big customer a month later, your hardware vendor isn’t going to provide a refund. When considering public cloud, though, the risk is in the unknowns. With an entirely new billing models for servers, storage, and whatever other add-ons are needed, organizations simply have to give it a go to start building a rough understanding of what costs will look like. Remember, this at a point that is long before an organization can get fancy with the public cloud automation and tweaking their own solution to trim public cloud costs.
There is security risk in adopting cloud, especially a security-challenged organization. However, just as with VDI, the risks of cost are significant. While it’s tempting for bean-counters to look at public cloud and declare it to be a method of gaining cost-savings, that’s simply not going to be the experience for organizations that are moving complex production workloads to public cloud. Cost savings can be achieved, but ironically, they come at a price. Learning how to take advantage of public cloud functionality takes time and effort, which means spending money. Certainly, the advantages beyond the learning curve could be tremendous to many organizations.
The SaaS example that I’ve followed is based on a real customer. They are in the process of moving from their highly virtualized datacenter to AWS. They are far enough in that they have a good handle on costs, and know with certainty that they will get to a point where they can realize cost savings (yes, including paying us less!). Beyond cost, they see flexibility as, by far, their greatest gain. To expand from a West-coast customer base is as simple as spinning-up instances in a different AWS zone; that is far more expansion-friendly than establishing a datacenter in another region. Despite dire warnings of outages from hardware partners, yells of compromised security from all quarters, and the scale of the challenge, they are already seeing cost savings in some areas, improved responsiveness and uptime improvements (yes, improvements), with no impact on security.
As with VDI, public cloud isn’t for every workload at every organization today. However, the reasons for this, and the associated risks, are not as straightforward as naysayers would have it, nor are the benefits as clear-cut as the champions will tell you.
To add a final twist, the example of a SaaS provider running on AWS and an organization considering VDI are intersecting. At Citrix Summit/Synergy, Citrix talked about how a service provider could provision DaaS (Desktop-as-a-Service) on AWS. Check the latest interesting tidbits at Amazon. Note that it includes a calculator so the service provider may, in-fact, take some of the cost guesswork out of the equation.
Of course, for a SaaS provider or any organization putting complex, custom server-based workloads on the cloud, the guesswork and associated risk can be mitigated only through experience.