Strategy is confidence and execution.
If you’ve got a process that supports your strategy, you can execute.
You can say no to the right things and focus on the important element Strategy is not just knowing where you are going, it’s knowing which things to say no to along the way.
We suffer from an over-abundance of opportunity. Success often means knowing what not to do.
1/18 Note: I was re-elected! Thanks everyone for your support.
OpenStack Foundation members, I have three requests for you:
And, of course, vote according to our code of conduct: “Members should not attempt to manipulate election results. Open debate is welcome, but vote trading, ballot stuffing and other forms of abuse are not acceptable.”
To vote, you must have been a member for 6 months. Going Mad Panda? Join right now so you can vote next time!
Even if you’re not a voter, you may find my comments useful in understanding OpenStack. Remember, these positions are my own: they do not reflect those of my employer (Dell).
Vote because it’s the strongest voice the community has about OpenStack governance
I’d strongly encourage you to commit code, come to the summit and participate in the lists and chats; however, voting is more. It shows measurable impact. It shows the vitality of the community.
OpenStack is exciting to me because it’s community driven.
I have been a strong and early leader in the community:
Vote for me because of my OpenStack Operations focus
My team at Dell has been laser focused on making OpenStack operable for over 2 years. My team acts like a lean start-up inside of Dell to get products out to market early.
We’ve worked with early operators and ground-breaking ecosystem partners (plus). We’ve helped many people get OpenStack running for real workloads. Consequently, I am highly accessible and accountable to a large number of users, operators and ecosystem vendors. Few other people in the OpenStack community have my breadth of exposure to real OpenStack deployments. My team and I have been dedicated, active participants in OpenStack long before Dell’s grand OpenStack strategy coalesced.
More importantly, I am committed to open source and open operations. The Apache 2 open source Crowbar project established the baseline (and served as the foundation) for other OpenStack deployment efforts. We don’t just talk about open source, we do open source: our team works in the open (my git account).
Vote for a board because diversity of views is important
OpenStack voting allows you to throw up to 8 votes to a single candidate. While you can put all your eggs into a single basket, I recommend considering a broader slate in voting.
We have an impressive and dedicated list of candidates who will do work for the community. I ask that you consider the board as a team. If you want operators, users, diversity, change, less corporate influence or any flavor of the above then think not just about the individual.
Why should I be part of your slate? I am not a blind cheerleader. I have voiced and driven community-focused positions about the board (dev cycle, grizzly >;; folsom, consensus).
One of my core activities has been to work on addressing community concerns about affinity voting. Gold and Platinum members have little incentive to address this issue. While I’d like to see faster action, it requires changing the by-laws. Any by-law changes need to be made carefully and they also require a vote of the electorate. If you want positive change, you need board members, like me, who are persistent and knowledgeable in board dynamics.
It would be easy to get lost in a board of 24 members, but I have not. Armed with my previous board experience, I have been a vocal advocate for the community in board meetings without creating disruption or pulling us off topic.
I am a strong and active board member and I work hard to represent all OpenStack constituents: developers, operators, users and ecosystem vendors.
Working on a board is a long-term exercise. Positions and actions I’ve taken today may take months to come to fruition. I would like the opportunity continue that work and see it through.
Rafael Knuth (@RafaelKnuth with Dell as EMEA Social Media Community Manager) has set an ambitious objective to interview all 24 of the OpenStack Foundation Board members. I had the privilege of being the first interview posted (Japanese version!).
Here’s the series so far:
These are excellent interviews and worth reviewing. They give balanced (often critical) views of OpenStack, its progress and challenges.
I update the list as he adds them.
I’ve been “in cloud” for over 13 years (@dmcrory and I submitted patents using it starting in 2001) and I’m continually amazed at how complicated people want to make it.
For my role at Dell, I’m continually invited to seasons of meetings to define cloud, cloud architecture and cloud strategy. The reason these meetings go on and on is that everyone wants to make cloud complicated when it’s really very simple.
Cloud is infrastructure with an API.
That’s it. Everything else is just a consequence of having infrastructure with an API because API provides the ability to provide remote control.
What else do people try to lump into cloud? Here are some of my topic cloud obfuscators:
pay-as-you-go (service pricing). This is a common cloud requirement but it’s really a business model. If someone builds a private cloud then it is still a cloud.
We start talking about these points and then forget the whole API thing. These items are important, but they do not make it “a cloud.” When Dave McCrory and I first discussed API Infrastructure as “cloud,” it was driven by the fact that you could hide the actual infrastructure behind the API. The critical concept was that the API allowed a you to manage a server anywhere from anywhere.
When Amazon offered the first EC2 service, it had to be a cloud because the servers were remote. It was not a cloud because it was on the internet; plenty of other companies were offering hosted servers. It was a cloud because their offering allowed required operators to use and API to interact with the infrastructure. I remember that EC2’s lack of UI (and SLA) causing many to predict it would be a failure; instead, it sparked a revolution.
I’m excited now because we’re entering a new generation of cloud where Infrastructure APIs include networking and storage in addition to compute. Mix in some of the interesting data and network services and we’re going to have truly dynamic and powerful clouds. More importantly, we going to have some truly amazing applications.
What do you think? Is API a sufficient definition of cloud in your opinion?
PS: Yes, if you have a physical server/network/store that is completely controllable by an API then you’ve got a cloud on your hands.
Occasionally, my journeys into Agile and Lean process force me down to its foundation: cultural fit. Frankly, there is nothing more central to the success of a team than culture. That’s especially true about Lean because of the humility and honesty required. If your team is not built on a foundation of trust and shared values then it’s impossible keep having the listening and responsive dialog with our customers.
Successful teams have to be honest about taking negative feedback and you cannot do that without trust.
Trust is built on working out differences. Ideally, it would be as simple as “we agree” or “we disagree.” In an ideal world, every team would be that binary. Remember, that no team always agrees – it’s how we resolve those differences that makes the team successful. That’s something we know as “diversity” and it’s like annealing of steel to increase its strength.
Unfortunately, there are four modes of agreement and two are team poison.
I’ve never seen a team that is as simple as agree/disagree but I’ve been at companies (Surgient) that tried to build a culture to support trust and conflict resolution (based on Lencioni’s excellent 5 dysfunctions book). However, there’s a major gap between a team that needs to build trust through healthy conflict and one that wraps itself in the dysfunctions of artificial harmony and warfare.
If you find yourself on a team with this problem then you’ll need management by-in to fix it. I have not seen it be a self-correcting problem. I’d love to hear if you’ve gotten yourself healthy from a team with these issues.
Signs of artificial agreement syndrome include
Lean process and methodology is important to me because I think it is central to the work that we are doing in the community. Even more, it’s changing how my team at Dell creates and delivers products for customers?This post may be long, but my answer to “why Lean” ends up being very simple: Lean process is honest and humble.
We need very strong ideas and a vision; however, we need to be motivated by making something that is significant to other people. They are the ones who give it value.
Humility it not just about listening and collecting feedback: it is about interacting and building relationships.
Whew….Yesterday, Dell announced TWO OpenStack block storage capabilities (Equallogic & Ceph) for our OpenStack Essex Solution (I’m on the Dell OpenStack/Crowbar team) and community edition. The addition of block storage effectively fills the “persistent storage” gap in the solution. I’m quadrupally excited because we now have:
Frankly, I’ve been having trouble sitting on the news until Dell World because both features have been available in Github before the announcement (EQLX and Ceph-Barclamp). Such is the emerging intersection of corporate marketing and open source.
As you may expect, we are delivering them through Crowbar; however, we’ve already had customers pickup the EQLX code and apply it without Crowbar.
If you are using Crowbar 1.5 (Essex 2) then you already have the code! Of course, you still need to have the admin information for your SAN – we did not automate the configuration of the storage system, but the Nova Volume integration.
We have it under a split test so you need to do the following to enable the configuration options:
Want Docs? Got them! Check out these > EQLX Driver Install Addendum
Usage note: the integration uses SSH sessions. It has been performance tested but not been tested at scale.
The Ceph capability includes a Ceph barclamp! That means that all the work to setup and configure Ceph is done automatically done by Crowbar. Even better, their Nova barclamp (Ceph provides it from their site) will automatically find the Ceph proposal and link the components together!
Ceph has provided excellent directions and videos to support this install.
I’m certain that the Atlantic‘s Charles Fishman was not thinking software and DevOps when he wrote the excellent article about “The Insourcing Boom.” However, I strongly recommend reading this report for anyone who is interested in a practical example of the inefficiencies of software lean process (If you are impatient, jump to page 2 and search for toaster).
It’s important to realize that this article is not about software! It’s an article about industrial manufacturing and the impact that lean process has when you are making stuff. It’s about how US companies are using Lean to make domestic plants more profitable than Asian ones. It turns out that how you make something really matters – you can’t really optimize the system if you treat major parts like a black box.
When I talk about Agile and Lean, I am talking about proven processes being applied broadly to companies that want to make profit selling stuff. That’s what this article is about
If you are making software then you are making stuff! Your install and deploy process is your assembly line. Your unreleased code is your inventory.
This article does a good job explaining the benefits of being close to your manufacturing (DevOps) and being flexible in deployment (Agile) and being connected to customers (Lean). The software industry often acts like it’s inventing everything from scratch. When it comes to manufacturing processes, we can learn a lot from industry.
Unlike software, industry has real costs for scrap and lost inventory. Instead of thinking “old school” perhaps we should be thinking of it as the school of hard knocks.
These views are my own. Based on 1×1 discussions I’ve had in the OpenStack community, I am not alone.
If you’ve read my blog then you know I am a vocal and active supporter of OpenStack who is seeking re-election to the OpenStack Board. I’m personally and professionally committed to the project’s success. And, I’m confident that OpenStack’s collaborative community approach is out innovating other clouds.
A vibrant project requires that we reflect honestly: we have an equal measure of challenges: shadow free fall Dev, API vs implementation, forking risk and others. As someone helping users deploy OpenStack today, I find my self straddling between a solid release (Essex) and a innovative one (Grizzly). Frankly, I’m finding it very difficult to focus on Folsom.
Grizzly excites me and clearly I’m not alone. Based on pace of development, I believe we saw a significant developer migration during feature freeze free fall.
In Grizzly, both Cinder and Quantum will have progressed to a point where they are ready for mainstream consumption. That means that OpenStack will have achieved the cloud API trifecta of compute-store-network.
Everything I hear about Folsom deployment is positive with stable code and significant improvements; however, we’re too late to really influence operability at the code level because the Folsom release is done. This is not a new dilemma. As operators, we seem to be forever chasing the tail of the release.
The perpetual cycle of implementing deployment after release is futile, exhausting and demoralizing because we finish just in time for the spotlight to shift to the next release.
I don’t want to slow the pace of releases. In Agile/Lean, we believe that if something is hard then we do should it more. Instead, I am looking at Grizzly and seeing an opportunity to break the cycle. I am looking at Folsom and thinking that most people will be OK with Essex for a little longer.
Maybe I’m a dreamer, but if we can close the deployment time gap then we accelerate adoption, innovation and happy hour. If that means jilting Folsom at the release altar to elope with Grizzly then I can live with that.
Rafael Knuth (@RafaelKnuth with Dell as EMEA Social Media Community Manager) has set an ambitious objective to interview all 24 of the OpenStack Foundation Board members. I have the privilege of being the first interview posted (Japanese version!). Here’s the whole series.
This is not puff interview – We spent an hour together and Rafael did not shy away from asking hard questions like “Why did Dell jump into OpenStack?” and “is VMware a threat to OpenStack?” Rather than posting the whole transcript (it’s posted here), I’m including the questions (as a teaser) below. There is some real meat in these answers about OpenStack, Dell, Crowbar and challenges facing the project.
WARNING: My job is engineering, not marketing. You may find my answers (which are MY OWN ANSWERS) to be more direct that you are expecting. If you find yourself needing additional circumlocution then simply close your browser and move on.
Some highlights…
Dell’s interest in OpenStack has been very pragmatic. OpenStack is something we really see a market need for.
Rackspace … runs on OpenStack pretty much off trunk … That’s exactly the type of vibrant community we want to see. At the same time, there is a growing community that wants to use OpenStack distributions with support, certifications and they are fine with being 6 months behind OpenStack off trunk. That’s good, and we want that shadow, we want that combination of pure minded early adopters and less sophisticated OpenStack users both working together.
We are working with different partners to bring OpenStack to different customers in different ways. It is confusing. Your question about Dell Crowbar was right … it is targeted at a certain class of users, and I don’t want enterprise customers who expect a lot of shiny chrome and zero touch. That’s not the target by now for Dell Crowbar. We definitely need that sort of magic decoder page to help customers understand our commercial offering.
Rob Hirschfeld 
