How RightScale Supports Virtual Networking Across Clouds

You’ve reached an archived Flexera blog post that may be out of date. Please visit the blog homepage for the most current posts.

Anyone who has ever tried to connect one computer to another knows that networking is complex. That network complexity can be exacerbated by the cloud – but RightScale cloud management can help you harness cloud providers’ networking capabilities and abstract away the complexities. This is especially true today, as we formally announce Network Manager, which provides abstraction of network constructs across clouds, provides for portability of applications defined with these constructs, and enhances organizations’ ability to secure cloud networks. Network Manager provides both a user interface and an API to manage networks across public and private clouds. With it you can audit histories to track changes in network configurations and visualize security configurations with a tool called Network Map. Watch our Network Manager video for an introduction and demonstration.

Why We Abstract Network Constructs

Every cloud provider builds into its platform the settings and designs that it thinks its customers will want to use. Because all the networking resources are different from one cloud provider to another — as are the names and behaviors of the resources and the APIs through which they are delivered — it can be difficult to get started quickly. Private cloud platforms may also differ depending on how they are deployed — you can configure OpenStack or CloudStack, for instance, in many different ways at installation time. In addition, providers change APIs and introduce new resources all the time.

Sounds like a headache? Yes, but having a wide variety of options also means that you can choose the cloud infrastructure that best suits the needs of your business and your applications. And rather than learn how to manage each feature from each cloud provider at the API level, you can turn to RightScale to abstract that functionality.

Three Cloud Providers, Many Differences

I’ll refer to the networking features of three cloud providers – Amazon Web Services (AWS) Elastic Compute Cloud (EC2), Google Compute Engine (GCE), and CloudStack – to show how cloud computing architecture implementations can differ. You can see these graphically represented in the video of a talk I gave at RightScale Compute and in the slides of the presentation.

Josep Blanquer’s session on Virtual Networking in the Cloud at RightScale Compute

In the current release of AWS EC2, each region can have multiple virtual private clouds (VPC). In a VPC, everything within the perimeter is your network, and to get at resources outside of it, you have to go through gateways (even though from an instance point of view you might not know or see that happening).

Within each VPC you can create subnets, and each subnet has Elastic Network Interfaces (ENI) – reusable virtual network interfaces. A subnet is scoped to a single AWS Availability Zone (AZ). VPCs also contain security groups (which you can attach to instances), routing tables, and network ACLs (which filter traffic across subnets).

With these features, you can launch an instance and connect it to multiple subnets that are in the same Availability Zone as the instance. Security groups are bound to individual ENIs and not to an instance as a whole.

An older AWS EC2 release, EC2-Classic, offers a single implicit network for each region. All communication in and out goes through network address translation (NAT). There are no subnets, routing tables, or network ACLs, and security groups are scoped to the implicit single network.

By contrast, the GCE cloud is global – from an API perspective, there are no regions. Within that cloud GCE offers what it calls networks, which are somewhat equivalent to AWS’ VPCs. Each network has an isolation perimeter and gateways for external traffic. Networks cannot be further segmented – there are no subnets, and instead of exposing routing tables, there is only a single collection of routes for the whole network. In this model, each route is associated with a set of tags as a way to both virtually group routes into logical routing tables as well as to identify which instances these should applied to.

GCE has something called firewalls that are somewhat similar to both security groups and network ACLs. Consistent with how routes are defined, you can associate firewall rules with tags, and every instance that has a particular tag gets the same rules.

Finally, unlike AWS EC2 and GCE, CloudStack is designed for private clouds, and has a lot of settings you can tweak at installation time, such as enabling multiple networking modes. Basic mode, modeled after EC2-Classic, provides one shared network per zone. There are no subnets or network ACLs. There are security groups, though they are not bound to zones, but rather to an entire domain.

In Advanced mode, you can have multiple networks, each scoped to a zone. Instead of security groups, you can implement rule-based firewalls. The newest option is Advanced mode with VPCs, in which each VPC can have subnets, which CloudStack calls Tiers. (Though they share a name with AWS’ VPCs, the two implementations are not the same.) Here, the network interfaces are not exposed in the API, but this mode does have some support for static routing.

These examples illustrate the diversity of approaches that cloud providers take. The varied concepts and terminology of the different implementations makes virtual networking in the cloud a complex proposition.

The RightScale Cloud Network Model

Fortunately, RightScale can help make sense of the chaos. We have defined networking resources that abstract the basic cloud concepts, such as networks, subnets, and security groups, so organizations can work with these entities across cloud providers consistently and without having to attend to details that are not important to them.

From a RightScale perspective, a cloud can have multiple networks, which are equivalent to VPCs for Amazon Clouds. Networks have subnets, and each subnet is usually bound to a data center (which is an abstraction of an Availability Zone in AWS parlance). In some clouds, however, such as GCE, networks as well as subnets are allowed to span data centers. Subnets have network interfaces that can be plugged into instances at runtime. Security groups are related to individual network interfaces rather than to the subnets. We also expose IP addresses as a combined resource that allows the definition of port ranges. In the next release we will also expose network gateways. Routing tables, network firewalls, and ACLs will follow.

And of course in addition to the networking features, RightScale abstractions also include a large array of compute and storage resources such as instances, data centers, and volumes, as well as images and volume snapshots. All of these features are accessible both through our API and Network Manager.

Balancing Abstraction and Cloud-Specific Features

The multi-cloud abstractions exposed in the RightScale API raise interesting questions. For example, how can organizations manage resources for their clouds if a particular provider’s cloud does not support them, as is the case with AWS EC2-Classic’s not supporting subnets? And how can organizations break the generic API structure and tap into specific options that are only supported by some cloud providers? For example, AWS is the only provider that enables organizations to create disks or instances with provisioned IOps.

To answer these questions, you must understand two important tenets of the RightScale API design: the ability to consistently manage resources across disparate cloud environments through a single pane of glass, and the option to customize cloud resources to take advantage of provider-specific features.

The RightScale API provides unified resource naming and structure for all your cloud resources. As a user, you always interact with the same structure of abstractions and the same semantics across all of your clouds. For example, you know that you’ll be able to traverse your networks, get to your subnets, and manage your routing tables using the same API resources and operations, regardless of the underlying cloud. RightScale takes care of mapping these to the appropriate underlying cloud abstractions, or creating synthetic ones when appropriate. For example, in your AWS EC2-Classic clouds you will see a synthetic subnet for each availability zone, and in GCE you’ll see a synthetic subnet for every network in your project. This way, you can automate your cloud infrastructure using code that correctly maps to different cloud infrastructures, and let RightScale worry about maintaining the mappings every time an underlying cloud API changes.

The RightScale API also allows you to tap into cloud-specific parameters whenever you desire. Beyond the unified resource API structure, you can still utilize cloud-specific parameters when managing the individual resources because RightScale passes any parameters that are not generic directly through the cloud provider without applying any translations. So, for example, you can create a volume for any cloud that includes the number of provisioned IOps you want to reserve — an operation that would only successfully complete if the cloud were EC2. The same parameter passing applies when you create specific DHCP options for a network, such as specifying a NetBIOS node type, which would only work for AWS networks.

RightScale cloud management enables you to manage the networking offerings of multiple providers from a single pane of glass using high-level abstractions while preserving your ability to access cloud-specific capabilities. I invite you to try RightScale for free, and see for yourself how it can help you more efficiently manage your cloud infrastructure.