Big changes don’t come easy, and as your organization embarks upon an OpenStack project, you will likely face a range of skeptics among internal stakeholders. You might find that other departments don’t think agile methodology is a fit for SLA-driven IT operations. Your organization’s operations team might be focused on hardware instead of user experience. Network engineers might worry that your new networking topologies conflict with existing security policies. Procurement teams accustomed to proprietary equipment might resist transitioning to commodity hardware. So what’s an OpenStack advocate to do?
After helping to build some of the largest OpenStack clouds in the world, Mirantis has encountered a fair share of skeptics at diverse companies, as well as a range of other obstacles that can potentially delay or interfere with an OpenStack project from reaching production.
For example, you may find that key incumbent stakeholders express doubts about your OpenStack project, in terms of its approach, execution, effect on operations, etc. I mean, you know this can work, but they’re not on board.
There’s no easy answer. Skeptical stakeholders and their differing expectations need to be addressed at multiple levels. Some crucial actions you should take include:
- Secure executive level buy-in from Day 1 to make sure you have a strong advocate with enough weight to pull in detractors.
- Agree on a Minimum Viable Product (MVP) that consists of a tangible application with the minimum features that can handle core workloads and create value; it should be the first major milestone of your OpenStack project.
- Plan for gradual organizational changes, especially when working with other departments less experienced with agile methodologies.
- Identify and communicate risks throughout the project, so relevant plans and/or processes can be adjusted as needed.
- Execute in an agile fashion but speak waterfall (this is easier than you may think).
OpenStack changes frequently. Since no two environments and their workloads are perfectly alike, it is inevitable that compatibility issues and unexpected bugs arise after deploying the latest OpenStack version.
While it may not be a popular position with the hard-working community engineers building the Kilo release, in production deployments, it’s our experience that you are better off to favor stability over the cutting-edge — don’t feel compelled to use the newest OpenStack recipe and upgrade every six months. It’s better to work with what’s tried and true, otherwise you potentially risk encountering expensive downtime and sleepless nights from unforeseen issues. By the way, many of our customers choose Mirantis OpenStack for exactly this reason; our distro pushes the upstream trunk code through a pretty significant battery of use cases and configuration tests to help prevent surprises.
There’s an old saying that good judgement comes from experience, and experience comes from the other kind of judgement. Since we want you to be successful with OpenStack, we are truly eager to share our experience, and help you go into your OpenStack deployments with eyes open.
Of course, there’s lots more. I will be discussing these topics and more in “The OpenStack Production Checklist,” a live webcast on December 18 where my colleague, Nick Chase, and I will share tips and recommend best practices from the point of view of executives, project managers, and engineers alike.