SSilver - Fotolia
I've been a keen observer (from the peanut gallery) of the OpenStack crew while they navigate a path to support multiple container approaches. The Docker driver for OpenStack Nova Compute shows promise, especially by providing a REST API to mostly heal borked application network configurations after deployment scripts go rogue. But with the release of the OpenStack Community App Catalog, network administrators sitting on the SDN sidelines now have a new tool to kick-start their learning in the best way possible for engineers -- by doing. OpenStack Heat is the open source initiative's primary cloud orchestration project, using software-defined networking (SDN) technology to launch and manage template-based applications.
OpenStack configuration tools are not full SDN, in that they're not designed to configure bare-metal hardware in support of all OpenStack elements. There's still a long way to go to get there and lots of competing solutions. But OpenStack Heat templates provide common configuration for container-deployed applications, including application networks. They're real configuration artifacts you can take apart, examine, set up in a sandbox and experiment with.
One ongoing criticism of OpenStack has been inadequate documentation, especially for OpenStack Networking (Neutron). It hasn't always been easy to find good how-to instructions or spell books to guide learning. But with the catalog, SDN students have access to complete configurations that have undergone comprehensive functionality testing at least once, eliminating some of the Franken-configs we've started from before.
Heat uses YAML to launch application infrastructure
One familiar aspect of discovery through disassembly for OpenStack Heat is that it's still configuration-based -- text files in YAML (a data serialization standard for all programming languages that can be read and written by humans). When fed to OpenStack services, YAML launches or modifies application infrastructure. First, this forces abstraction between the final configured state of the environment and the configuration, the most important first step to SDN.
However painful it may be, make this your mantra: "Let go of real-time command line." Second, the config templates will introduce you to many concepts that cloud providers have relied on for years, such as SDN subnets, gateways, interfaces and services like SSH.
To be clear, you'll be experimenting with OpenStack's particular flavor of SDN and cloud orchestration. Elements like OS::Neutron::Router and OS::Neutron::Subnet may just be a stepping stone to SDN configuration on another platform. However, you can set up OpenStack on a single box for free and start downloading templates from the catalog site. And if anyone has sprinkled an install of OpenDayLight or the Cisco Nexus 1000V over half a dozen machines, you'll appreciate OpenStack's more thrifty resource requirements.
Full OpenStack SDN: Not there yet
Before you can get OpenStack purring away and logically defining service networks for container-deployed applications, there's one problem: You'll still need to manually configure the network platform hosting it. The host, physical switches, routers and so on are configured the same way they've always been; the same way they are with VMware; the same way they are with the feathered fringes of Cisco's Unified Computing System command line. And this is where SDN still falls down.
OpenStack isn't magical; it still requires an agent running on a machine. Even CoreOS, which I've commented about favorably before, may be a cleaner approach to container management, but it also installs on something. (I've even seen CoreOS on OpenStack, which seems a bit crazy to me, but to each his own.) But what these don't offer yet is downloadable templates and controllers that can do the pre-config and charm the physical platform in one step.
OpenStack Murano bundles several related applications for ease of deployment. For example, the Docker & Kubernetes bundle aggregates Docker hosts, Pods and containers, including some host network consolidation. But still elusive for SDN is standardization of host infrastructure, or at least a selection of common choose-your-own-adventure subtypes. At least a few one-size-fits-many configurations would help accelerate adoption. Platform vendors in particular have an opportunity to stand out in catalogs and move products with a little more investment in common projects.
Template deployment: Devil in the details
Regardless of which platform you choose, you'll still have to complete a few tasks by hand besides the initial configuration. Just like with Amazon Web Services, you can't simply push a downloaded Heat or Murano template to the OpenStack agent and expect it to pass packets. You'll have to spend some time in the console, gather Universal Unique Identifiers for networks and security groups, and edit your deployment YAML with the specifics of your rig.
But with a bit of experimentation, you'll find that bundling apps, dependent services and performance monitoring to make sure you're meeting service-level agreements is surprisingly straightforward. And template-driven deployment, OpenStack Heat or otherwise, goes a long way toward solving administrators' ever-present challenge: Ensuring apps are wired correctly. (VMotion-busted ESX vSwitch access control lists, anyone?) With template-driven networking, we can finally switch our thinking, at least in part, to resource queues that pass packets, not media and connectors.
In the meantime, when we see notes like, "The Heat team is working on providing even better integration between infrastructure and software," we'll read between the lines and expect to still manage some config outside of SDN. And when we get to where one-size-fits-most metal, then OpenStack SDN will be ready for the mainstream enterprise.
How OpenStack Neutron could influence the future of networking as a service
Neutron, OpenStack's answer to networking has its issues