Upgrade & Secure Your Future with DevOps, SRE, DevSecOps, MLOps!
We spend hours on Instagram and YouTube and waste money on coffee and fast food, but wonât spend 30 minutes a day learning skills to boost our careers.
Master in DevOps, SRE, DevSecOps & MLOps!
Learn from Guru Rajesh Kumar and double your salary in just one year.
Source:-devops.com
When it comes to DevOps adoption, â[many organizations] tell a similar story,â said Scott Van Kalken, systems engineer at F5 Networks. It takes more time and effort to develop the right culture than you probably expect.
Van Kalken has a long history in tech, including development and operations roles, and has spent several years practicing DevOps. He is part of the open source and meetup communities, and organizes some of the largest DevOps events in Australia.
âDevOps typically starts in a corner of the organization, where people want to deliver high-quality software really quickly,â said Van Kalken.
When that team gets good results, the organization decides to scale up its DevOps efforts, but tradition and silos get in the way.
âAt least two things are needed to overcome those obstacles and achieve DevOps success,â suggested Van Kalken.
Collaboration and Safe Places
The first thing you need to achieve DevOps success is a collaborative team environment. One of the central ideas of DevOps is you donât throw software over the wall between functions, such as development and testing, so there needs to be an understanding and acceptance that everyone in the team is on the same side.
Second is the provision of a safe place to fail and the realization that failure is just an iterative step on the path to implementing the best ideas.
A financial services company that Van Kalken works with was adopting GitOps but needed to convince the service management team this was the right move.
âInitially, it was quite challenging because service management thought it [GitOps] was uncontrolled chaos, even though that isnât the case,â he said.
Its support was gained after running a series of workshops that showed the underlying processes were actually the same, even though the tools used to implement them were changing.
Service management is still the final gatekeeper, but it now approves releases in the repository rather than on paper.
Maturity
âThere is a maturity in accepting change does involve risk,â said Van Kalken.
Things such as GitOps provide a quick and easy way of reverting to a previous release if something goes wrong. So the âsafe place to failâ idea can be implemented in a way that protects the organization in a practical sense as well as staff members in a psychological (and career protecting) sense.
Another way DevOps can protect the organization is that frequent releases generally involve relatively minor changes, which in turn have a smaller blast radius in the event something goes wrong. Again, this is about having the maturity to recognize risk and dealing with it, rather than trying to avoid it in the first place.
A sometimes overlooked aspect of increasing the release cadence is the effect on users, who are being asked to cope with frequent changes.
Van Kalken pointed out that increasing the frequency does not necessarily mean multiple releases a dayâit could be from two releases a year to three or four, if thatâs what suits the organization.
Not all changes have a direct impact on users. Some are under the hood, improving performance or addressing rarely-encountered bugs. But when usersâ interaction with the system is changed, he suggested canary deployments as a way of checking the acceptability of the new approach among a larger pool of users than those brought into the development process, before it is released to the entire user population.
âThis approach also has a place in DevSecOps as another way of limiting the blast radius,â he said.
Accepting Failure
Perhaps the biggest challenge to an organizationâs culture is the adoption of chaos engineering because if youâre going to kill a container or flood a network with data in order to check that the wider system can cope, you absolutely need to be in a safe place to fail.
You also need to realize everyone involvedâincluding developers, security people and those involved in the business sideâwants to achieve high availability, and that means designing systems that can handle (partial) failures.
It isnât enough to do this in pre-deployment testing. Ongoing testing provides confidence that production systems will continue to cope with such failures.
âItâs pretty cool when you get it right,â said Van Kalken. However, âyour culture has to be OK with this iterative approach.â
âDevOps is really just a methodology to achieve a better outcome,â stated Van Kalken. That involves collaboration, iteration and embedding security and other considerations up front. But the wider organization needs to understand and tolerate this, and the risk that goes with it.
âEducation, awareness and experience can all contribute to dispelling the traditional view that risk and failure are inherently bad,â he suggested.
Are the Metrics Appropriate?
A related point is that whether one outcome is better than another, depends on the metrics adopted. â[Metrics are] probably the biggest things organizations need to change,â said Van Kalken.
For example, a customer who ordered a pizza doesnât care whether a particular system involved in taking the order, cooking the pizza and then delivering it, achieved a certain uptime target. They just want the pizza to arrive promptly.
When that doesnât happen, he believes a collaborative approach is needed to determine why the delivery was late, exactly what caused the problem and how to quickly roll out a fix to stop it recurring.
When it comes to practical advice, Van Kalken emphasized the need to get people together early in a project, otherwise there is a risk that sub-groups will demonize each other. In addition, you get more buy-in and everyone accepts they have to help with the pedaling, not just sit back and be passengers.
âIf people arenât talking, you have a bad culture,â he said. But he acknowledged it can be difficult to get past existing adversarial relationships. Breaking the ice between teams that havenât previously engaged with each other can also be tricky.
Returning to an earlier theme, he stressed the importance of adopting an analytical, rather than punitive, approach when failure occurs. Everyone involved must know the organization accepts risk and understands the consequences.