While IT has been battling lock-in since the earliest days of computing, not too much attention has been paid to the problem of vendor lock-in as IT rushes to madly to embrace the cloud.
What to Do?
To prevent being locked in to a single vendor, you need to ensure that the architecture you have selected can run on multiple clouds, and that the data can be easily migrated from Cloud A to Cloud B. While that sounds trite and simple, it's still true. And in theory, it is not hard. But as usual, God (or the Devil; take your pick) is in the details.
Totally new development without any use of legacy code is the easy case, but it is not so common; we all carry around the accumulated baggage of the past. However, should you be fortunate enough to have this luxury, I would suggest developing on Eucalyptus (see the later section on this platform) or OpenStack, a new open source effort led by Rackspace and NASA, and using one or more of the most favored languages for cloud development, namely C++, Java, or Python, or PHP for less-demanding applications.
This approach gives you the greatest choice of providers, including those discussed in Chapters 3, 5, and 8 through 11. Eucalyptus runs under VMware, is compatible with AWS, supports Windows Virtual Machines (in Eucalyptus Enterprise Edition 2.0), and is supported by many, if not most, of the cloud service vendors. In addition to Linux images, Eucalyptus EE 2.0 customers can now deploy images running on Windows Server 2003 and 2008 and Windows 7, along with an installed application stack in a Eucalyptus private cloud environment.
OpenStack, currently built with the Ubuntu Linux distribution and using the KVM virtualization hypervisor, is compatible with Amazon's AWS and is expected to run directly on Linux as well as be compatible with VMware, Xen or Hyper-V. However, if, like most enterprises, you need to deal with an accumulation of legacy applications, then it is obviously important to understand what the accumulated inventory of platforms and languages consists of, and to determine whether source code is available or has been partially or totally lost, which happens much more than one might imagine).
Next, you need to determine whether to use this as the opportunity to recode or to just make the existing applications work in cloud. If you are recoding, then the previous advice holds. If not, vendor choices for migrating applications to the cloud will be dictated and limited by several constraints:
- Does the vendor support the operating systems and programming languages that you require?
- Which database management systems are required? Is there a vendor-maintained "image" that supports your DBMS?
- How much memory and processing power is required? Does the vendor provide sufficiently powerful machines, and is there room to grow?
- Do you choose a private, public, or hybrid cloud? What impels your decision?
- Do the management tools you have in place support management in the cloud? Are there upgrades available? If not, you need to select one or more of the tools described in this book.
- How rapidly do your needs change, and can your vendor provision and deprovision fast enough?
- Does the vendor's service level agreement (SLA) meet your needs?
- Is your auditor satisfied with the vendor's documentation of its compliance with SAS 70 and ISO 27001? Is SysTrust certification available?
As RightScale.com states on its Web site:
All clouds are not created equal, and all clouds do not create equal lock-in. Consider the following questions regarding the portability of your current application from one environment or cloud to another. They provide a way to measure the degree to which you may risk lock-in with a given cloud choice.
- Application: Do you own the application that manages your data, or do you need another tool to move your data or application?
- Web services: Does your application make use of third-party web services that you would have to find or build alternatives?
- Development and run-time environment: Does your application run in a proprietary run-time environment or is it coded in a proprietary development environment? Would you need to retrain programmers and rewrite your application to move to a different cloud?
- Programming language: Does your application make use of a proprietary language, or language version? Would you need to look for new programmers to rewrite your application to move?
- Data model: Is your data stored in a proprietary or hard-to-reproduce data model or storage system? Can you continue to use the same type of database or data storage organization if you moved, or do you need to transform all your data and the code accessing it?
- Data: Can you actually bring your data with you, and if so, in what form? Can you get everything exported raw, or only in certain slices or views?
- Log files and analytics: Do you own your history or metrics, and can you move it to a new cloud, or do you need to start from scratch?
- Operating system and system software: Do your system administrators control the operating system platform, the versions of libraries, and the tools, so you can move the know-how and operational procedures from one cloud to another?
As this book is written, if we use a normalized example of a virtual 8 GB RAM system with 320 GB of disk running Windows Server Enterprise 64-Bit operating system, operating continuously for a month, the charges from four large vendors are as shown in Table 1.
Table 4.1 Vendor prices.
|Vendor||Month||Hourly||What Is Provided|
|Rackspace Cloud||$ 417||$0.58||8 GB RAM 320 GB Disk included in base|
|Amazon AWS||$ 394||$0.48||7.5 GB RAM, Incl. 320 GB S3 Storage|
|Terremark vCloud||$ 607||$0.72||Incl. 8 GB RAM and 4 CPU + 320 GB Disk|
|SoftLayer CloudLayer||$ 435||$0.50||Incl. Windows Server + 350 GB Disk|
Bandwidth charges can vary significantly, as can surcharges for heavy processor (CPU) usage and for extra disk space. A more detailed discussion of economics and performance is provided in Chapter 5. Linux platforms are less expensive, as no licensing fees are due to Microsoft.