OpenStack is quickly becoming the de-facto standard in cloud infrastructure software. There's no doubt that, in the past few years, OpenStack has quickly grown in both acceptance and footprint. Many companies worldwide are relying on OpenStack to run their most critical business applications and the list keeps growing.
Unfortunately, those same companies are challenged on a regular basis to hire talent who are familiar, or better yet, experts in the technology. The real problem at hand today is a lack of training and expertise to be able to qualify someone as an OpenStack professional. This is exactly the void that last weeks announcement of the Certified OpenStack Administrator certification is supposed to fill - only one problem, the focus of the exam content does not qualify someone as an OpenStack administrator.
I've been a contributor to the process for a majority of this year, having participated in building out a list of tasks that administrators generally perform (along with participants from nearly a dozen other companies who participate in the community). The foundation sent it out in the form a survey, which I hope many of you got and answered, and then used those survey results to create a list of tasks that an OpenStack administrator would perform, such as:
Launch an instance
Create a block storage volume
Mount a block storage volume to a compute instance
Generate and upload a SSH key
Login to Horizon
For a full listing see: https://docs.google.com/spreadsheets/d/1Q9hmsbjCY959clDMzxpWXdV15GWGjiEr1QNpQoQfjf4/edit?usp=sharing - The color coding indicates that green tasks are critical, yellow tasks are questionable, red tasks are out.
For those of you familiar with OpenStack administration, I hope you see a trend here and can spot the grave error. All of those tasks are what users of an OpenStack cloud do on a regular basis. Administrators have a much different daily task list, and a majority of them are not remotely reflected here. The content being tested is not related to the job of an administrator at all, but rather focuses on the skills necessary for a user or consumer to login and use an OpenStack cloud.
To make matters worse, I'm supposed to be participating in a panel of experts. One 'expert' said they could only work on one of the 13 domains, because that was the extent of their experience in OpenStack. Another expert took it upon himself to write 40% of the exam questions when there are 12 participants. It's just a big popularity contest, with the image of participating for their companies being worth more to some than the quality of the final product.
All in all, I believe the Foundation's efforts to develop a credible certification for OpenStack administrators is failing because the process is completely flawed. The process is very far along, yet the product we have come up with is not something I'm proud of at all. The fact that other participants are not alarmed is also alarming. One said participant built the largest training program for OpenStack on the planet today. Another is a colleague who I co-authored a book with. Do they not see that the task list is this much off base?
Last week there was talk of revising the test every 3 years. I was the only person on the call aware of the fact that code from 3 years ago isn't even available for download. Really? The only one?
My advice is, if you're holding out for a credible OpenStack certification, look to the training marketplace and talk to companies like Mirantis, Aptira, RedHat and many others who have built a strong reputation in OpenStack training already. They are able to closely control the quality of their products, thus their offerings are more likely to be inline with what your company wants to quantify knowledge around - OpenStack Administration skills.
I continue to participate in the development of the COA exam with hope that the effort can be turned around. A 3 year refresh, testing on content that you can't download anymore and focusing on questions that are so rudimentary that, at best, the exam is a user certification is not going to cut it.
Monday, November 9, 2015
Thursday, June 4, 2015
OPNFV: Arno Release and a Long Road Ahead
There is a huge buzz around the industry today around the first release of OPNFV, the Open Platform for Network Virtualization, code-named Arno.
Since the ETSI NVF-ISG definitions came out last December, there has been a mad dash across the board toward delivering the next Unicorn of network service providers. With companies like AT&T publicly committing to the Domain 2.0 effort, which commits to 5% of their network being virtualized this year, there is little doubt that there's a strong push toward software defined networks (SDN) and the ability to provide virtual network fundtions (VNFs) on top of a network function virtualization (NFV) platform.
While attending the OpenStack Summit in Vancouver last month, there was a strong showing from all of the players in this space which did two things in my eyes. First, it validated OpenStack - not just as a platform for web companies to move their transitional workloads, but as a platform which companies who provide mission critical services are looking at seriously for running the most relied upon services in the world. Second, it confirmed that a number of massive companies have a strong commitment, both to OpenStack and to OPNFV.
While all of this sounds great, the first release of OPNFV has me concerned that there is more expectation than reality in this release. I feel like there are a number of ways in which the project can improve, and their start really has me wondering if there will be a long term need for what they are doing. Here's a breakdown of what I've seen as problems so far:
First, OPNFV chose to start with a CI/CD system, which is a great start, but there's a fundamental flaw in that they have chosen to work with ISO builds of third party vendor distributions - specifically using Fuel and Foreman. I feel like there's a fundamental flaw in this decision to use specific vendor releases and not integrate with the OpenStack CI systems. Whose distributions will be included in OPNFV? What if I do it myself? What if I'm using a combination of these things - or I'm using hybrid cloud services?
Additionally, OPNFV has been very selective about it's storage platform by using Ceph - mostly due to ease of deployment. If you attended CERN's session about Ceph, you'll quickly see that using this platform may not be the best choice for mission critical services. I actually believe that being selective about any backend solutions is actually a very rigid path forward and can't be achieved.
There is already 26 projects created in OPNFV! OpenStack itself is more than 5 years mature and hasn't come close to this many projects. Some OPNFV projects are requirements projects, some are performance projects - but none of them are actual software projects. There is no goal to deliver a full software solution. I'm not quite sure how that works?
Finally, I've been told directly that people really shouldn't look to deploy OPNFV today. I'm in agreement with that statement. While it's great to validate the platform, start a build system and get people involved I just don't feel like the project is on the right trajectory. There's a definite need for more involvement from subject matter experts, as well as software engineers, who can help to overcome some of the obstacles I've mentioned.
While my opinion of OPNFV is that it's presently a science experiment, we have to remember that OpenStack was in that same position just a few short years ago. There are a lot of companies putting large bets on the success of SDN and NFV in the service provider market, and I honestly am excited just to be involved with any part of it.
Since the ETSI NVF-ISG definitions came out last December, there has been a mad dash across the board toward delivering the next Unicorn of network service providers. With companies like AT&T publicly committing to the Domain 2.0 effort, which commits to 5% of their network being virtualized this year, there is little doubt that there's a strong push toward software defined networks (SDN) and the ability to provide virtual network fundtions (VNFs) on top of a network function virtualization (NFV) platform.
While attending the OpenStack Summit in Vancouver last month, there was a strong showing from all of the players in this space which did two things in my eyes. First, it validated OpenStack - not just as a platform for web companies to move their transitional workloads, but as a platform which companies who provide mission critical services are looking at seriously for running the most relied upon services in the world. Second, it confirmed that a number of massive companies have a strong commitment, both to OpenStack and to OPNFV.
While all of this sounds great, the first release of OPNFV has me concerned that there is more expectation than reality in this release. I feel like there are a number of ways in which the project can improve, and their start really has me wondering if there will be a long term need for what they are doing. Here's a breakdown of what I've seen as problems so far:
First, OPNFV chose to start with a CI/CD system, which is a great start, but there's a fundamental flaw in that they have chosen to work with ISO builds of third party vendor distributions - specifically using Fuel and Foreman. I feel like there's a fundamental flaw in this decision to use specific vendor releases and not integrate with the OpenStack CI systems. Whose distributions will be included in OPNFV? What if I do it myself? What if I'm using a combination of these things - or I'm using hybrid cloud services?
Additionally, OPNFV has been very selective about it's storage platform by using Ceph - mostly due to ease of deployment. If you attended CERN's session about Ceph, you'll quickly see that using this platform may not be the best choice for mission critical services. I actually believe that being selective about any backend solutions is actually a very rigid path forward and can't be achieved.
There is already 26 projects created in OPNFV! OpenStack itself is more than 5 years mature and hasn't come close to this many projects. Some OPNFV projects are requirements projects, some are performance projects - but none of them are actual software projects. There is no goal to deliver a full software solution. I'm not quite sure how that works?
Finally, I've been told directly that people really shouldn't look to deploy OPNFV today. I'm in agreement with that statement. While it's great to validate the platform, start a build system and get people involved I just don't feel like the project is on the right trajectory. There's a definite need for more involvement from subject matter experts, as well as software engineers, who can help to overcome some of the obstacles I've mentioned.
While my opinion of OPNFV is that it's presently a science experiment, we have to remember that OpenStack was in that same position just a few short years ago. There are a lot of companies putting large bets on the success of SDN and NFV in the service provider market, and I honestly am excited just to be involved with any part of it.
Tuesday, January 27, 2015
Defining a Long-term Strategy and Roadmap for OpenStack
Back in September, 2014 Randy Bias presented at the Silicon Valley Forum for OpenStack on the topic of OpenStack product strategy - or the lack thereof.
For the past two days, members of the OpenStack community came together at the VMWare offices in Palo Alto, California to discuss three topics which are important to the future of OpenStack. So important, that some people in the community suggest that OpenStack is in danger of collapsing on itself. The key topics discussed included:
As we break for the day, we'll be sub-dividing into teams which will be focused on three major areas:
A large majority of attendees in Palo Alto represent the major vendors writing code for OpenStack today. Our hope is that, by defining these processes, we can better work with the PTLs and the OpenStack community in order to drive quality and adoption of OpenStack software for public and private clouds.
Full details of the meeting can be seen in our Etherpad
If you're interested in getting involved in this effort, please join our Mailing List . If you're a product manager working within the OpenStack ecosystem, this is a group you don't want to be left out of.
For the past two days, members of the OpenStack community came together at the VMWare offices in Palo Alto, California to discuss three topics which are important to the future of OpenStack. So important, that some people in the community suggest that OpenStack is in danger of collapsing on itself. The key topics discussed included:
- Establishing a Long-Term Vision for OpenStack
- A Tagging Approach to Project Maturity
- DefCore and RefStack
As we break for the day, we'll be sub-dividing into teams which will be focused on three major areas:
- Definition of the Product Roadmap Process - This group will be focused on how we can best define a roadmap for OpenStack that looks beyond a single release.
- Socialization within the OpenStack Community - working with PTLs, core team members and other resources to gain support and buy-in from the people writing code, performing reviews and actually developing the software.
- Cross-project Coordination - working with the project PTLs to determine how cross-project features are implemented today and determine how we can help the process.
A large majority of attendees in Palo Alto represent the major vendors writing code for OpenStack today. Our hope is that, by defining these processes, we can better work with the PTLs and the OpenStack community in order to drive quality and adoption of OpenStack software for public and private clouds.
Full details of the meeting can be seen in our Etherpad
If you're interested in getting involved in this effort, please join our Mailing List . If you're a product manager working within the OpenStack ecosystem, this is a group you don't want to be left out of.
Monday, January 12, 2015
I'm running for The OpenStack Board of Directors - here's why
Some of you may already know me, many of you likely do not. If you would grant me just a few minutes of your time, I'd like to introduce myself and tell you why I want to represent you as a member of the OpenStack Board of Directors. For the tl;dr version, just skip to the end.
I am originally from Miami, Florida. I moved to the San Francisco bay area with my family just 3 1/2 short years ago and have worked in the industry since 1991. I've been a proud member of the Cloudscaling team for just under two years now. Over that time I've been an active participant in the OpenStack community. I was lucky enough to be invited to work on the Architecture and Design Guide, worked with Cody Bunch and Kevin Jackson on their OpenStack book and am even in discussions to write a book of my own. In October 2014, Cloudscaling was acquired by my new employer, The EMC Corporation, and we're all looking forward to redefining a lot - both about Cloudscaling and our cloud initiatives within EMC. 2015 is going to be an exciting year.
At the time I first arrived in California, I was working in a very traditional field engineering role doing your average consulting gig selling and installing systems, network and security solutions very similar to my prior twenty years' experience. It was, honestly, a go-nowhere job working with a great group of people but I never could have known what it would really do to change my life. Everything changed for me the day I walked into the offices of Nebula hoping to sell them on a videoconferencing solution (which they did not buy). What I walked out of their offices with was a keen interest in this revolutionary new open source project called OpenStack which would eventually provide a whole new direction for my career.
I went back to my office and consulted the very raw and error-ridden documentation sources and struggled my way through a number of them. Over and over, I was able to produce non-working environments in VirtualBox until I finally found Emilien Macchi's github repo with a working set of instructions. At this point it was months later. As a total novice to linux and openstack, it had taken me nearly 3 months to produce a working 3-node openstack cloud.
This was the Diablo/Essex release timeframe. There were just a few projects to coordinate - there wasn't even any real dashboard to talk about. There was no CI testing system for the source code. It was real cowboy times. On release day a nova bug regression came into play which had major implications for people running the KVM hypervisor, which was just about everyone at that time. It was then that the continuous integration system was built, the testing and gate systems came into play and the developer community literally exploded in size.
What the continuous integration, gate and testing system really did is allow OpenStack to endure those large growth spurts and take on a number of new developers who were eager to contribute and commit code. It was a great time for OpenStack where a lot of new developers joined the various projects. At the Folsom summit, Rob Hirschfeld quoted '550 developers on my project' in his parody of ThriftShop titled OpenStack is Awesome. Today there are more than a dozen core projects to coordinate with more on the horizon. We have quite a few projects in the integration phases and quite a few additional ones in incubation with well over 2,700 developers working on that code today. It's safe to say that the development team has grown by 5 times in two years.
What these projects lack, in my opinion, is clear direction and prioritization of features and blueprints which will allow for wider, more sweeping adoption of the technology. In order for OpenStack to succeed, it's important that user stories are well represented and that features which satisfy those requirements are implemented in a timely manner. As a Foundation board member, I hope to begin the process of implementing the OpenStack Product Managers program as suggested by Randy Bias at last years SV Forum event in California.
In addition to bringing order to chaos within the various projects, I am also very interested in the coordinated efforts to bring OpenStack into the enterprise. I believe that OpenStack can overcome all of the hurdles that are preventing it from sweeping adoption in enterprise. Without the coordinated efforts of the Foundation, along with the project leads and development teams, it's unlikely to occur. The features which are most important to enterprise adoption need to be represented within the developer community. User and operator voices need to be better expressed. Those voices need to come from the community - not from the 'hidden influencers' of OpenStack.
I want to represent the individual developer, user and operator communities so that OpenStack can become the open source standard for building cloud infrastructure across all different markets in companies of all different sizes. In order to succeed in the market, I strongly believe that the various projects need more guidance and input from people who have expertise in managing products. I also believe that this same effort will help to address the concerns of enterprises looking to adopt the technology. We've come a long way over the past few years, and I would be honored to represent you so that we can continue on our path forward and push adoption to it's highest ever.
In order to cast your vote, please check the email account registered with the OpenStack Foundation for your own personal link.
Thank you for taking the time to read this. Your vote is greatly appreciated!
tl;dr version:
OpenStack is growing fast, enterprises have lots of roadblocks to implementing it. I want to help address this at the Foundational level so that OpenStack can continue its forward moving momentum and become the open source standard for building public and private cloud infrastructure. Go vote for me. Thanks!
I am originally from Miami, Florida. I moved to the San Francisco bay area with my family just 3 1/2 short years ago and have worked in the industry since 1991. I've been a proud member of the Cloudscaling team for just under two years now. Over that time I've been an active participant in the OpenStack community. I was lucky enough to be invited to work on the Architecture and Design Guide, worked with Cody Bunch and Kevin Jackson on their OpenStack book and am even in discussions to write a book of my own. In October 2014, Cloudscaling was acquired by my new employer, The EMC Corporation, and we're all looking forward to redefining a lot - both about Cloudscaling and our cloud initiatives within EMC. 2015 is going to be an exciting year.
At the time I first arrived in California, I was working in a very traditional field engineering role doing your average consulting gig selling and installing systems, network and security solutions very similar to my prior twenty years' experience. It was, honestly, a go-nowhere job working with a great group of people but I never could have known what it would really do to change my life. Everything changed for me the day I walked into the offices of Nebula hoping to sell them on a videoconferencing solution (which they did not buy). What I walked out of their offices with was a keen interest in this revolutionary new open source project called OpenStack which would eventually provide a whole new direction for my career.
I went back to my office and consulted the very raw and error-ridden documentation sources and struggled my way through a number of them. Over and over, I was able to produce non-working environments in VirtualBox until I finally found Emilien Macchi's github repo with a working set of instructions. At this point it was months later. As a total novice to linux and openstack, it had taken me nearly 3 months to produce a working 3-node openstack cloud.
This was the Diablo/Essex release timeframe. There were just a few projects to coordinate - there wasn't even any real dashboard to talk about. There was no CI testing system for the source code. It was real cowboy times. On release day a nova bug regression came into play which had major implications for people running the KVM hypervisor, which was just about everyone at that time. It was then that the continuous integration system was built, the testing and gate systems came into play and the developer community literally exploded in size.
What the continuous integration, gate and testing system really did is allow OpenStack to endure those large growth spurts and take on a number of new developers who were eager to contribute and commit code. It was a great time for OpenStack where a lot of new developers joined the various projects. At the Folsom summit, Rob Hirschfeld quoted '550 developers on my project' in his parody of ThriftShop titled OpenStack is Awesome. Today there are more than a dozen core projects to coordinate with more on the horizon. We have quite a few projects in the integration phases and quite a few additional ones in incubation with well over 2,700 developers working on that code today. It's safe to say that the development team has grown by 5 times in two years.
What these projects lack, in my opinion, is clear direction and prioritization of features and blueprints which will allow for wider, more sweeping adoption of the technology. In order for OpenStack to succeed, it's important that user stories are well represented and that features which satisfy those requirements are implemented in a timely manner. As a Foundation board member, I hope to begin the process of implementing the OpenStack Product Managers program as suggested by Randy Bias at last years SV Forum event in California.
In addition to bringing order to chaos within the various projects, I am also very interested in the coordinated efforts to bring OpenStack into the enterprise. I believe that OpenStack can overcome all of the hurdles that are preventing it from sweeping adoption in enterprise. Without the coordinated efforts of the Foundation, along with the project leads and development teams, it's unlikely to occur. The features which are most important to enterprise adoption need to be represented within the developer community. User and operator voices need to be better expressed. Those voices need to come from the community - not from the 'hidden influencers' of OpenStack.
I want to represent the individual developer, user and operator communities so that OpenStack can become the open source standard for building cloud infrastructure across all different markets in companies of all different sizes. In order to succeed in the market, I strongly believe that the various projects need more guidance and input from people who have expertise in managing products. I also believe that this same effort will help to address the concerns of enterprises looking to adopt the technology. We've come a long way over the past few years, and I would be honored to represent you so that we can continue on our path forward and push adoption to it's highest ever.
In order to cast your vote, please check the email account registered with the OpenStack Foundation for your own personal link.
Thank you for taking the time to read this. Your vote is greatly appreciated!
tl;dr version:
OpenStack is growing fast, enterprises have lots of roadblocks to implementing it. I want to help address this at the Foundational level so that OpenStack can continue its forward moving momentum and become the open source standard for building public and private cloud infrastructure. Go vote for me. Thanks!
Subscribe to:
Posts (Atom)