Ravello’s – Smart Labs Cloud Agnostic

From the perspective of cloud migration, two main types of cloud application exist; Cloud-Centric & Cloud-Ready. Cloud-centric applications are “born for the cloud“, built as greenfield cloud application stacks, meeting all cloud requirements. On the other hand, cloud-ready applications must be redesigned or changed in a way that they can fit the cloud structure. Cloud-centric applications are often built with different tools and runtimes than traditional applications. For example, a cloud-centric application may replace a relational database with a NoSQL database, like Cloudant or MongoDB.

Public cloud is a great platform for developing cloud-centric greenfield applications. Unfortunately, it’s not an ideal place to develop custom application stacks using a variety of customized network infrastructure, especially if it has complicated high availability requirements. If you were to re-design your application to meet all the cloud-ready rules you would never move anything to the cloud. Cloud-ready rules are easier to incorporate into cloud-centric applications. But if you are migrating applications onto a cloud environment for the first time, things can get more complicated. Modifying application structures to make them cloud-ready can be difficult and NETWORKING is usually the first stumbling block.


No Layer 2 in the Public Cloud

It’s difficult to add custom applications to public clouds as it does not support clean layer 2 environments. Broadcast and multicast frames are filtered, VLANs, Gratuitous ARP’s are largely unsupported. High availability, auto-discover and clustering solutions that rely on multicast and broadcast do not work in the public cloud. For example, in Microsoft Azure public cloud, the high availability function for F5 BIG-IP products only work in conjunction with Azure Traffic Manager. There is an inherent lack of probable control over networking and this lack of control is a limiting factor for the migration of complex application stacks. The solution is a technology that allows migration of workloads to any cloud provider without making any changes to the stack.


Ravello’s  – Public Cloud Agnostic

Ravello aims to make the public cloud easy to consume on-demand. They want enterprise to replicate all on-premise infrastructure to the cloud, without making any changes to internal application structure and its infrastructure. It operates by snapping a blueprint of what you have on-premise and then copying that “file” to Ravello’s cloud network, which lies on Amazon and Google (no support for Azure yet). For example, you may have a 3-tier application stack load balanced with Netscalers and secured by Fortinet’s and Paolo Alto. Each tier has its own clustering requirement with non-routable packets. Ravello’s technology allows you to take a blueprint of the tiers and supporting infrastructure and replicate it exactly to their cloud. Their solution gives enterprise data centre applications a way to benefit from the elastic and agile cloud benefits without making changes to the application. How does all this work?





Overlay Tunnels & Nested Hypervisors

Ravello is a Software as as service (SaaS) cloud services provider; a cloud that sits on top of other clouds. Ravello utilize existing public clouds to seed their own cloud by deploying a cloud to a cloud. Their ability to provide a clean layer 2 environment comes from the construction of point-to-point overlays using User Datagram Protocol (UDP) as the transport. Ravello is powered by a new HVX nested hypervisor and Software Defined Networking (SDN). It’s distributed hypervisor combines software-defined overlay networking and a nested virtualization engine. The nested hypervisor approach allows customers to bring their own network elements (e.g. Juniper or Cisco router, F5 or NetScaler load balancer and various firewall appliances ) to implement a chosen network function and topology.

Ravello implements a full overlay solution that exposes a clean Layer 2 networking to the guest. Now, you can use any type of networking feature; multicast, broadcast, VLAN, VMAC, GARP, and span ports, giving access to all functionality originally available with on-premise data centers. It’s a similar analogy to buying Virtual Private LAN Service (VPLS) from a managed Service Provider. With VPLS, you can design any type of topology. By default, public clouds are not network ready and have limited complex topology support, mainly due to the lack of Layer 2. With Ravello, you can have full layer 2 and layer 3 flexibility in Amazon and Google’s public cloud.

Their network overlay consists of a data plane and control plane element. The control plane consists of a distributed Layer 3 router and other DNS / DHCP features. Data plane is a fully distributed virtual switch and virtual router. With any overlay network, you get layer 2 frame, encapsulate it and send to the other side. Traffic between host is tunneled / encapsulated and invisible to the cloud. The tunneling method allows you to build whatever topology you want. You can even use the same on-premise IP and MAC addresses.




The first step is to export VM from Vmware/KVM to Ravello networks. They have a tool that connects directly to vCenter so you can suck information automatically. No changes made and it’s a simple drag and drop process. Conceptually, they extract the application environment, recreate the environment in their SaaS cloud and then start VM in the new environment. Ravello parse the metadata from the virtual machines and automatically construct the network and infrastructure. The application thinks it’s running in its own native environment, but it’s actually running in Ravello’s environment that is running on top of either Amazon or Google.







About Matt Conran

Matt Conran has created 184 entries.

Leave a Reply