Latest posts by JP Emelie Marcos (see all)
- Increase IT Operational Efficiency with SignifAI - April 26, 2018
- Learnings From My Discussion with Eric Yuan, CEO and Founder of Zoom - November 14, 2017
- Four Predictive Analytics Challenges Facing Site Reliability Engineering Teams - August 24, 2017
Today, companies are quickly coming to realize the many benefits of adopting a collaborative approach between teams, which had traditionally been working independently of one another. Welcome to the DevOps revolution.
However, this kind of revolution does not take place overnight, especially at the enterprise level. Making the transition to DevOps requires a massive philosophical shift away from how companies have traditionally operated in the past to become more cohesive, more agile, and ultimately more productive.
Let’s take a look as some of the best practices to ensure a smoother transition from working as traditional, and non-collaborative silos, to DevOps— the agile, and efficient model of cross-departmental productivity.
It’s a Culture Change
While most developers do not have an intimate understanding of the underlying infrastructure, and most system admins do not code, both of their roles must gradually evolve and intersect, allowing for all parties to embrace the culture change. In order to help facilitate this process, organizations are transitioning to cross-functional and product aligned teams. Integrating different teams is at the heart of DevOps, and is the first hurdle that any company needs to overcome in order to adopt new collaborative practices.
Rather than managing projects, a broad cross-functional team aligns to products, by owning its roadmap, architecture, design, development, run and support requirements.
This transition also typically brings QA testers and other representatives of the business into the development team as part of the collaborative process.
While this may sound easy, for many enterprises this is a difficult process that involves a number of challenges such as staff restructuring, breaking up shared services and reporting lines. Additionally, long-time employees may be less likely to deviate from their well-defined role within the organization and buy into the culture change. Again, this is a process, and the larger the organization, the longer it will likely take for the full adoption of DevOps. A gradual approach, however, should allow everyone to ultimately embrace this new way of working.
With so many tools on the market to choose from, it can be almost overwhelming for any organization that is looking to make the switch. Not every platform performs every function and finding the right mixture of tools to fit the specific needs of the organization to ensure that team members are on the same page, can be a challenge to any enterprise.
There are a couple of considerations before using any one of the vast number of open-source tools or SaaS based offerings. True, the free user trials are convenient, but this also allows users the ability to quickly adapt them without proper internal oversight. It is crucial to be able to both support implementation, while maintaining full visibility on any potential vulnerability. When choosing the right set of tools, keep in mind three factors; technology, domain and purpose to pick the winning combination.
Whether it’s a repository manager, a data manager, build tools, or a monitoring dashboard— the organization must also maintain governance over the data that is stored within these DevOps tools.
As an organization elects and implements new tools, they should know that it can have negative consequences in relation to downtime. Recent research suggests that downtime costs the average Fortune 1000 company between $100k an hour, for an infrastructure failure, up to $1 million per hour for the failure of a mission-critical application.
Implementing collaborative practices must be a gradual process in order to maintain the highest uptime possible. There are many issues that must be taken into consideration, including: code quality, version control, and proper unit testing. Companies in the early stages of integration, might want to take cues from other organizations that have successfully adopted continuous integration. For instance, 30% of companies who practice infrastructure standardization and comprehensive test automation, quickly advance towards their goals.
It would behoove any organization that is looking to adopt a new model to either hire consultants or hire new employees who are experienced working in a DevOps environment. Without this kind of injection of proven experience, the sheer amount time spent on making this transition could potentially translate into these incredibly costly lags in service.
Budget & Training
One common challenge to the implementation and overall adoption of DevOps is how an organization’s budget, specifically the structure of their budget, will change as their expenses increase. The reality is that enterprises are constantly looking for ways to spend less whilst maximizing profitability. Adopting any new system or processes is going to take time and money, often with unforeseeable unexpected costs cropping up at some point. Obviously, these unexpected costs can be budgeted for, but only to a certain extent and they are only part of the challenge:
Onboarding applications to DevOps: This is the first major expense, because tracking and collecting meta data to understand the behavior of any application component, requires tremendous amount of action items and followups.
BAU Can Harm the Process: When we are dealing with CI/CD, we must take into account that the technology will change and evolve. If you cannot keep pace with revisions and updates, you will lose your ability to automate and the entire project will be for naught. Plan carefully, so that your staff will not get caught up with business as usual and lose track of the goals.
Staffing cost: Understanding the demand that onboarding will have on your staff in necessary for setting a budget. Experience has proven that an engineer will max out from onboarding 20 application components a month before he has to deal with BAU work. Thus, it is important to bring to bring on people who have broad skillsets, and enough of them, in order to deal with onboarding and BAU.
Ultimately, the adoption of DevOps greatly benefits an organization’s ability to ensure uptime and increase overall service quality. High-performing IT organizations that employ such practices are deploying 200 times more frequently than their low-performing non-DevOps counterparts. Furthermore, these organizations are also able to enjoy 24X faster recovery from IT failure while greatly minimizing the chance of downtime.