.svg)
The year is almost half over and depending on the part of the world you are in, semblances of life before the pandemic is starting to reappear. Rapid digital transformations occurred for many industries because of the pandemic and as organizations scrambled to adjust to the needs of their customers and clients.
DevOps practices and infrastructures were pushed because the velocity of change increased to compensate for the disruptions and the availability of staff and skills were fluid. Tech, platforms, and practices continue to evolve and move forward even during the pandemic; necessity is the mother of innovation.
The term DevOps has been around for over a decade now, though in the last several years there has been a paradigm shift in organizations to embrace DevOps practices and culture. Today, having DevOps practices in organizations is not a bleeding-edge or a novel concept. Like any journey, it can certainly take time.
Viewed as the stewards of engineering efficiency, driving to organizational goals of deploying changes as soon as they are ready and providing pragmatic safeguards for engineers and running application infrastructure, the DevOps movement in 2021 and beyond pushes forward. Core tenets to these goals and software delivery are providing automation to move forward the capabilities of the organization.
A prominent page out of the SRE Handbook is building a blameless culture; since hindsight is 20/20, pointing out individuals is not a good way for improving the system. Architectures should be robust enough that changes can be easily made in platforms due on an ongoing basis, and if there are bottlenecks or incidents, postmortem findings can be quickly and blamelessly implemented. As time goes on, guardrails are put in place and in a pragmatic fashion. Balancing the radio dials of innovation vs control can make pragmatic guardrails. An example of a good guardrail would be to implement self-healing architectures.
A quintessential blameless question to answer would be, “How was an engineer allowed to make a certain change?” For example, in a misconfiguration. Self-healing architectures at the core have the ability to revert quickly if there is a problem to restore/maintain MTTR. Making automated decisions, if there is deviation/regression, is important for self-healing architectures. Another pillar of self-healing architecture is the ability to monitor and manage drift. Drift usually occurs when the defined state of the system is modified by a user. In the GitOps paradigm, the repository is the source of truth and GitOps providers will bring back the state of the system to the defined state. Because DevOps teams can’t think of every possible combination to implement safe and pragmatic guardrails, leaning on the machines to help (e.g. AIOps) continues to rise.
With the myriad of monitoring, observability, and analytics tools and platforms out there, making sense of the deluge of data can be difficult. The rise in logs, APM data, and traces/spans can be information overload for even the most seasoned DevOps engineer. Similar to credit card vendors figuring out fraud at the time it occurs, Artificial Intelligence Operations, or AIOps, helps to make decisions on what is normal vs what is not, and can continuously run after a deployment.
If you are pessimistic about Artificial Intelligence/Machine Learning, an extremely good use case for AI/ML is to find deviation. If you imagine yourself as a new engineer on a dev team and embracing the “if you write it, you run it” operating model, knowing what is normal is a real challenge and an expected part of the learning curve. Scratching the surface with AIOps, modern DevOps platforms leverage AI/ML to look for patterns and anomalies helping to alleviate decision fatigue for the operators of said platforms. Even if your developers are miles away from production, with the rise of Kubernetes, technical barriers are being brought down in that both development and operational skillsets can deploy to Kubernetes, which is becoming a common ground of running DevOps workloads.
The evolution of the Kubernetes ecosystem continues to trend up. Over the past seven years, since the initial release of Kubernetes, more and more workloads of importance have been placed on Kubernetes clusters. Not seen as a “neat project” anymore, operational expertise is required.
Kubernetes itself is a great distributed system platform to accomplish many DevOps-centric tasks such as being the perfect place to run your Continuous Integration infrastructure.
Kubernetes provides an excellent place for ephemeral workloads to run. For example, ephemeral build runners in your CI process. As other compute-intensive items need to run for short periods of time in your DevSecOps pipeline, such as container/image scanners, Kubernetes is an excellent place to run these items. As the entire Kubernetes ecosystem rises and Kubernetes continues to proliferate the enterprise, Kubernetes becomes ubiquitous to run application workloads and engineering efficiency/DevOps tools and workloads. Kubernetes continues to drive public cloud consumption, either with infrastructure to power the cluster, or managed Kubernetes offerings. As the push to the public cloud continues, so do the cloud vendor’s goals of cannibalizing the ecosystem.
As the public cloud continues to garner more and more workloads as organizations shift from on-prem data centers to public cloud infrastructure, public cloud vendors want to cannibalize the entire software development lifecycle. Ranging the entire gamut of developer tools from Source Code Management [SCM] to Integrated Development Environments [IDEs] to CI/CD and all needed underlying infrastructure, cloud vendors are looking to drive stickiness and adoption.
Looking at Amazon Web Services, for example, leveraging their Cloud9 IDE allows your web browser to be connected to other AWS services, such as AWS CodeCommit [SCM] and eventually into AWS CodePipeline [CI] to some degree. Both Microsoft Azure and Google Cloud have similar products. No matter if leveraging AIOps, Kubernetes, and/or cloud-native infrastructure through the aid of cloud vendors, an overall goal of DevOps since the inception is the ability and confidence in iteration.
One of the core pillars of developer experience is iteration. An argument that the entire purpose of the SDLC is a confidence-building exercise, and core to confidence is the ability to iterate; incremental changes are safer than monumental shifts. Iteration does lead to experimentation and vice versa, which is more possible with modern DevOps and engineering efficiency platforms.
Depending on which side of the equation you came to DevOps with, the development side or operational side, your appetite for iteration might be different. Generally, developers live for iteration, as they rarely get something right the first time; this is the entire reason for a development environment. Versus traditional ops roles; production is production - you have to be right the first go or an incident is around the corner.
With the rise of software-defined infrastructure/infrastructure-as-code, operations engineers are embracing more software engineering concepts and practices. With the unity that DevOps provides, both sides of the equation (development and operations) can continue to iterate.
Infrastructure-as-code allows for the rapid creation of infrastructure. Treating infrastructure as immutable (if you need to make a change, you recreate infrastructure) has boiled in from the containerization world. Because you need to recreate, the opportunity is there to improve this iteration and experimentation is a normal practice.
Businesses have been experimenting with hypothesis-based modeling and experimentation for years. For example, placement of certain items above/below others in retail stores is core to hypothesis-based testing based on how the items perform. In older paradigms, engineering teams have been layered from direct external customer feedback; meaning there is an extended feedback loop and the ability to experiment is reduced because the ability to pivot to or from the experiments is more difficult. With the rise of progressive delivery paired with continuous delivery and the ability to have feature flags not only for application features but also infrastructure, experimenting is much easier. Because of all of the shifts that iteration and experimentation bring vs traditional approaches, the DevOps movement is still evolving and still a hot industry to build a career in.
There is no question that DevOps practices and insights are becoming mainstream and a very in-demand skillset to help instill the needed culture and practices in organizations.
In a recent Enterprisers Project article, several DevOps leaders weighed in on top interview questions for DevOps Engineers. Software is certainly a team sport, but DevOps is the “team sport of team sports,” breaking down silos and enabling engineering efficiency. DevOps transformations take time and are not accomplished overnight; organizational change can take years. Because of the skillset and time to implement change, demand is certainly outpacing demand for DevOps professionals and it is very high in 2021. If you are looking to take your first dip into DevOps, there are lots of great resources for you to learn.
If you are unfamiliar with DevOpsDays, they are local and grassroots conferences that are focused on fostering DevOps cultures and practices. There was a pause for several DevOpsDays in 2020, with some going virtual. Though, they are starting to sprout back up in 2021 and beyond as restrictions around meeting in person start to ease! I was exposed to the cultural and transformative side of DevOps, above and beyond tooling, at DevOpsDays several years ago and highly recommend attending. These events really drive home the true potential of the DevOps mindset in terms of collaboration and communications, and how it can benefit your organization to implement a cultural shift into DevOps.
Scaling DevOps throughout an organization can be difficult, especially if core metrics/OKRs are deployment velocity and frequency. Core to deployments are the CI/CD pipelines in organizations. At Harness, we did research over dozens of organizations looking at common deployment patterns in our free Pipeline Patterns eBook. Feel free to download the eBook today to learn from what peers in the industry are achieving. At Harness, we are also stewards of {unscripted} conference where everyone can sharpen software delivery skills, make sure to catch the conference. The DevOps movement continues to move forward as new paradigms appear. DevOps hiring is strong in 2021 and it’s never too late or too early to sharpen those skills.
Cheers!
-Ravi
Sign up for our free plan, start building and deploying with Harness, take your software delivery to the next level.
Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.
.svg){kind=small}
Learn intelligent software delivery at your own pace. Step-by-step tutorials, videos, and reference docs to help you deliver customer happiness.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.
.png)
