Business culture is key in OpenStack network requirements

While open source tools tout flexibility and customization capabilities, these tools -- including OpenStack -- aren't suited to all businesses.

OpenStack network requirements greatly revolve around an organization's culture and how it supports its network infrastructure. Vendor-driven organizations are less likely to gain OpenStack benefits than organizations that have more flexibility in how they choose tools, according to author V.K. Cody Bumgardner. For some network engineers, OpenStack network requirements would mean giving up some control over the infrastructure and handing over control to other people, such as developers and end users.

In his book OpenStack in Action, Bumgardner discusses OpenStack network requirements and best practices for network teams as they walk through OpenStack network deployments.

Editor's note: The following interview was edited for length and clarity.

Why would enterprises adopt OpenStack over other IaaS options?

V.K. Cody Bumgardner

V.K. Cody Bumgardner: It's a strategic choice. It wouldn't be good for every place -- for instance, hospitals are very vendor-driven. They want everything within a vendor stack and [to] have somebody vertically control every point of integration.

For others, it gives you a choice to make architectural decisions. You don't have to reinvent the wheel. If you want to use a specific type of best-of-breed network, you can. If you want to use software in the machines, you can. If you can be flexible and have the talent to take advantage of best-of-breed systems, then OpenStack can be a good choice.

If that isn't your culture and you have this almost prescribed infrastructure, then OpenStack probably is not a good choice. Companies that provide commercial support may be a middle ground, but the options fall into two camps.

The benefit is you have a standard way to use APIs to control infrastructure. It's more flexible in the way you choose how to do deployments and the underlying infrastructure you choose to manage.

What OpenStack network requirements should organizations know?

Click here to learn more about
this book. Enter code 'TechTarget40'
at checkout, and receive a 40%
discount on this title.

Bumgardner: The main question is: What is your culture? Do you go to a vendor and say, 'Give me your design, tell me what to buy and how to support it'? Starting out, you evaluate systems. What are your options?

If you have siloed folks that work on a particular model of equipment, then OpenStack is probably not for you. If you have people that function at a higher level with some fundamental understanding about the underlying architecture that makes things work, then OpenStack can be very useful for you, and you're much less restricted.

When you make the change to OpenStack, it allows end users or developers to make decisions for themselves on a machine level. If something I build should have a static address, I can request and automatically receive static addressing. Or, if I want to create a networking hierarchy within my tenant, I can do that.

In a normal enterprise system, you would talk to a dozen different people and go through different approvals where, from an OpenStack perspective, you can build your own world inside the tenant. At least internally, network control is up to you because you can create that hierarchy.

One example is load balancing applications. You can't do geographic load balancing within one OpenStack cluster, but you can do local load balancing. The load balancer can be the only thing exposed from your tenant. Then, you can have a three-tiered architecture deployed within your tenant that itself is diverse within the OpenStack system. That means architects can control that. Even in a development environment, you're giving control of design and architecture deployments to people that typically know what they want to do from an application perspective.

How can network and development teams work together to make the most of an OpenStack network deployment?

Bumgardner: One thing that lets you work together from the network, development and storage sides is the ability to look at the same infrastructure to see how it's configured.

If you can effectively deploy OpenStack anywhere, it gives you vendor and technology neutrality.

Somebody with networking experience can create exotic configurations for network functions virtualization or load balancers without compromising broader functionality and policy. In an enterprise space, the network people would have one or several big load balancers and a certain deployment policy, which developers have to conform to. Having functions virtualized and pushed into tenants means network people can work more closely with application folks to create custom services for network functions, load balancing, etc.

You get the benefits of standard tools, but the failure domain is limited to a particular project and the network infrastructure can be tailored to a particular tenant or application rather than trying to deploy things centrally.

What benefits and challenges do OpenStack network requirements bring to organizations?

Bumgardner: If you can effectively deploy OpenStack anywhere, it gives you vendor and technology neutrality. You'll always have some form of storage, compute and networking, but if any components are up for grabs, in terms of vendors or how things connect, you can change the underlying physical infrastructure.

From a management and a monitoring perspective, the way you deploy resources, monitor what's going on, and provide authentication and authorization will be the same. You don't need to be technically aligned to get advantages of OpenStack, but you need to be culturally aligned and have the right people.

If your culture understands how things work on a low level, and you have the technical chops to understand how things work and make them work, then OpenStack can be fantastic. You can safely push changes to individual users without spending all your time trying to provision things for people.

However, if your culture means you have a problem, you call your vendor and have them do everything for you, then OpenStack may not be the best. You could get support, but if your organization doesn't have people that understand the relationship between compute, storage and networking, it may be difficult to take advantage of. If you don't understand how these things work or go together, then it's going to be hard to support.