Experiments will DevOps
When I asked this question “What do you understand by DevOps”, pretty much everyone’s answer can be summarized as “collaboration between development and operations teams resulting in better releases and reduced release cycle times”. This is fine. Now when the second question “how this is is implemented in your organization?” asked, answer cannot be summarized easily. It has variations. Some almost unique responses are.
- Developers will deliver the build (code, test, build) and then hand over the build to operations team for deployment. There is an agreed SLA and ways of working between the teams for communication and status updates.
- Development team will deliver the code; Operations team members will monitor the quality of builds, will automate the releases to all sandboxes and control the changes to the environments
- Development team focuses on coding and environment configuration of different servers. Operations team owns and delivers the automation for deployment, testing and build, monitors the failures and escalates it to right development team for closure.
- Managing and configuring environments are outsourced. Development and project level operations are owned by project teams. Central operation teams will allocate shared DevOps resources for each project based on magnitude and importance of in-release scope.
- Development and project level operations are owned by project teams. Central operation teams will allocate shared DevOps resources whose primary job is automation for each project based on magnitude and importance of release scope.
- We have outsourced the operations to third party organization. They allocate the best resource based on time and material contract for each project. We get best DevOps practices implemented this way.
- Ops team does the code management, testing, build and deployments, Dev team focuses on development and environment configuration to enable the testing of their code.
People structure and interdependencies are the reasons attributed for the gap in understanding and the implementation. These I call experiments with DevOps. Few thoughts on what is DevOps and what should be done to realize the benefits of DevOps. DevOps, is this a concept, a philosophy or ways of working or strategy or something else?
Jezz Humble says in his “The State of DevOps”, DevOps is a movement of people who care about developing and operating reliable, secure, high performance systems at scale”
- Culture: People and process first. If you don’t have culture, all automation attempts will be fruitless.
- Automation: This is one of the places you start once you understand your culture. At this point, the tools can start to stitch together an automation fabric for DevOps. Tools for release management, provisioning, configuration management, systems integration, monitoring and control, and orchestration become important pieces in building a DevOps fabric.
- Measurement: If you can’t measure, you can’t improve. A successful DevOps implementation will measure everything it can as often as it can… performance metrics, process metrics, and even people metrics.
- Sharing: Sharing is the loopback in the CAMS cycle. Creating a culture where people share ideas and problems is critical.
Where do we begin?
Quick answer is DevOps Practices. Implement the DevOps practices and ensure they are matured over period of time to deliver the full potential of DevOps. Scott Ambler explains following 10 practices are critical in establishing successful DevOps culture in the organization.
- Active Stakeholder Participation: developers, operations staff, and support people must work closely together on a regular basis
- Automated testing: Adopt test-first approach. Automate testing’s so that you can test as often and early as possible.
- Integrated configuration management
- Integrated change management
- Continuous integration
- Integrated deployment planning
- Continuous deployment: Extend the CI to all environments till production. If development teams are not disciplined enough, results in defects
- Production support: Development teams should ensure production fixes and regular releases both are taken care without issues.
- Application monitoring
- Automated dashboards: Code quality, build and deployment dashboard should be real time
All this through a team who works collaboratively which is key to DevOps.
CA identified from the survey in 2013 the top obstacles in implementing the DevOps which is depicted in the chart below.
So technically we may succeed in establishing the silo practices. It is more challenging to bring the silos together which is nothing but the cultural change. These challenge that needs to be taken care is described by Chris Rilay in short as follows:
- Who owns Culture: You have heard that DevOps is culture first. And while you know what culture means, it’s never clear who owns it. Until operations can identify how they will include culture fostering into their daily activities, there is no way to help this aspect of DevOps grow. It is a must to get to the processes and proper implementation of the tools. Infrastructure is still in operations full control, but because large organizations are creating dev silos the culture is not, and because they are supposed to be tied, this is a bit of a contradiction.
- Everyone has a tool: These days everyone has a tool for the job. Many of the tools are open-source, or SaaS based offerings that users can get a trial of and start using instantly. The trick for operations is to support this and still maintain awareness. These tools can be adopted without any internal oversight, which can lead to issues down the road. First because of support down the road if the original adopter leaves, but more importantly governance. What data is stored there?
- “There is an App for that, right”: All those tools are simply an app you download and use, right? Nope. They have to tie into everything else, and it’s not the App that is the challenge. The challenge is getting it adopted, integrated, and quantified. For example a functional testing tool fixes QA challenges, but it has to fit in with delivery automation tools as well.
- Cloud + Legacy: The reason operations don’t jump at tools at the pace that development and business users would desire, is not because they do not want to. Often it’s because that tool has to fit into an ecosystem of existing applications. Usually there are a few grandpa applications in there that lack have the agility the modern tools have. But they still have to work together.
- Not only does the new hybrid environment include on-premise tools, IaaS tools like Amazon, Google, or Azure, PaaS compute services, and finally SaaS business applications. But, they all have to jive together too!
- Networking is a drag: Networking, not servers, is often the immutable object that is not easy to make agile. Even when working with vLans there is a spider web of IPs, Ports, Routers, routing tables, perimeter networks etc whose interdependency can’t simply be changed, broken, moved, or replicated.
- Marginalized and Changing Budgets: it is very cliché to say budgets are being squished while demands are increasing. But that is not the point. The point is the structure of budgets is changing, and many organizations have not figured out how to align that with the shift in types of technology. There are the capital expenses that are separate from the operational ones. However CAPEX spends often are mirrored by sister OPEX ones. It becomes very confusing when you try to quantify the spend on an on-premise project management tool with a SaaS one as well.
- Security compliance and change policies also are challenges in implementing the DevOps.
There is variety of tools that addresses the needs of DevOps practices. Based on technology, domain and purpose choose the right tool set combination. Similarly wide variety of automation framework and scripts exist enabling DevOps culture.
On DevOps tools, In Jan 2015, in one of its RightScale survey’s Chef and Puppet tops the usage and Docker seems to be marching towards the top in near future.
Things to watch out for during adoption
However few things to be kept in mind in addition to above challenges while adopting DevOps are
- Developers and Operations- Difficulty staying on the same page
- Developers vs. operations—and the fear of change
- Having to learn new skills outside the comfort zone
- Upheaval at work: Workflows change and processes look different. The intertwined workflows are harder to visualize and document, making regulatory compliance more difficult and time-consuming.
- For traditional organizations the power shift that DevOps creates can be unsettling. In organizations where IT commands a great deal of power within the corporate structure, change in the hierarchy is a big change
Change should be managed without threat to anyone on-boarded to DevOps solution.
How will I know “Am I DevOps ready”?
Neil Garnichaud puts it in three simple questions. If your answer is No, you are not there yet on the DevOps curve
- Do you, as a developer, have access to troubleshooting information in real time?
- Does your production environment use tests and other tools from the development team to validate that the production environment is working?
- As a developer, do you view the networking team as your partner?
RightScale survey shows there is an uptrend in DevOps adoption. This will continue to raise more.
DevOps as a Service is gradually gaining popularity and something to watch out for in future.
Share your feedback on how DevOps is implemented and its challenges in your organization.