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!
Wednesday, January 29, 2014
Talking Trove with Baz #CloudOps @Lithiumtech
Last night I had an opportunity to hang out at the @Lithiumtech office for their San Francisco based #CloudOps meetup and learn all about an OpenStack project which is still in the incubation stages but has a really bright future. Michael Basnight, Trove PTL from Rackspace came out fully decked in his three cat shirt and unicorn hat to spread the love and recruit more troops to bring the hopes and dreams of the project to life.
As a database administrator, your job time should be spent doing valuable things. Installing a database server is not one of those valuable tasks. If you have to install that database server repeatedly, that is definitely not time spent well. I would equate the joy of installing a database server with going to the dentist for a triple root canal. The intricacies of installing and configuring a database, setting up the proper security settings, initializing database instances and tables are all things that take a considerable amount of time.
Let's not even get into the complexities of change management or those pesky enterprise silo teams that put the brakes on even the most critical of projects. There's nothing like bringing in the systems, storage, software, network, security and BI teams all together to thwart the efforts of business units and partners alike.
To put it bluntly, installing and configuring a database server sucks. So wouldn't it be nice if you could click the easy button to install a database server (so you can leave early for beer)?
The Trove project is aimed at delivering Database-as-a-Service on top of OpenStack's Infrastructure-as-a-Service. The idea is that, as a consumer of cloud services, instantiating a database server should be easy. The cloud user should be able to select from a list of database servers such as mySQL, PostgreSQL, mongo, cassandra and, potentially, others. Using a standard API the instance can be launched, managed and even auto-scaled in future implementations.
With OpenStack, these are all things that can be automated with Trove, abstracted away from the user, avoiding all of those pesky silos and change management forms. Then all of those people whose jobs used to involve repetitive manual tasks can also do more important things (or leave early for beer with you).
At the moment, Trove is an extremely young project. With great luck, Trove is on it's way to becoming an integrated project. Unfortunately, as it currently stands with the OpenStack Foundation and the Technical Committee, Trove is confined to being incubated until it takes certain steps.
What will it take for Trove to become integrated and, eventually a core project? You! The Trove project needs people who are willing to work on the code base and have the technical experience to contribute.
Some of the things currently in development include:
Support for additional databases beyond mySQL
Support for redundant database instances
Integrated backup mechanisms for upstream databases that don't support backup
Support for provisioning with Heat
For a full list of Trove blueprints see: https://blueprints.launchpad.net/openstack/trove
To contribute code to OpenStack see: https://wiki.openstack.org/wiki/HowToContribute
It was a lot of fun listening to Baz talk about Trove and that's not just the beer talking. Be sure to come out to Lithium for the next CloudOps meetup (http://www.meetup.com/cloudops) and join in on the excitement.
Oh, and you might win a tablet.
(Also, did I mention the free beer....)
As a database administrator, your job time should be spent doing valuable things. Installing a database server is not one of those valuable tasks. If you have to install that database server repeatedly, that is definitely not time spent well. I would equate the joy of installing a database server with going to the dentist for a triple root canal. The intricacies of installing and configuring a database, setting up the proper security settings, initializing database instances and tables are all things that take a considerable amount of time.
Let's not even get into the complexities of change management or those pesky enterprise silo teams that put the brakes on even the most critical of projects. There's nothing like bringing in the systems, storage, software, network, security and BI teams all together to thwart the efforts of business units and partners alike.
To put it bluntly, installing and configuring a database server sucks. So wouldn't it be nice if you could click the easy button to install a database server (so you can leave early for beer)?
The Trove project is aimed at delivering Database-as-a-Service on top of OpenStack's Infrastructure-as-a-Service. The idea is that, as a consumer of cloud services, instantiating a database server should be easy. The cloud user should be able to select from a list of database servers such as mySQL, PostgreSQL, mongo, cassandra and, potentially, others. Using a standard API the instance can be launched, managed and even auto-scaled in future implementations.
With OpenStack, these are all things that can be automated with Trove, abstracted away from the user, avoiding all of those pesky silos and change management forms. Then all of those people whose jobs used to involve repetitive manual tasks can also do more important things (or leave early for beer with you).
At the moment, Trove is an extremely young project. With great luck, Trove is on it's way to becoming an integrated project. Unfortunately, as it currently stands with the OpenStack Foundation and the Technical Committee, Trove is confined to being incubated until it takes certain steps.
What will it take for Trove to become integrated and, eventually a core project? You! The Trove project needs people who are willing to work on the code base and have the technical experience to contribute.
Some of the things currently in development include:
Support for additional databases beyond mySQL
Support for redundant database instances
Integrated backup mechanisms for upstream databases that don't support backup
Support for provisioning with Heat
For a full list of Trove blueprints see: https://blueprints.launchpad.net/openstack/trove
To contribute code to OpenStack see: https://wiki.openstack.org/wiki/HowToContribute
It was a lot of fun listening to Baz talk about Trove and that's not just the beer talking. Be sure to come out to Lithium for the next CloudOps meetup (http://www.meetup.com/cloudops) and join in on the excitement.
Oh, and you might win a tablet.
(Also, did I mention the free beer....)
Friday, May 3, 2013
San Francisco Bay Area OpenStack Meetup Recap - May 2. 2013
You know OpenStack is gaining momentum and recognition when your local meetup group attracts a bunch of developers and operators along with sales and marketing people from across different verticals - and that's exactly what I experienced yesterday at the first user group meetings since the Summit in Portland a few weeks ago.
Our local community seems to have grown tremendously since I have become involved. We have some really talented and intelligent people showing up to share ideas and collaborate - and Sean Roberts (@sarob) has been doing a fantastic job of developing a focus for our user groups as he works on community development for the OpenStack Foundation Board of Directors. We're very lucky to be able to support three different meetup groups for beginner, intermediate and advanced users of OpenStack thanks to Sean's great efforts - along with those community members who bother to show up and get involved.
This week's Advanced meetup group was focused around a Havanna Summit review - which meant that the members who were in Portland a few weeks ago got to recap some of the more interesting projects and topics we saw. Some of those included:
Refstack.org - Refstack provides a reference architecture and testing methodology in order for a cloud provider to be able to call itself an OpenStack cloud. This is built around Agile development processes used similar to what is currently used to manage code in the OpenStack Continuous Integration systems. Providers will be required to expose an endpoint for testing purposes and must be capable of passing a series of OpenStack systems tests in order for it to be 'certified' as an OpenStack cloud provider.
DevOps requirements - We discussed the real world requirements for implementing a DevOps approach when attempting to implement infrastructure that scales - and how so many companies are incorrectly thinking that 'free' software meant that there was no cost to implement. This is something that is affecting real world companies as we spoke with one operator yesterday who went through this exact pain with his employers while implementing OpenStack over the past 6 months. Based on his estimation, his implementation of OpenStack requires additional services which will cost approximately twice what the hardware costs amortized over 3-5 years. I'm not sure if this is based on a reliable scientific calculation - but I also don't think he's far off. The same gentleman also discussed his difficulty in building out the hardware infrastructure due to a lack of reference architecture to refer to at the time he was building (see above).
Project RedDwarf - Database as a Service - Project Red Dwarf is a mysql database-as-a-service solution for OpenStack aimed at providing scalable, redundant database solutions on-demand to tenants within the cloud. Colin McNamara (@colinmcnamara) presented on the design he saw where mysql could be scaled as a service - somewhat similar to a popular public cloud solution's implementation of relational database services. This would be a great solution for deploying OpenStack-on-OpenStack, another huge topic at this year's summit.
There was plenty more to discuss during this meeting, but we only had the room until 5:00 PM and there was a crowd gathering outside - so we said our goodbyes (for now) and planned to meet back at the Yahoo! campus for the beginner and intermediate groups at 7:00.
I arrived back at the Yahoo! campus slightly late, and when I walked in the Intermediate group was chatting it up. We were waiting on Vinay Binnai (@vinaybannai) to come present the blueprint he has been working on with other community members regarding Firewall-as-a-Service. We discussed what a firewall as a service should be with regard to tenant networks and a number of people committed to working on the blueprint in order to move progress along on the project.
All in all, the meetups were really well-run this week. I'm looking forward to the next one on the 16th. If you can make it out to Yahoo in Sunnyvale, come join us! We meet every second Thursday and our meetups are organized at http://www.meetup.com/openstack
Oh yeah, Colin schooled me on continuous integration, a topic which is completely new to me. I'm reading Jez Humble's book "Continuous Deployment" as a result. Funny how those things work out.
Our local community seems to have grown tremendously since I have become involved. We have some really talented and intelligent people showing up to share ideas and collaborate - and Sean Roberts (@sarob) has been doing a fantastic job of developing a focus for our user groups as he works on community development for the OpenStack Foundation Board of Directors. We're very lucky to be able to support three different meetup groups for beginner, intermediate and advanced users of OpenStack thanks to Sean's great efforts - along with those community members who bother to show up and get involved.
This week's Advanced meetup group was focused around a Havanna Summit review - which meant that the members who were in Portland a few weeks ago got to recap some of the more interesting projects and topics we saw. Some of those included:
Refstack.org - Refstack provides a reference architecture and testing methodology in order for a cloud provider to be able to call itself an OpenStack cloud. This is built around Agile development processes used similar to what is currently used to manage code in the OpenStack Continuous Integration systems. Providers will be required to expose an endpoint for testing purposes and must be capable of passing a series of OpenStack systems tests in order for it to be 'certified' as an OpenStack cloud provider.
DevOps requirements - We discussed the real world requirements for implementing a DevOps approach when attempting to implement infrastructure that scales - and how so many companies are incorrectly thinking that 'free' software meant that there was no cost to implement. This is something that is affecting real world companies as we spoke with one operator yesterday who went through this exact pain with his employers while implementing OpenStack over the past 6 months. Based on his estimation, his implementation of OpenStack requires additional services which will cost approximately twice what the hardware costs amortized over 3-5 years. I'm not sure if this is based on a reliable scientific calculation - but I also don't think he's far off. The same gentleman also discussed his difficulty in building out the hardware infrastructure due to a lack of reference architecture to refer to at the time he was building (see above).
Project RedDwarf - Database as a Service - Project Red Dwarf is a mysql database-as-a-service solution for OpenStack aimed at providing scalable, redundant database solutions on-demand to tenants within the cloud. Colin McNamara (@colinmcnamara) presented on the design he saw where mysql could be scaled as a service - somewhat similar to a popular public cloud solution's implementation of relational database services. This would be a great solution for deploying OpenStack-on-OpenStack, another huge topic at this year's summit.
There was plenty more to discuss during this meeting, but we only had the room until 5:00 PM and there was a crowd gathering outside - so we said our goodbyes (for now) and planned to meet back at the Yahoo! campus for the beginner and intermediate groups at 7:00.
I arrived back at the Yahoo! campus slightly late, and when I walked in the Intermediate group was chatting it up. We were waiting on Vinay Binnai (@vinaybannai) to come present the blueprint he has been working on with other community members regarding Firewall-as-a-Service. We discussed what a firewall as a service should be with regard to tenant networks and a number of people committed to working on the blueprint in order to move progress along on the project.
All in all, the meetups were really well-run this week. I'm looking forward to the next one on the 16th. If you can make it out to Yahoo in Sunnyvale, come join us! We meet every second Thursday and our meetups are organized at http://www.meetup.com/openstack
Oh yeah, Colin schooled me on continuous integration, a topic which is completely new to me. I'm reading Jez Humble's book "Continuous Deployment" as a result. Funny how those things work out.
Monday, April 29, 2013
OpenStack Summit Portland 2013 - Unconference Edition
Just as the Nicira NVP session by Dan Wendlandt wrapped up, I checked out the handy OpenStack Summit schedule app on my Android platform to find that none of the upcoming sessions were of particular interest - so I headed over to check out the Unconference schedule.
What is Unconference you may ask?
Unconference was an opportunity for anyone with an OpenStack-related topic they wanted to discuss to write their name and topic in a time slot on a set of easels in the main hallway. Slots were given out to speakers on a first-come first-served basis - once the slots were all claimed the list was finalized. I was rather delighted by the list of sessions being offered. Unconference was a smorgasbord of OpenStack-related content that had some really interesting topics throughout the summit. In fact, Unconference was somewhat of a regular destination for me. Any time I couldn't find something of interest in the general sessions Unconference came through for me.
I figured out that Room A104 was my next destination as I wanted to see Mirantis present on Savanna - Hadoop as a Service on OpenStack. I walked into a packed room with standing room only, found my place over against the side wall and tuned in to hear what the Mirantis team had to say about their new project. The back of the room filled up with other attendees and Mirantis team members smiling proudly - and rightfully so, these guys are doing some really interesting things with OpenStack. By the time they were ready to start, the room was as packed as could possibly be. I don't think Mirantis expected this much hoopla over Hadoop as a Service.
I figured out that Room A104 was my next destination as I wanted to see Mirantis present on Savanna - Hadoop as a Service on OpenStack. I walked into a packed room with standing room only, found my place over against the side wall and tuned in to hear what the Mirantis team had to say about their new project. The back of the room filled up with other attendees and Mirantis team members smiling proudly - and rightfully so, these guys are doing some really interesting things with OpenStack. By the time they were ready to start, the room was as packed as could possibly be. I don't think Mirantis expected this much hoopla over Hadoop as a Service.
Before we get too far, lets just put it out there - I'm weary about calling everything 'X' as a Service on OpenStack. Sure you can call it 'X-as-a-service' but isn't that the whole idea of addressing a pool of resources and shouldn't everything be made available as a service that's available in a service catalog? I would have put this up as my own Unconference topic had I gotten to the easel early enough - and it probably isn't the last you'll see of this subject from me - but I digress.
The developers went through a 20 minute presentation on the features of Savanna, talked about the future road map a little bit and then they did something that defied all odds - a live demo which actually worked! The Mirantis team was able to demonstrate how the Savanna GUI integrates fairly simply with the OpenStack Horizon dashboard as a plugin. In the interface, the user can easily pick the base snapshot image on which to base their Hadoop deployment, type in a number of worker and tracker nodes and away OpenStack goes building out the requested Hadoop environment.
Just a few minutes later, the presenter from Mirantis logged into the tracker node and submitted a job to the cluster to calculate Pi - a job that it did with relative ease and kicked back the result in what seemed like almost no time at all. I was fairly amazed at how quickly the Hadoop cluster was stood up with a name node, a tracker node and 5 worker nodes - from the first provisioning steps to running a job in under 10 minutes.
After the demonstration the floor was opened up to questions and comments - of which there were plenty. Interest in Savanna was high and there seemed to be a number of developers from other projects watching this one closely. After the tasty preview offered in this session, I'm looking forward to seeing more of what Savanna can do in future releases. During the conference, it was announced that Hortonworks, Red Hat and Mirantis will be working on this project jointly, so I would expect to see some really amazing developments in the not-so-distant future.
Keep up-to-date on the Savanna project at http://www.savanna.mirantis.com
Keep up-to-date on the Savanna project at http://www.savanna.mirantis.com
Subscribe to:
Posts (Atom)