CloudVelocity rips apps from data center, spews them onto Amazon cloud

Coming to Azure and OpenStack clouds real soon now

Moving applications from your data center to a public cloud – a process generally called onboarding – requires a lot of manual setup of the public cloud and tweaking of the operating system, middleware, and application software to make the jump. CloudVelocity, which came out of stealth mode in December and which is now shipping the first iteration of its One Hybrid Cloud tool, wants to automate this entire process.

Any kind of automation always sounds easier than it ends up being, and it's reasonable to be skeptical about any tool that claims to automate the movement of n-tier applications in five fell swoops. But Arnand Iyengar, CloudVelocity cofounder and CTO, has heard all the skepticism before and assures El Reg that the application-porting capabilities of CloudVelocity do indeed work.

With CloudVelocity 1.0, the company is sticking with the obvious first leap that any data center is looking to make: out to Amazon Web Services to put their applications on a mix of EC2 compute instances and S3 and EBS storage instances. This feat is complex enough, and it has taken two and a half years for CloudVelocity to get this product out the door. The tool, which is called One Hybrid Cloud, supports Windows and Linux applications running on x86 iron.

Iyengar founded CloudVelocity in December 2010 along with three other colleagues that he worked with at NeoPath Networks, which was setup in 2002 to do storage virtualization and which was eventually eaten by Cisco Systems; Rajeev Chawla is CloudVelocity's CEO, Raman Chawla is VP of engineering, and Panos Tsirigotis is chief software architect.

The company secured a $5m Series A financing round from Mayfield Fund when it uncloaked in December. That was also when it put out a beta version of a Developer Edition and an Enterprise Edition of its tool.

The Developer Edition allows a multiple-tier app to be cloned from your running data center and pushed out to virtual private computer networks on AWS; the Enterprise Edition goes one step further and does the migration out to the cloud for you or allows you to set up a clone of your apps on AWS as a high-availability failover.

As One Hybrid Cloud 1.0 becomes generally available on Tuesday, the company has wrangled another $13m in Series B funding led by Third Point Ventures, with Mayfield Fund kicking in some more dough and Pelion Venture Partners investing for the first time in the startup. It has also changed its packaging slightly, with the Developer Edition now called the Gallium Edition and the Enterprise Edition called the Titanium Edition. The product's name has shifted as well, from CloudVelocity to One Hybrid Cloud, or OHC for short.

Moving an app to the cloud is as easy as 1, 2, 3, 4, 5 according to CloudVelocity

Moving an app to the cloud is as easy as 1, 2, 3, 4, 5 according to CloudVelocity

There are five stages of application porting that CloudVelocity performs. The first one is discovery, when OHC sniffs around the application you want to move and finds all of its software and hardware dependencies. The software can sniff physical hardware or server instances that have been virtualized on the popular hypervisors for x86 iron. It analyses the storage, down to the volume and file levels, and also notes LDAP or Active Directory authentication services. You can move your app to the AWS cloud using the internal authentication server behind your firewall (as most companies do), or you can clone and move the authentication server to AWS.

Then comes the blueprinting phase, when the CPU types and memory configurations running on each server node in the app stack are analyzed and OHC makes suggestions about how to replicate similar configurations on EC2. The storage types and volumes are also analyzed and then blueprinted for similar deployment on S3 or EBS on the AWS cloud.

In the provisioning phase, virtual machines are selected on EC2 and storage volumes are set up on S3 or EBS as needed. The virtual machine types are stored on S3, but they are not fired up on the real EC2 until you are ready to deploy, because that costs money. (Clever, that.) All of the network settings, down to IP addresses and subnets for each node and tier in the application stack, are replicated on Amazon's VPC data center slices.

CloudVelocity has multiple layers of security between the data center and the public cloud

CloudVelocity has multiple layers of security between the data center and the public cloud

During the synchronization phase, OHC goes into the code running in your data center and literally extracts it and packages it up as a bootable Amazon Machine Image, or AMI. "This is not a simple process, but it can be done," says Iyengar. The images in the Amazon cloud are linked through the OHC tool to the apps running in the data center, so any changes to the code running in the data center can be replicated to the cloud.

In the final stage, service initiation, the virtual servers that comprise the n-tier app are booted up in the correct order as determined by the running application. (Generally, you boot database servers, then app servers, and then web servers.)

"For each machine, we take over the system as a whole," Iyengar says. "By maintaining all of these parameters, there is a high probability that the application will run unchanged on the cloud."

It is that "high probability" that has El Reg snickering a bit. But look at it this way: it was an honest answer.

At the moment, OHC 1.0 can only be used to port Windows or Linux apps running in your data center to AWS. But the architecture was meant from the get-go to allow for the porting of apps to Microsoft's Windows Azure public cloud and to any cloud running the OpenStack control freak. In theory, says Iyengar, there is no reason why it could not hook into VMware's Hybrid Cloud Service or Google Compute Engine.

And with the second round of funding announced today, CloudVelocity can start adding in support for these other public clouds. Once that is accomplished, then OHC could – in theory – be used as a porting tool to jump between clouds, not just from data center to one cloud in particular. The first iteration of this will allow for applications to be moved off AWS.

OHC costs $2,000 per server per year if you are using it for application development/test environments or disaster recovery. If you are deploying applications out to AWS, then you buy a perpetual OHC license that costs $15,000 to port the applications running on 50 servers. Those are approximate prices, by the way. The cost goes up based on the complexity of the apps, and goes down based on the number of units you buy. ®

Sponsored: From CDO to CEO


Biting the hand that feeds IT © 1998–2019