When we talk about OpenStack, there is a lot of focus on the Continuous Integration/Continuous Deployment (CI/CD) methodology it uses to achieve its rapid release schedule of two releases a year. Think about that for a moment, a network of thousands of developers working together to release an operating system that runs clouds. Clouds that run applications, applications that run businesses. This is no small feat.
Not only is OpenStack developed in this manner, but many organizations using OpenStack as the platform of choice for their own CI/CD ventures. As OpenStack grows by leaps and bounds with every release, so do business’ abilities to accelerate their own development with the newest features.
So why continuous? Continuously integrating and deploying allows developers to get their changes, which are often new features, into the hands of their users faster. Users like new features. How many times have we used a platform and said to ourselves “this is great, but it would be better if…?”. In the world where “there’s an app for that”, and likely more than one app that does almost the same thing, the CI/CD methodology can be the difference between success and failure. Any of us who have programmed know that one of the biggest issues we can run into is the integration phase. By doing this continuously, we can catch small issues before they become bigger ones.
Of course, the CI/CD model fits nicely into the DevOps movement. By closing the gap between the development and operations teams, rapid deployment becomes not only possible, but profitable. How many times have we sat in meetings, on either the development or the operations side and struggled to get our point across to the other team? Maybe they just didn’t get it, maybe they weren’t thinking the same way we were. By merging these two teams, we eliminate this. Sure, it may take time for developers to understand operations, and operations to understand operations, but ultimately, there will be an intrinsic power in the group, and great things will happen. Sometimes this makes me wonder what’s next. DevArch? ArchOps? Architects are providing the foundation to DevOps to run with the CI/CD model, but when do they all merge?
One critical piece of OpenStack, like any other application born of the CI/CD method is documentation. I think many times people see the development work as the sexy part, the fun part, the cool part. We all love to talk about how many lines we’ve written (either it is a massive undertaking we’re bragging about, or we’re talking about how we got 200 lines of code into five). It doesn’t matter how fast we deliver the next iteration of our application, it’s pretty useless if no one can figure out how to use it. OpenStack is the same way. Because of the rapid development cycle, this becomes even more important. How else can we figure out what great new features are available?
To me, beyond the architecture of OpenStack, how all of the different projects are going to interact, documentation is the next most important step. Documentation is an invaluable resource to those who are just starting to dive into OpenStack, or those who need to start making a solid business case to take their environments to the next level. The OpenStack documentation is the rally map, while the developers build the car, before it gets raced during the next release’s summit.
One remarkable example of OpenStack documentation is the OpenStack Architecture Design Guide, which is completely free of charge, and was created in a week. Yes, a week. It is amazing what a dedicated team can do when they get the time to sequester themselves. While there are other books out there that have also been created in the week long sprint format, this one by far is my favorite. It is a great resource for anyone who wants to learn more about OpenStack architecture.
One of the great things that #vDM30in30 is forcing me to do again it to get used to writing every day. I’ll admit, with #NaNoWriMo there were days (sometimes multiple at a time!) I skipped, and would get caught up on a weekend. Not the case this year! I’ll be posting a blog every single day (and I may or may not have started a #NaNoWriMo as well that I know I won’t even come close to finishing, but it was too much to resist). I think once this month has passed, I’ll try to get involved with OpenStack documentation. It isn’t really that hard to get setup with, and I can make a great contribution by doing something I really enjoy doing.
When I think of the DevOps model, I don’t really see myself fitting in. Sure, I could, and it would probably be a lot of fun once I got going, but I think my interests lie elsewhere. I’m more of an ArchDoc, architect and author seeking to document the architecture I’m building. Your architecture won’t be much unless you have the documentation to support it, from build out, testing, and planning, to using business needs to justify new components and additional spend. I’m looking forward to the rise of the ArchDoc. After all, someone’s got to get the infrastructure ready for those DevOps folks.
Song of the Day – 2 Cellos – You Shook Me All Night Long
Melissa is an Independent Technology Analyst & Content Creator, focused on IT infrastructure and information security. She is a VMware Certified Design Expert (VCDX-236) and has spent her career focused on the full IT infrastructure stack.