To cloud or not to cloud

This post was also published in the Wall Street Journal's CIO Journal.

Cloud is all the rage in IT right now, offering nearly instantaneous time to value, continual feature upgrades, and reduced cost. However, it is important to delineate different types of cloud offerings and what should and shouldn’t run in the cloud. There are also several contractual issues CIOs should consider when dealing with cloud vendor.

Software-as-a-Service is mainstream and cost-effective

Among the very first cloud offerings, software-as-a-service (SaaS) solutions such as Salesforce.com Inc. and ServiceNow Inc. are very compelling. The offerings are completely self-contained, turnkey and offer rich feature sets that are continually enhanced and refined by the vendor. Often SaaS vendors integrate with each other which makes it easier to piece a stack of software together.

When selecting a SaaS vendor, CIOs should ensure that the vendor has a high standard of data security and offers an interface by which data can be retrieved into internal systems. Lines of business have a tendency to start using SaaS vendors on their own, and savings and compliance can be realized by rolling up several of these point purchases into a global deal with a single vendor. An interesting new tool from Skyhigh Networks can monitor what SaaS tools are being accessed from a company’s network in order to facilitate discovery of SaaS usage.

Legacy enterprise software vendors such as IBM Corp., Oracle Corp. and SAP AG are increasingly acquiring SaaS companies in order to continue their growth beyond traditional packaged software. After such acquisitions, pricing typically increases two to three times, so in order to have a predictable experience when engaging a SaaS vendor, a CIO should consider singing multi-year deals with a set yearly increase and exit options.

Infrastructure-as-a-Service is great, but expensive

Infrastructure-as-a-service (IaaS) offerings such as Amazon Web Services are a convenient method to elastically expand your data center without buying new equipment. Amazon.com Inc. provides security features such as Virtual Private Cloud (VPC) which segregates your network traffic and allows access via a secured virtual private network (VPN). In addition Amazon provides Direct Connect which offers point-to-point access to your Amazon infrastructure.

The elasticity and self-service features of infrastructure-as-a-service make it easy for internal customers to add machines instantly without waiting for machines to be ordered, racked, and kick-started. Additional machines can be added for heightened traffic due to large events or seasonality.

In order to build out an IaaS service, it is important to lock down security with features such as VPC and VPN. From a compliance perspective, it is important to have a clear policy of what can and can’t be run on the IaaS, as well as a plan to move systems off of the IaaS and back into a data center within a set amount of time in case the systems need to be moved back due to a security breach or legal issue.

The downside of IaaS is the price. Pricing can be complicated in terms of figuring out how many and what type of instances are needed, and whether or not to use reserved instances with a time commitment that are cheaper. At CBS Interactive, we have a director of cloudarchitecture that assists business units with this type of decision making, and we continually monitor the aggregate Amazon charges in order to maintain efficiency.

IaaS charges are completely operating expense, and cannot be depreciated as a capital expense as is normally the case when purchasing hardware for a data center. When I first started using Amazon Web Services in their private beta a decade ago, after 25 or so instances it was cheaper to run your own hardware. Now that number is 200 or so instances. However, the total cost comparison should include the business agility offered to internal customers in terms of easily spinning up new machines.

Private clouds are emerging

At CBS Interactive, we host a large number of websites ranging from CBS.com to CNET to Last.fm. We are currently building out a private cloud in one of our main data centers where internal customers will benefit from CapEx amortization and have the agility of an IaaS provider. At that point, what to run where will become a simple math equation since system administration will be comparable between our IaaS and our private cloud.

Private clouds are difficult to implement, however, as they require cobbling together vendors that offer self-service provisioning, load balancing, storage access, and database administration that leverage the existing networking and system infrastructure in a data center.

Hybrid clouds are not realistic for existing applications

Many vendors claim that hybrid clouds offer elasticity without having to move systems into a SaaS or PaaS environment. In my experience, this is not a realistic alternative. Applications that can run in a hybrid cloud are specifically designed to be split across different data centers and architectures.

Taking a legacy application and running parts of it outside of a data center with a cloud provider requires that incoming requests into that application are load balanced across the two, that data access from the cloud version to the source system is available without latency, and that some data is synchronized between the two in such a way that the application performs as expected. The amount of work to accomplish all of this on an existing legacy application typically far exceeds the benefits of elasticity.

Platform-as-a-Service has too much lock-in

Platform-as-a-Service (PaaS) offerings such as Google Inc.’s AppCloud, Heroku Microsoft Corp. ’s Azure, and Amazon Beanstalk offer the ability to drop in code modules without having to worry about features such as load balancing, scaling, user management, and database management and tuning.

While they are typically not appropriate for legacy applications, these services offer incredibly fast time to value for new applications. However, PaaS platforms are like Hotel California – it’s easy to get in and hard to leave, as the application is heavily locked into the PaaS vendor and cannot be easily moved without significant re-engineering.

If the application needs to be moved due to a compliance or legal reason, or it has grown so much that it is exorbitantly expensive to run on a PaaS, organizations can find themselves stuck between a rock and a hard place. PaaS is therefore much more suited for smaller organizations, and only applicable to larger organizations that have a strongly defined PaaS policy in place on what proprietary PaaS services may be used in order to ease a transition out of the PaaS.

In addition, given Heroku’s recent metrics issues, it is important that independent measuring be put into place to ensure that the PaaS system is performing as promised.

Features-as-a-Service require too much access to internal systems

I am of course using the term feature-as-a-service in jest. There is currently a rash of analytics, Big Data, and mobile enablement vendors pitching the enterprise with a cloud-based approach and promising the simplicity of a SaaS solution.

However, virtually all of these solutions require that either the enterprise continually copies mountains of data into the vendor’s cloud systems, or that the enterprise allow deep vendor access into internal systems such as databases. Either option causes innumerable security and compliance headaches.

Some of the vendors are beginning to shift, either only targeting the SMB market, or adding a traditional on-premise option for their software. Another emerging option is to have the vendor deploy their solution within an Amazon Virtual Private Cloud, thereby accessing secure enterprise data within that cloud, but without compromising security or compliance.

Perhaps data oriented features-as-a-service will be more viable if an enterprise’s data shifts to the cloud onto the new breed of systems such as Amazon’s RedShift data warehouse. In the meantime, the benefits of a feature-of-a-service cloud offering rarely outweigh the compliance and data cost of onboarding the vendor.

To Cloud or not to Cloud

There are different types of cloud solutions, different types of applications suited to the cloud, and different levels of comfort with an enterprise to move systems to the cloud. It is important to evaluate each cloud option with a well-formulated approach that looks at the overall benefit, cost, exposure and includes an extraction evaluation to avoid lock in. Cloud on!