Applications should not crash. Systems should not go down. In the world of DevOps, failure isn’t exactly encouraged. While we have seen every kind of iteration positioning failure as a positive thing (failing forwards, failing better, failing often, you name it), the fact of the matter is that ‘failure’ isn’t particularly beneficial or conducive to achieving our goals.
Yet, DevOps failures are an unfortunate reality for many of us and they are often inescapable. Perhaps, then, it may be useful to redefine what failure is and what failure is not. Failure is being unable to meet your objectives; it is a lack of performance. Failure is not making and then learning from your mistakes, which will allow you to succeed later on.
Speed is as critical to software development as it is recovery from failure, so the rate at which you can leverage the insights gained from making mistakes is critical to your success. With this philosophy as the background, here are some of the most common DevOps failures, and how to learn from them quickly.
1. Falling out of step
DevOps means having to deliver at the speed of business, which can be particularly challenging in today’s fast-paced, technological world. As such, many teams run process in parallel during continuous integration and continuous delivery, allowing them to accelerate their automated testing and shorten their feedback cycles.
According to Laura Frank Tacho, Director of Engineering at CloudBees, “While this may be a good idea, in theory, it can sometimes cause significant misconfiguration. Allowing the code to deploy at the same time tests are running consequently defeats the purpose of pre-deployment automated testing.”
As such, it is vital to remember that code must pass all appropriate checks and balances before being deployed to the customer. While DevOps principles assert that engineers should be ready to deploy at any given moment, deployment should be managed and deliberate. Continuous delivery pipelines must be constructed in such a manner that parallel testing serves as a gate to production, not an automatic route to deployment. Rather, deployment should only occur at the final stage of the pipeline after all tests, validations, checks, and approvals have passed.
2. Getting locked out
It’s important to have the right layers of protections in place at every stage of the development process. Without validation of configuration, for instance, engineers can lock themselves out and be forced into the tedious process of manually logging in to each machine to reconcile misconfigurations.
“To preempt these types of situations, engineers should validate all changes early – and often – to ensure not only the quality of the application but the environments and even the CD pipelines itself,” explained Carlos Sanchez, Principal Software Engineer at CloudBees. Applying cohesive credentials and permissions management to DevOps and productions systems will also help engineers focus on problem prevention, rather than detection.
3. Organizational obstacles
Not all problems DevOps engineers face are technical; sometimes it can be a case of their organization’s culture and structure. When multiple teams and departments are concentrated in various silos, it becomes difficult to treat systems and software developments as a whole, particularly pursuing continuous improvement. For instance, when attempting to facilitate cross-departmental collaboration, answers from the opposing teams can be “that’s not our department” or “they won’t speak with us.” Even in more collaborative companies, the time required for cross-functional hand-off and context switching is a significant obstacle to achieving velocity.
Organizing teams around product or software functionality and including all stakeholders in the software development process will allow DevOps leaders to improve the synergy amongst stakeholders. It should also prevent the ‘us versus them’ mentality that can sometimes plague traditional software development. Viktor Farcic, a Senior Consultant at CloudBees, agreed, pointing out that, “Culture must not be overlooked as a factor in DevOps. While process, practices, tools, and technology are undoubtedly the core pillars of the practice, culture is equally important. It is surprisingly one of the more difficult aspects to change.”
4. Unsuitable KPIs
The pace of business is only becoming faster as new technologies improve operational processes and transform business models for the digital age. Shareholders are applying intense pressure on organizations to keep up with this rapid pace. As a result, organizations are finding themselves having to report multiple key metrics to measure their performance across all areas.
In light of this, Juni Mukherjee, Product Marketer at CloudBees, explained that these metrics aren’t always the most suitable. “To effectively prove performance, DevOps leaders must first establish a set of principles that will help them understand what, and how, meaningful metrics can be obtained; for example, considering lead times as time to production, not to completion.”
5. To scale or not to scale
When working with open source software, it is vital to have expertly trained developers who can ensure that the software is still suitable for their organization’s particular use case. It’s also important to make sure it takes full advantage of the innovations the open source community has to offer.
However, in order to select appropriate open source software, Sacha Labourey, CEO at CloudBees, explained that DevOps teams should first “take a long-term view of their organization’s needs and business priorities, and discuss how the solution will need to scale over the next few years. Doing so will allow organizations to understand the prep work needed to scale usage.”
Teams should also determine if the solution aligns with their existing toolchain. As organizations continue to scale, they will be hard-pressed to find a tool that can do it all. As a result, integrations along the way are inevitable. Ensuring that these integrations are stable is critical for their success. Understanding how the solution will fit and work with existing tools is an important factor in scaling for the future, and, ultimately, the organization’s growth.
SEE ALSO: DevOps for your SME? Four steps to a successful initiative
In conclusion
To successfully practice DevOps, you must build seamless connections linking people, processes, tools, and goals. However, this entails hard work. There will be mistakes and communications along the way. These issues, as challenging as they may be, are solvable if DevOps processes are treated as an iterative process of learning and improvement. By using DevOps correctly, developers can turn short-term failures into long-term success.
The post Learning from DevOps nightmares appeared first on JAXenter.
Source : JAXenter
