Mark Voelker is no stranger to the OpenStack community. As a technical leader at Cisco and a co-founder of the Triangle OpenStack Meetup, Mark gets to see OpenStack from a lot of different lenses.
In this interview about his work at Cisco and his upcoming All Things Open talk, Mark shares his thoughts on where OpenStack is and where it's heading as topics like Big Data and Network Function Virtualization (NFV) continue to emerge in the OpenStack roadmaps for many companies.
Want to learn more about OpenStack? Check out the Opensource.com resource page here, and be sure to attend Mark's talk at All Things Open, OpenStack - Everything you need to know to get started.
Tell us a little about yourself. What do you do with OpenStack at Cisco?
I'm currently a Technical Leader in the Cloud and Virtualization Group's Platform Team. I like to think of us as a group of breadth-first technologists that are looking at technical issues across the spectrum of what's necessary to build and operate an OpenStack-powered cloud. That means I'm very hands-on with OpenStack itself, but I also work with a number of associated technologies and architectural concerns. DevOps, for example, is a big part of my workday (I'm also a core developer in the Puppet StackForge community).
I spend time working with continuous integration and deployment technology, configuration management, monitoring, debugging Python code, packaging, and the software and hardware architecture that makes all that work. It's a really fun role because I get to touch so many different aspects of what goes in to a cloud. I also get the freedom (and support) to work on community initiatives, like the Triangle OpenStack Meetup here in the Research Triangle Park area, which I cofounded.
Without giving too much away, tell us a little bit about your upcoming talk at All Things Open. What can attendees expect to learn?
OpenStack recently celebrated it's fourth birthday. A few years ago I was spending a lot of time explaining to people what OpenStack is at a very basic level. Nowadays, we're way past that: there are dozens of good "OpenStack 101" talks out there, and almost everyone who hasn't been living under a rock knows something about it.
What a lot of folks don't have a good handle on, though, is what it actually takes to make a cloud deployment successful where the rubber meets the road. There's software you need to think about besides OpenStack itself. There are architectural decisions to be made. There are operational strategies and tools you'll need to run your cloud once it's online. You need to think about how to build a cloud that you can actually operate and maintain over time.
My talk at All Things Open aims to address some of these areas and share some of my experiences in successful and not-so-successful deployments. The end goal is to get people zeroed in on what makes a cloud deployment smoother.
The OpenStack community has made a conscious effort in the past several months and at the last Summit to focus on the user community. Do you think this effort has helped make OpenStack easier for newcomers?
Absolutely, and I think we're moving toward doing an even better job. I've spoken with core devs and PTL's who came away from user-oriented sessions at the past couple of summits with "lightbulb" moments about operator concerns, as well as operators discovering new things from developers. I've seen a lot of focus put on end-user concerns over the past development cycle as well. Boring concerns like operability, stability, and upgradeability have been getting a lot of attention. Operator meetups like the one I recently attended in San Antonio or at the last Design Summit in Atlanta have given operators a forum for collaborating among themselves as well (and by the way, we're doing it again in Paris).
We've seen a lot of excitement and interest around OpenStack as a tool in providing Software Defined Networking and Network Function Virtualization solutions. How is OpenStack adapting to meet these needs, and how is Cisco's work in OpenStack facilitating this?
At it's very core, part of OpenStack's job is to abstract underlying infrastructure and make it API-addressable and horizontally scalable. You're issuing API calls to OpenStack's control plane and are letting OpenStack in turn drive the realization of what you asked for in the physical world. That means it lends itself very well to SDN solutions and does so in a way that lets organizations choose the pace at which they consume technologies like Software Defined Network (SDN), controller-based or overlay-based, and Network Function Virtualization (NFV). For example: with Neutron you can start today with an OpenStack cloud that's backstopped by technologies you're familiar with, such as VLANs (virtual) for network segmentation. You can then move to more scalable overlay technologies like VXLAN (virtual extensible) without end consumers of the API really knowing about it—in fact, with ML2 (now the defacto default plugin for Neutron) you can combine different mechanism and type drivers on the backend. You can even deploy an SDN controller technology like OpenDaylight without modifying the interface that applications have in to the infrastructure.
More recently, we're seeing another really cool development on this front: a policy layer. For example, the Group Based Policy work happening in Neutron and the Congress project provide end users with a different way to think about declaring the state of their infrastructure, essentially providing a new set of logical primitives which can be driven by a controller technology. Once you're delegating a lot of the decision making in your network to an SDN controller, policy-based declaration of your infrastructure becomes a very digestable next logical step. That parlays itself nicely into SDN solutions that can be policy-driven (Cisco's Application Centric Infrastructure being one example). That's partly why we're involved not just with the Group Based Policy work in Neutron, but also with corresponding work in open SDN communities like OpenDaylight and open standards work like OpFlex.
A lot of the same tenants hold true in the NFV world: NFV is partly about virtualizing and then horizontally scaling network functionality that used to be purely physical and scaled vertically. Having an API-able infrastructure gives you elasticity, and abstractions give you freedom of a common interface to many different underlying providers. As NFV has really started to come of age in OpenStack lately, we've seen more emphasis on some of the things that are important to NFV use cases. For example: Neutron now has a NFV subteam for folks collaborating on NFV use cases, there's been a lot of work SRIOV lately to increase performance for applications like load balancing, we've seen projects like Octavia spin up, and we've seen the launch of complimentary projects like the Linux Foundation's new OPNFV (Open Platform for NFV) initiative. Not only is Cisco making contributions that help make OpenStack better for NFV and building products that provide the underpinning, we're also putting an emphasis on building platform with the community: that's why we're also involved with OPNFV, and in the next few weeks we're hosting a Google Hangout with members of the community to talk about NFV in OpenStack.
We're just a few weeks away from the Juno release, and some work is already being done to plan for Kilo. What are you excited for on the horizon with OpenStack?
It's super exciting to see OpenStack being used "under the hood" of all kinds of applications and the use cases that are shaking out as OpenStack's userbase continues to grow. NFV is sort of the obvious example here, but we're also seeing things like mobility applications, video applications, some neat stuff in Big Data, and federation. As a networking geek, I'm excited to see the initial launch of the distributed virtual router functionality in Neutron and improved support for IPv6. The continued multipronged work on policy driven infrastructure also has my attention. As someone who spends a lot of time with operators, I'm also excited to see continued focus on operability, availability, and upgradability. For example, a good deal of work has been done to provide high availability for the Neutron L3 agent.
Why does open source matter to you? How do you think it has helped OpenStack to succeed?
I see open source as a terrific avenue for collaborating on the platform for real-world applications. Nobody runs a cloud just for the fun of it (well, other than geeks like me who have too much server hardware at their disposal). They do it because it's the best way for them to provide some higher-level application or service on which they can differentiate or solve a technology problem. I think that's partly why an open approach to cloud works so well for OpenStack: you're actually seeing companies that compete heavily with each other collaborate to build a platform on which they can compete with each other. They're solving the common problems together so they can focus on what really sets them apart. And the same is true for people deploying OpenStack: as an open platform they're free to help shape it's future without having to do it all themselves, which allows them to focus more time and energy on the use case they're deploying it for. Really great open source communities are the ones where those types of people start working together with the rest of the community to build a better platform for everyone even when the problems they're tackling are tough. If you look at the tremendous growth in the OpenStack community over the past four years, you can really see how it has fostered an "espirit de corps" among a very large and diverse set of companies and individuals.
Open source in a very real sense is also what drives standards today. There was a time when technologies were largely defined by standards bodies where generating agreement on definition was a long, tedious process. Those certainly still have a part to play, but today we're moving much, much faster as organizations are increasingly defining "standards of consensus" by actively collaborating on concrete implementations: code you can actually pick up and use or reference rather than a definition document that you have to develop a solution to against on your own.
Is there anything else you'd like to add?
You asked about NFV earlier, and that's a really hot topic right now. Cisco is going be hosting a Google Hangout later this month with some folks from the NFV scene within OpenStack community. Keep an eye on our blog for details and tune in to ask questions or find out what all the buzz is about!
See the full series of All Things Open 2014 speaker interviews.
Comments are closed.