CEO Raj Dhingra says platform automates cloud migration, easing test/dev, disaster recovery, and optimizing cost.
It’s easy to get all “cloud first” when you’re talking about new, greenfield applications. But how do you get the core business applications running in your data center – so-called brownfield apps – easily and efficiently migrated to the cloud? That’s the problem startup CloudVelox set out to solve, with the larger mission of helping CIOs build “boundaryless” hybrid data centers. IDG Chief Content Officer John Gallant spoke with CloudVelox CEO Raj Dhingra about how the company has automated the migration of complex, traditional applications to Amazon Web Services (and Microsoft Azure in the near future). Dhingra explained how companies are using CloudVelox’s One Hybrid Cloud platform to not only migrate apps, but to build cloud-based disaster recovery capabilities and simplify a variety of test/dev chores.
You have a long and very successful background in the tech industry. Talk about this opportunity and what CloudVelox set out to do?
The company was founded in late 2010, beginning of 2011 at a time public cloud was gaining interest in the minds of enterprise customers. There were quite a few companies trying to help enterprises and developers build new applications for the cloud. Vendors called them greenfield applications. We all heard companies who were innovators and early adopters talk about cloud first, mobile first, building customer-facing applications that can take advantage of the cloud.
What nobody seemed to have focused on was what about my existing data center applications? Let’s call them our brownfield applications. How can I take advantage of the cloud for my existing brownfield applications that I run in the data center? There are anywhere from 15 million to 80 million VMs running in data centers around the world. What about them? How can I take advantage of that? CloudVelox focused on the brownfield applications and how enterprises can migrate and run those applications in the cloud and how can that be automated.
The secret to cloud computing is automation. You request a service, maybe it’s infrastructure-as-a-service, then you are able to quickly spin it up and pay as you go. In a similar way, how could you automate taking an application that’s running in your data center and then run that in the cloud without having to do a lot of manual script-oriented effort? That was the vision.
Let’s go solve this problem. It’s a tough problem to solve. There are many things that need to occur for this automation to be useful and valuable, to allow enterprise CIOs to think about a boundaryless data center. What that means is, how can I basically manage my virtual data center as if it’s one data center, whether I actually own the data center, I run some of my workloads in a hosting facility or I’m running this application on Amazon Web Services. Think about all of that as a seamless set of resources and applications and, more importantly, be able to actually move that workload from any location or data center to another.
MORE: We’ve mapped aggressive cloud data center expansion by AWS, Google & Microsoft
When we talk to analysts or customers, there’s the sense that people don’t move those brownfield applications either because they’re worried about the security of the data or because they don’t see a huge cost advantage in making that change. Are you saying that it’s really just too difficult and you’ve overcome that obstacle?
In the past, many of the concerns have been around security or maybe about performance. We’ve seen a progression over the last few years where many companies of different sizes started to operate in a hybrid IT model. I might take some of my existing workloads and refactor them, modernize them so they can take advantage of native cloud services. It is not that straightforward to take that brownfield application and make it run.
There’s a variety of issues that come up. Traditional tools have been more about manual processes, taking a VM and doing an image conversion so it can run, let’s say, in AWS or Azure. There’s a lot of configuration required because the way the application was running in your data center required a certain type of server, so much memory, a certain type of storage infrastructure. You may have set up your network in a certain way; how your subnet works, how your IP address is used, physical IP addresses. Maybe you set up security groups and you locked down some ports and opened up some ports. If you’re going to re-host that in the cloud, all that needs to be replicated, keeping in mind the matching services in the cloud. Your data center may be running VMware, but AWS is not. How is this virtualized instance in EC2 going to use the right kind of storage, which is EBS on AWS? How will my network design map into a virtual private cloud on AWS? How do the security characteristics in my data center match the security groups on the public cloud?
If you do this manually it’s overwhelming, it’s time consuming, it’s error prone and many times people find it doesn’t work. The key was to address these barriers, automating to reduce that complexity of learning what I have in my data center, to reduce the complexity of learning what’s in the cloud. The cloud is a very fast-moving set of services based on the cloud provider. Do I have people trained to do this mapping and recomposing with matching services? We had to take a holistic approach understanding the infrastructure, understanding the application, looking at the data, looking at the database and all the apps that composed the particular workload.
What applications is your system appropriate for and what are some applications that it’s not so appropriate for?
Before I answer that I’m going to step back and make a point. What I’ve seen is there is a great need for education. People are trying to learn about the cloud and what works and what doesn’t. One of the things that we have focused on is providing some very good content around how to do these things. What’s important and what’s not? Your question maps exactly to a 10-installment blog we started a few months ago. We’ve written about why it makes sense to go to the cloud, the three paths you can use to go to the cloud – re-host, re-platform, re-factor.
The third blog post was: How do you select what are good candidates for the cloud? And the last one that’s just gotten published is: What are bad candidates for cloud migration? For example, if you look at what might be good candidates for cloud, what are the criteria you have to use? First and foremost, is the application operating system environment supported in the cloud, at least for re-hosting purposes? If your application is running Windows or Linux, that’s going to be a good candidate. If it’s running a proprietary version of your OS, then it will need some modernization or some re-platforming. For example, if it’s running Solaris or IBM AIX then that needs some work before it’s going to run in the cloud.
The second criteria can be, is your application running on proprietary, custom hardware which is actually not available in the cloud? If it’s running on some ASIC-based appliance that uses proprietary silicon, that hardware environment is not going to be available in the cloud either. You need to virtualize the application before you can move it there. Third, does your application have any dependency on another application or service that’s running in the data center? Maybe it uses AD {Active Directory}. You can move it to the cloud but then you need to set up a VPN or some sort of network connection.
AWS offers what’s called Direct Connect where you set up a high-speed link between your data center and AWS and the cloud becomes an extension of your data center. Are you concerned about data security and data sovereignty? If you are a global company, you’ll need to maintain some of your data in the right location. These are some of the factors that affect how you think about the right applications. Typically, Windows-based apps, Linux-based apps, collaboration apps, ERP applications, Oracle, SAP, SQL, we’ve seen customers basically take many of these applications and re-host them in the cloud.
+ ALSO ON NETWORK WORLD: Tech Q&As: The IDG Enterprise Interview Series +
What clouds do you work with?
Currently, we have been helping customers with migrating or protecting their data in Amazon Web Services. We plan to deliver Azure support. The source could be your data center running VMware, Hyper-V, Xen, KVM. For destination, we’ve commercialized Amazon Web Services. The second most popular cloud we are hearing about in 2016 – and this was not the case as much in 2015 for brownfield applications – is Azure. We are commercializing support for that by the beginning of 2017.
The third cloud, when we talk to enterprises, seems to vary. For some customers it might be Google, maybe it’s OpenStack, maybe it’s an IBM software cloud. We haven’t found a third cloud to be very popular. A very large percentage of enterprises today are operating more in one cloud and maybe two clouds. I have spoken to one customer that’s actually running in four different clouds. That’s more the anomaly today.
It would seem that one of the strong use cases of this is creating a test and dev environment for a particular application in the cloud so if you want to make changes to it you’re doing it there instead of on the live application. Are people doing that?
Yes, they are. There are three main use cases that we’ve seen for the cloud. The first one we’ll call cloud migration and I’ll dive into it in a little bit more detail in just a minute. The second one also gaining popularity is what I call cloud recovery. An enterprise doing traditional disaster recovery for business continuity purposes had a primary data center and a secondary data center. My secondary data center needed to be acquired, with Capex, OpEx impact. I needed to maintain it. That’s very expensive and very high operational impact. We’re helping those customers with replacing their secondary data center with the cloud. You continue to run your applications in your primary data center but we can actually help them failover to the cloud. More importantly, we are able to recover their application in a matter of hours rather than days without significant effort.
The third use case is what we call cloud Dev/Test and that’s exactly the type of example you mentioned. Maybe my development team wants to test the scalability of my application based on going from 100 users to 1,000 users to 10,000 users. Trying to set up an environment and acquire the type of infrastructure to be able to test for 10,000 users would not just cost a lot of money, it would take a lot of time. Then you may not need that again. So the ability to scale that and provision that and only pay for how much time you use it, is a very good example for being able to clone your application workload from your data center to the cloud.
We recently saw a customer who was running Oracle in their production environment and wanted to go from Oracle 11 to Oracle 12. However, they did not want to bring down their production system to do the test. Cloning it in their data center would take them, again, a great deal of expense and effort. What we did was essentially replicate their entire Oracle workload into AWS. They then tested the Oracle 11 to 12 upgrade, learned what worked and what didn’t, validated the upgrade and applied that to the production system. That’s a very good example of being able to do something without incurring a great deal of Capex, the amount of effort required to create the environment.
Could you share one great customer example that really shows how people are using this?
One is a company called Exar. It’s a manufacturing company and they were faced with a few issues at the same time. One was that they wanted to run some of their applications in AWS and needed to find a way to get them there with a smaller IT team. Less than 15 people, I think. Second, they have a primary data center here in the Bay Area, but the secondary data center was in Sacramento and they had aging hardware that was coming up for refresh.
It would have cost a great deal of money to buy new hardware and, of course, the CFO was asking why do we need to spend this money for a secondary data center? Why don’t we look into the cloud? The third issue was actually the one I just referred to which was that Oracle 11/Oracle 12 upgrade. They used our software to achieve all three goals, all three use cases. They were able to migrate some of their applications to run in AWS. That was a re-hosting scenario. The second case was to take the Oracle applications that they were running in their primary data center and protect them, meaning for cloud-based recovery in AWS, and the third was also related to the 11-12 upgrade, cloning DevTest, and they were able to achieve that goal as well.
We’ve seen customers in manufacturing who are very focused on cost savings and being able to do more with less because they operate in a very global and competitive environment, as well as tech companies who want to take advantage of the cloud, media companies in a similar way, government agencies and retail and pharmaceutical. These are the verticals where the notion of cloud migration and cloud recovery is gaining a lot of adoption.
I want explore your One Hybrid Cloud platform, specifically two key aspects that I think people would be really interested in. One is security and the other is manageability.
We focus on three aspects in trying to make this easy for enterprises. First and foremost is we’ve built a solution that we call “enterprise grade,” meaning the product is built to support a broad range of infrastructure, meaning Windows applications, Linux applications, different types of storage, supporting Oracle, MySQL, SQL Server. Second, we built in a great deal of security capabilities. For example, data from the source environment is encrypted when it’s being transferred to the cloud. We also do data compression as we move the data and the application and the workloads to the cloud. Data is also encrypted when it is stored in the cloud. Also, we use very few open ports, for example, to communicate with the data center and the cloud itself.
Finally, when we actually look at the workload running in the data center, we use a unique technique called applications blueprinting and that’s one of our core intellectual properties, our core capabilities. We can identify the characteristics of the infrastructure that the workload is using. We can identify what type of storage and storage volumes are being used, we can identify the networking characteristics – the subnets, the IP addresses. We can characterize the security ports that are open or closed in this environment and we can do that both for physical and virtual servers or VMs.
More importantly, using this metadata, using this application blueprint that is very specific to your infrastructure, to your application, to your data center, we can now match that with the appropriate services on the cloud side. What’s the right compute, what’s the right storage, what’s the right networking capability and design and what are the right security groups on the cloud side? We completely automate this and that is really what makes it very simple. We provide drag and drop automation. We provide that simplicity of that user experience and the automation to actually help customers take advantage of moving their brownfield applications into the cloud. The application blueprint also allows us to do optimization.
Before I’m going to move that workload to the cloud, I will try to right-size what’s in my storage environment to an appropriate matching instance or matching service on the cloud side. We can basically help customers optimize before you move. One of the things that’s coming on our product roadmap is continuous optimization. Once that workload has been moved into the cloud, we will continuously monitor it and provide optimization insights and automation whereby you can reduce your cost, increase your performance, reduce your risk.
Are there tools to help customers determine what their costs will be when they move these apps into the cloud?
Yes, exactly. Once we’ve done the application blueprint, then on the management portal we provide a variety of policies and those policies can help customers do what-if scenarios in real time. If I’m optimizing my CPU and memory, then this is what my cost is going to be. It will tell you it’s going to cost you 30 cents per hour to move this workload into the cloud depending on the actual instance that we match. You can say: I want to use high-performance storage. As you select that, on the screen we will in real time show what the costs are for that service on the AWS side and give you a what-if scenario.
What is the competitive landscape for you? Who is out there promising to do similar things?
There are companies that focus on greenfield applications and cloud management and there are a few that are focused on brownfield applications. When it comes to brownfield applications, there are two types of approaches. There are companies that are basically doing what I call image conversion. I have my application running on my server or in my VM and I’m going to basically shut that down. I’m going to use an image conversion utility or software and I’m going to make it compatible with the format required by, let’s say, AWS called AMI {Amazon Machine Image}. Then I’m going to do all the setup and configurations for that AMI to run in AWS, which means attach to the right storage, provide the network parameters and do all the security stuff. All of that is relatively manual.
You’ve got to shut things down and you’ve got to move it over. The data may not move as a part of this migration, it’s just maybe moving the application. The data might need to be moved separately and then bringing it up requires further work. Those are the image conversion types of approaches and there are people who were doing this for data center to data center. They just adapted that tool for the cloud. We’re not doing server-to-server migration; we’re doing a holistic application migration. That’s where we automate all those aspects that I talked about.
First, you don’t need to shut down your VM. Zero downtime. Second, we learn and blueprint the application. Third, we then automate the provisioning and the orchestration of the right resources on the cloud side. Fourth, we then are able to start the replication continuously. It’s called live migration. You don’t need to shut anything down. Fifth, once that replication and synchronization is complete – we’ve completed all aspects, the application, the operating system, the database, the data itself – then the validation is going to be much easier rather than having done it in a piecemeal approach.
What should people expect from CloudVelox over the next year?
A few years ago enterprises were asking whether the cloud was enterprise-ready. The cloud providers like Amazon, Azure and others have moved quickly to introduce a lot of capabilities around performance, scale, supporting different types of applications and infrastructure that secured their clouds. Now enterprises are asking: Are we cloud-ready? The cloud is enterprise-ready but are we cloud-ready?
We’re helping quite a lot of customers better understand where their current applications and workloads are, helping them understand what their options are and how they can actually migrate and protect their applications in the cloud. There is a third set of customers that are in the ready, set, go cloud phase with maybe 15% to 20% of their [brownfield] applications already running in the cloud. They’re looking at migrating another 20% to 40% over the next, let’s say, three or four years. This market is moving rapidly from “is the cloud enterprise-ready,” to “is my enterprise ready to start running a lot more stuff in the cloud” and we’re helping customers with that.
Also, more and more customers will be operating in a multi-cloud world, meaning I’m going to, based on policy, run some applications in my own data center, some applications in AWS and another set of workloads in another cloud. Let’s say it’s Azure. Maybe it’s Google Cloud. How can I operate in a multi-cloud world? We will help enterprises place and move that workload because there are no tools available for that. Most cloud providers are not focused on helping you move workloads away from their cloud. They want to help you get your workload into the cloud.
You’ve heard that Hotel California song, you can check out but you cannot leave. Enterprises are worried about cloud provider lock-in. We’re enabling that freedom of cloud for those enterprises. The second part that enterprises can expect over the next six to 18 months is around cloud optimization. Each cloud is different. Each cloud has its own set of native services. Azure has its native services. AWS offers its own types of managed database services. Rather than just running my applications as-is in the cloud, can I take advantage of cloud-native services? That’s where our vision, our strategy and our approach around cloud optimization comes in. We’re going to help enterprises really optimize their workloads for the specific cloud they’re running on but at the same time still provide an ability for them to have mobility between clouds.
