Getting started with DevOps or trying to address process improvement in DevOps is almost always a challenge. The reason for this is the importance and complexity of driving change — there will always be people, process, policy, and products that need to be considered, no matter the maturity of your organization.
As part of an ESG Research Report I recently completed on the journey to DevOps (The DevOps Reference Model: The Foundation for Transforming Application Development and Deployment), I recorded a video describing the beginning of any DevOps transition:
Additionally, don't forget to check out my irreverent infographic, The Road to DevOps.
Female: The following is an ESG video blog.
Steve: Hi, I'm Steve Hendrick, Principal Analyst for Application Development and Deployment Research at ESG. Some of you know that I've recently completed a DevOps Reference Model. And I created this model because there's not enough guidance coming from the DevOps tool vendors on how to get started with DevOps and where DevOps is headed. So here are some pointers to help you get started on your DevOps journey.
Now, DevOps is a very expansive topic, and I have conservatively counted 13 market segments within DevOps. And what this means is that it will be hard to make informed decisions in DevOps until you have a pretty good grasp of what DevOps is. While this video will help you with that, there is still a significant amount of research that you will need to do to reach a reasonable understanding of what DevOps is.
Now, the first rule of DevOps is not to talk about DevOps. Wait, wait that's...wrong script. The first rule of DevOps is to understand DevOps. And while there are probably elements of agile development that your enterprise has already adopted, DevOps encompasses the entire life cycle of an application from concept all the way through the pipeline and management of the production application.
Understanding DevOps methodology will go a long way to helping you evaluate the current state of how you do application development, and compare and contrast it to best practices from enterprises that do DevOps well. DevOps at its core is about people and processes, so don't underestimate the legacy drag created by corporate culture and use executive sponsorship and multidisciplinary teams as a way to overcome cultural roadblocks.
Now, the second rule of DevOps is to be application-first, or be application-centric. Today, IT is about delivering services which are accomplished through applications. Everything else about IT exists to support application delivery and applications in production. This will be easy if you're using cloud infrastructure, but much harder if your resources are not software defined or software managed.
The purpose of being application-first is to prioritize pipeline deployment ongoing application management activities. The intent is to ensure that all of these activities and gates are non-blocking so that the application can move through its life cycle without arbitrary delays, waiting for approvals or resources. From a production standpoint, this also means measuring application performance to ensure support for all of the abilities, including scalability, availability, maintainability, and manageability.
The third rule of DevOps is that you're only as good as your greatest weakness. DevOps is full of serial, iterative, and recursive activities, and any one of these can build delay into the development deployment, production, or performance of an application. This is a very good reason to reflect back on the first rule, to fully understand DevOps methodology. If there's a weakness in your current software development life cycle, the best way to fully grasp the weakness is to have a comprehensive view into DevOps methodology or DevOps done right.
Now, if you're disappointed that we didn't talk about your favorite tools or the importance of architecture and design or where DevOps is heading, take a look at my DevOps Reference Model. Search on both ESG and DevOps. Thanks for watching, and be seeing you.