Computing on Demand as a Business Strategy
Deploying applications or moving data to the cloud is rarely an all-or-nothing proposition. Instead, internal versus external computing is a balance whose formula is unique for every corporation. Using the criteria we've discussed in this chapter, you can build your own decision-making spreadsheet to aid in the process of deciding whether to try moving to the cloud. In later chapters we'll look at particular clouds and the impact they can have on your applications. In the rest of this chapter, we'll look at more general answers to questions about cloud strategies. Most of the answers will start with the assumption that you've already committed to move at least some of your data infrastructure to the cloud.
Regardless of which cloud you do choose, you should always keep in mind what mechanisms are in place to move data back to your internal data processing infrastructure if you decide not to continue the project, or if you decide that the initial balance of data or applications inside and outside the cloud should be changed.
An example may be useful here. While few would dispute that Salesforce. com is a great customer relationship management (CRM) system, the cost per seat is a key decision point in adoption for most organizations. One solution that we keep hearing about from different companies is about reducing the total seat costs by using Salesforce.com for the front-line salespeople, but something like SugarCRM for the call centers. Using two separate cloud applications isn't unusual, but it does lead to the question of where the data is stored and how it is moved from one application to another. One company had a middleware data mashup product from Apatar.com periodically moving data back and forth to make sure the call center knew about recent outside sales activity. This little company with roots in the old Soviet Republics also has offices in Boston, and is addressing the huge data conversation market. It's not hard to imagine a sales manager looking at the huge cost per seat for something like Salesforce, yet wanting to populate a hundred seats in a call center. This solution is tailor-made for this exact situation: The sales manager can download a free copy of Apatar and drop connectors onto the Apatar workspace. Each connector has a set of credentials for the data source, and has connector nubs on them for tools. Easiest are straight field conversions, where one program uses "firstname" and the other "fname"; harder are the items where one separates the first and last names and another uses only fullname, or where one program uses department codes and the other uses names. All this type of data manipulation is simple with this type of tool. Considering that we've heard of all kinds of companies paying some pretty big bucks for this type of data migration, it's no wonder that this tiny little company has gotten so much attention. Although it is certainly not the only tool of this type, this drag-and-drop data mashup tool is certainly worthy of attention.
While cloud computing has begun to take hold at the opposite ends of the computing spectrum, we're also seeing clouds gaining traction in the small-to-medium-size business (SMB) market. As the SMB world seeks to use Internet presence to compete with companies both larger and more agile, we've seen a shift in how they're starting to use cloudlike applications to leverage their Internet presence, allowing them to provide considerably more services to their customers than with traditional data processing methods.
As one example, we're seeing more and more Web designers taking responsibility for maintaining Internet servers. On the one hand, smaller organizations don't have the resources to dedicate workers to a single IT task. On the other hand, historically it has been these situations, where IT workers are required to perform multiple tasks, where systems administrators become less vigilant and attackers are able to exploit security weaknesses to turn those weakened servers into illegal download sites or zombies in a "botnet" army. This liability seems to be a new driving force for SMB organizations to look at clouds, to sidestep the potential liability of maintaining a server farm. However, this trend has some unintended consequences if we look further down the IT support chain.
Considering just how much Web design talent there is out in the world, it just makes sense to leverage this talent pool for special or new projects. Traditionally, you had to spin up a new server, customize it, add users, do penetration testing, fix the holes, load the application development environment, and then invite the contractors in to play. But all you're really after is some cool clean Web code for your smoking-hot new site. So why not spin up a site in the clouds, and get up and running on this new project in significantly less time? Since any cloud vendor worth anything has already done the patching, securing, and penetration testing, you can probably spin up a development site faster than you can steam a latté.
Clouds may sound like a do-all strategy, but that silver lining also is a stormy scenario for value-added resellers ( VARs). Countless small and medium-sized companies look to VARs to provide the application development and IT support that they cannot supply from internal sources. What we question is whether the outsourcing trend is becoming a crutch. VARs aren't always going to look out for the best interests of the customer as they look to increase their profits. What we can't tell is whether this trend toward cookie-cutter solutions is also going to stifle the creativity that has made the Internet such a great resource. Or will this trend toward standardization make it even easier to migrate to generic clouds? The successful VARs that we've seen are the ones that have used hardware sales only as a service to their customers; and instead are using the outsourcing trend to provide high-profit services. We've especially seen this as giants such as HP, Dell, and IBM carve up the computing hardware market and somehow survive on tiny profit margins. The trend over the past decade has been toward services, and we just have to believe that those services are eventually going to live in the clouds.
A saving grace is that cloud vendors are working with many VARs to develop new profit models for this part of the industry, and the same vendors are looking to build direct partnerships with customers—direct partnerships that some say will reduce the need for SMB customers to rely on VARs for the bulk of their IT support. We maintain that with any paradigm shift in the IT industry, there will always be some pain as we see the adoption of the new technology. Some of the retooling examples we've seen are from mini-computers to PCs, from PCs to the Internet, from paper to intranets and the Internet, and from 800 telephone numbers to websites. Each technology shift has been a double-edged sword, with ramifications both seen and unseen. Said a different way, there will always be some fallout as the next disruptive technology appears, but the survivors will be those who plan for the change and manage it, rather than hiding from it.
It's difficult to forecast with any accuracy precisely how all the economic pieces of a major technology shift will work out. It's certain, though, that cloud computing is bringing about shifts in the way companies think about the allocation of costs in IT. Part of those shifts deal with recurring costs, and many of those recurring costs are built around partnerships with cloud vendors and with VARs. We're also predicting that as the comfort level sets in with clouds, the finance folks will start to get used to the concept of the rent-a-data center attitude that clouds can provide. If you look at the processes that went on during the New York Times indexing project, you can easily see how the temporary nature of cloud computing has really started to catch fire.
Let's now look a little more deeply at the cloud's impact on partnerships.
The Cloud Model for Partnerships
There is no way I'm going to give Company X a log-in to my server!" We've all heard this before. It might be personalities, it might be regulations, or it might be just plain paranoia, but all the same, we often run into situations where it could save Company X a huge amount of money if Company Y's buyer could just log-in and check inventory for a fast-selling widget, yet Company X can't seem to loosen its corporate controls enough to let it happen. The problem in this case is where we put neutral territory that both companies can access and control without exposing their internal IT infrastructure. It's not an unreasonable position, really. Security surveys during the last couple of years have indicated that partners are a huge, legitimate security threat for most companies. If we assume that allowing access to certain "inside the firewall" information is a legitimate business need, how can we make it happen without unnecessarily endangering the inner workings of our corporate network?
The answer for some has been to use a cloud service as a common area for cooperative processing. Instead of spending the time and money building a neutral zone, why not use a service? After all, it wouldn't be hard to have several images to work from, with one running for Company Y and another running for Company Z. The common files, and common network access points, are outside either company's security perimeter, allowing the files to be shared without requiring that security protocols be breached. All data transfer can take place over secure VPN tunnels; policies and procedures can be put into place to govern precisely which files can be synchronized to cloud storage.
Let's look at a scenario where all the public-facing systems for Company X live in the cloud, but finance and human resources live in the company's local data center. However, finance certainly needs to get data off the public e-commerce site. Depending on what consultant you ask, the answer is most likely going to be some sort of proxy. The whole idea is to hide from the outside world the details of what the inside of the company looks like.
On a more personal scale, the authors used the Microsoft SkyDrive cloud to write this book. Instead of going through all the hassles of setting up a DMZ server in either of our facilities, we found it much easier to use a cloud service to store drafts of the book along with support material, images, and notes to ourselves. We could have easily built a system on a spare server, but that would have taken a machine away from our testing infrastructure and someone would have had to maintain it. This way, we can always get to our material, it's backed up by someone else, we aren't paying utility bills, and we didn't spend all the time to bring up a content management system. We've heard the same story from countless others who needed a common storage area for a project, but who couldn't or wouldn't open the firewall for the other party.
Going a bit further into Microsoft's cloud offerings, the folks in Redmond didn't leave SkyDrive to handle all the cloud file storage chores; a separate service called Live Mesh automates the process of synchronizing files between a computer (or a series of computers) and the cloud. Of course, Microsoft is far from the only provider of services like these. Dropbox, for example, is a popular file synchronization service that provides cross-platform automated updating. Media Fire is one of the many cloud services that allows you to share files with any number of people with whatever level of security suits you best. Of course if you're using a Mac, you've practically had Mobile.Me rammed down your throat.
What systems like these provide are a fertile ground for customized connections that provide data synchronization and a place for applications to more easily exchange information. Amazon's S3 storage system is a frequently used platform for development, and we've started to hear about developers writing wrappers for the system that will allow multiple parties to mount a common storage area with full read/write privileges. So we can easily imagine a special directory on both Company X and Company Y servers that are a common area. In this example, neither company is exposing its entire infrastructure, but both companies are able to access a shared directory. One provider of just such a solution for Linux servers is SubCloud.com (www.subcloud.com), where an application installed either in the cloud or locally extends the server's capabilities to share the S3 storage. A good analogy is how an income tax preparer uses a special set of forms to convey your income tax information to the Internal Revenue Service. Formerly, the common data transmission medium was the U.S. Postal Service. Now, those same forms are electronic, so the tax preparer sees an image that is very familiar—just like the old forms—but the IRS sees tagged information fields transmitted to a public proxy and eventually input into the IRS processing system. The point is that the data can enter a DMZ in one format and exit in another. It can also scrutinized at several levels, so that a certain level of trust can be established. Perhaps you could call your proxy "Checkpoint Charlie"?
At the workstation level, there is a cross-platform solution by Bucket Explorer (www.bucketexplorer.com) that utilizes a file explorer-like interface to provide team folders on the Amazon S3 system. That has a direct analog from both Microsoft and Apple. The point is that data can be input on a Mac, examined by a Linux machine, and then perhaps a Windows machine could be the SQL host that stores all the transactions.
The issue of interface—how data moves from local network to cloud application or from desktop to cloud server—is one of the issues that differentiates one cloud system from another. There are, if not an infinite number of ways to make these things happen, at least a large number of options. We've already seen the drag-and-drop interface of Skydrive and Media Fire, and the automated synchronization of Mesh, Mobile. Me, and DropBox. There are many others as well, including some with roots in earlier, nonvirtualized operating systems. Some developers have significantly stretched the original intent of the "named pipe" interfaces by having processes on different servers using a shared file system for interprocess communications. The concept is that a Python app running on Amazon EC2 might have a file mount to Amazon S3, but Company Y's Linux server also has that same Amazon S3 share-mounted on its accounting server. With a shared file area, the IT personnel can work cooperatively to implement a named pipe on the shared area so that immediate information on widget orders can be transferred from one company to another without exposing anyone's internal infrastructure. Peter A. Bromberg, while exploring the possibilities on the Egghead Café for .NET programmers, noted:
The point we're trying to make goes back to the quote from Sir Isaac Newton about standing on the shoulders of giants. Just because the original intent of this was X doesn't mean it can't be extended to do Y. It should also be pointed out that named pipes aren't the only method for inter process communications, just one of the legacy methods commonly found.
Brian J. S. Chee is a senior contributing editor at InfoWorld magazine. Chee currently does research for University of Hawaii School of Ocean and Earth Sciences and Technology and has a unique insight into networking trends and the emergence of new technology.
Curtis Franklin Jr. is a senior writer at NetWitness and been an information technology writer for more than 25 years.
Printed with permission from CRC Press. Copyright 2010. Cloud Computing: Technologies and Strategies of the Ubiquitous Data Center by Brian J. S. Chee and Curtis Franklin Jr. For more information about this title and other similar books, please visit http://www.crcpress.com/.