A River Runs Through It: What I Learned About DevOps Ecologies From Standing in Cold Water | DevOps Experience 2023
A healthy river is a complex interplay of geology, hydrodynamics, and natural and created ecosystems. Add in someone in waders, waving a stick, and the story becomes even more complicated.
This talk is about how observation, adaptability, continuous improvement and local knowledge change our experience of DevOps… and fly fishing.
Join Brian Walter for an exploration of how you can map your own local ecology by finding code owners, related teams and sociotechnical insights, and also get some beautiful nature pictures.
Transcript
What on earth could DevOps and fly fishing possibly have in common? How could they be related? And what does sociotechnical engineering have to do with fly fishing in the first place?
Hello everyone. I'm glad you could all join me today. Today we're gonna talk about two things.
I love fishing and DevOps. We're gonna talk about how we could possibly learn about one from the other, and we're gonna learn a little bit about sociotechnical engineering along the way. I think we're gonna have some fun with this one, so let's just jump right in.
My name is Brian Walter and I've spent the last 26 years building technical teams and highly complex architectures. I've had the privilege of working on some very large scale systems, and now I'm currently building a company called Open Context, a platform for auto discovering and understanding your organization's sociotechnical map, a realtime view into the contextual relationships between people, code, infrastructure, and services. Now, I grew up in the Pacific Northwest, and as you might imagine by the name of this talk, I absolutely love to fish.
I love being on the river. I love the bugs, I love the fish, I love the boats. If it's fishing, boating or water related, rain or shine, if it's any of these things, I'm probably your guy.
I fished in places all over North America, British Columbia, Alaska, Montana, Wyoming, Idaho, Washington, and my home in Oregon. I love to travel to fish, but my home waters are here in the northwest, specifically the north coast of Oregon. I live in a cabin just outside of the small coastal town of Tillamook, Oregon on the banks of the Wilson River.
The Wilson River is an incredible steelhead in Salmon River in the winter months. This is my home in the picture here, and while it's remoteness trades off some of the ma major conveniences of city life, it lets me be by the water constantly. I've also been around this DevOps thing for quite a while, and as I draw on my experiences from two of the most important aspects of my life, fishing and DevOps, I keep finding connections and intersection between the two, overlapping between two seemingly unrelated and different worlds.
I could've made this talk sociotechnical engineering for DevOps, but then all the cool fish pictures wouldn't make any sense. So today we're gonna talk about those connections and hopefully I'll entertain you a little bit along the way. We're gonna start our journey into sociotechnical engineering at my home on the Wilson River.
The Wilson River is a coastal tributary of Oregon's Tillamook Bay. Several different rivers flow into the waters of Tillamook Bay and the Wilson is the largest of them. We're home to Chinook salmon, coho salmon, steelhead, and sea run cutthroat trout.
And on top of that, there's native cutthroat trout that call the Wilson Home year round. Now, I love the Wilson River, but I'm not the only one. Its close proximity to the Portland metro area, and its fantastic.
Fisheries have made it a hugely popular destination for fisher people, swimmers, boaters, and countless other groups who enjoy the river. If you are on the west side of Portland, the Wilson is by far the easiest river to access from town. The Wilson has been on its own journey, a journey to being frankly loved to death as Portland has grown.
By the 1980s and 1990s, the Chinook and coho and steelhead and trout fisheries were dwindling. Use of the river was at an all-time high and with its fisheries collapsing due to pressure, something had to be done. Salmon runs were down by 80% in the year.
In the year 2000, steelhead runs the same. Harvest had been taking its toll, had also had logging and habitat loss throughout the estuary. Reforms were needed in many different areas.
One of those reforms we're gonna talk about next today, more than 50% of the salmon and steelhead runs in Ula Bay are born here at the Whiskey Creek volunteer fish hatchery. Now, a fish hatchery is a place where salmon and steelhead are collected from the river artificially spawned and bred to grow thousands upon thousands of baby fish. Those fish are put back into the ecosystem and ultimately contribute to the populations in the river located just to the south.
In Ni Tart's Bay. The Whiskey Creek hatchery is almost entirely volunteer, run, grassroots, supported, and absolutely vital to the success of North Coast Oregon Fisheries. But operating a fish hatchery in the northwest is extremely complicated.
There are incredible politics involved, environmental concerns, policies to follow special interest groups to appease, as well as a high demand for the best possible science and practices to ensure that the correct impact is being made and that we're not actually damaging the ecosystem we love. It's not just about the creation of hatchery fish, but being confident that the impacts to native wild fish that we love so dearly are safe beyond these concerns. It turns out that simply operating a fish hatchery is extremely complicated in its own right, a very significant technical endeavor.
Today, more than a dozen different state and federal tribal government agencies, international government agencies, even with Canadian treaties, local fish advocacy groups, environmental groups and commercial interests all weigh in on how fisheries are managed in the Northwest. This has a direct impact on hatchery plans and operations. All of these groups have different personalities, different people, and different needs.
Some are easy, some are difficult, and some of these groups are straight up obstinate and impossible to move. And this is a relatively simple hatchery just to the north and the Columbia River system. With the largest salmon run in the world, the complications are even wilder.
When you go there, it's 10 times more complicated. So what's a small team of highly skilled biologists and passionate volunteers to do? How can they run their hatchery operation under such incredibly complicated conditions?
How can they have the impact to the ecosystem they desire? And it starts with everybody at the table recognizing that we all love this ecosystem. We all love the fish.
We all want a healthier river system. By the end of the day, compromise is often the answer. These are groups that seldom agree on what technically to do, and yet we all love this ecosystem and we all want a successful outcome.
Think of these groups as your stakeholders, your business, your product team, your finance team, your compliance department, your developers, your DevOps engineers, and even your customers. Everybody cares, everybody has a voice, and everyone can make a complete mess of this process. Starting to sound familiar, right?
A highly technical environment with significant regulation, with intense technical demands, and if it all goes well, very frequent and regular deployments of Phish. Now, we're not gonna deep dive into how hatcheries operate here. That's a presentation I would love to give someday, but that's not what this is about.
But in my learnings, I quickly discovered that the concepts of sociotechnical engineering and the principles of DevOps exist outside of the traditional DevOps field, and we find them in so many other areas of life. So with that connection, let's learn a little bit about sociotechnical systems theory. It's a mouthful, right?
And full disclosure, I don't profess to be an expert in this. I'm learning too. Just like you, I'm learning from our mentors, folks like John Willis and Andrew Clay Schaeffer, folks like James Wickett, folks that have published incredible works and helped to define the DevOps movement.
If you wanna go deep on the subject, John Willis's new book on Edwards Deming is a fantastic place to start Presentations from Andrew Clay Schafer, excellent as well. But at a high level, sociotechnical systems theory starts with a few things. A holistic systems view with an emphasis on the interconnectedness of our components, the relationships between those components and how they play in your environment, the people, the teams, the code, the infrastructure, the services.
We're adapting to one element and realizing that a particular element may impact the entire system. That a change can have a ripple effect, that we're all connected, we're all interdependent. We have an emphasis on feedback loops and continuous learning, collaboration and shared knowledge.
We adapt in what we're doing and we offer resilience and we anticipate change, and we operate with ethics and human values. We care about our teams and we care about the impacts to our families. We care about the people.
If these values sound a lot like what we've heard about DevOps over the years, that's because DevOps has its roots in sociotechnical engineering, much the same way. A river system is an incredibly complex ecosystem. Interdependent components, the environments we operate in works the same with DevOps.
We have a heavy emphasis on the human element. Sociotechnical, uh, engineering underscores this intertwined nature of technology. Human systems urging DevOps practitioners to ensure that we're all in harmony for optimal outcomes.
Now, I'm an introvert, so how can I be socio anything? I don't like talking to people? Is it that I don't like talking to people or is it something more nuanced in that?
What is being an introvert in the first place? So I did some research. So Simon Sinek draws an analogy of what an introvert is versus an extrovert as this.
An introvert is somebody who starts the day with five coins, with every human interaction with another person. Those coins are depleted, more interaction, more depletion. That's why for many of us we're just exhausted after a conference like this one.
Now, extroverts are the opposite of that. They start the day with no coins, they start depleted, and every time they interact with somebody, it recharges them. They get a dopamine hit, they get a high, they get fulfillment out of interacting with others.
It's, it can be an addiction for them, and without this interaction, they feel drained. Now, I suspect many of you are introverts, and just as we learned about sociotechnical engineering, we find ourselves in an interesting spot. If DevOps requires such strong interaction between teams, how on earth can I do this without feeling drained?
How can I make an impact? I am who I am. I've found for myself the tools like asynchronous communication, being deliberate in how I write and access to real-time context maps of our environment, crucial to managing my introversion.
Nothing kills me faster than an 80 person conference bridge to solve an incident, and yet I've been there time and time again. For me, simply acknowledging this and having a little empathy for our people goes a long way. For others, it's more difficult.
Either way, empathy is the answer. So with that background, let's talk about some DevOps principles and let's try to connect them to fly fishing. Now, if you're at this conference, you're probably already somebody who knows a thing or two about DevOps.
But if not, let's go over the basics. So the essence of systems thinking, understanding the broad complexities of how our systems work, that's what this is, right? This is not just technical components, but recognizing that people are part of the system.
We have endless tools to understand dependencies in products and technologies today, but people are the system. This is a broader system where impacts can cascade through the environment. We talk about feedback and iterative improvement and learning from our experiences and making small changes to improve systems and our practices.
We love collaboration in DevOps, the shared knowledge is the answer. It's been said, if you want to go fast, go alone. If you want to go far, go together.
We are nothing in DevOps if we don't work together as a team. Adaptability and continuous learning core principle, the bottom line stuff happens all the time. Our environments can be crazy.
You never know what's gonna come from the business tomorrow, and you don't always know what the system is going to do next. Sometimes we just gotta do what we gotta do to get things working, and that leads us to resilience through problem solving. Sometimes our problems require incredibly intense focus and commitment, but if it were easy, everybody would do it right?
And we do all these things through an ethos of ethics, community and sustainability. We emphasize doing the right thing, being honorable, caring for your team and having empathy. Those are the basics of DevOps principles we've all come to know and love.
So let's dive a little bit deeper. When we think about the essence of systems thinking, like I said, it's not just the technical dependencies. We recognize the intricate interconnection and relationships between the people, the process, and the technology.
In an organization. We emphasize viewing the software development and delivery pipeline as a holistic system rather than isolated components. Systems thinking encourages us to break down silos between development operations teams.
We foster collaboration and we treat them as integral parts of the same system with the same shared objectives. This approach promotes a culture of continuous improvement, where feedback loops and proactive problem solving becomes central to what we're doing. By embracing systems thinking, DevOps practitioners can optimize the flow of work, enhance communications, drive innovation, and ultimately lead to more efficient, resilient, and be customer centric and how we deliver our software and services.
Now, how can I connect that To fly fishing? We see the river as a system, water flow, fish behavior, insect cycles. Before we set out, we check the weather, we check the conditions, we understand what's going to happen.
We do everything we possibly can to understand how the wind might affect our cast or water clarity might uh, affect our fly selection. In DevOps, it's the same. We think about the system as a whole.
We're thinking about end-to-end deployment. We're understanding our ecosystem, and before we deploy our code or changes, we understand the impact of those changes and we select the right tools to monitor the alerts. The sociotechnical connection here is sound.
Both domains require this understanding of our complex systems and the intricate interplay of how the components work together. Feedback and iterative improvement are fundamental principles in the realm of DevOps. DevOps encourages a culture where feedback is not only welcomed but actively pursued and sought after.
After every stage of the software development lifecycle, this feedback can come from a variety of sources, automated testing, monitoring, and even our end users. By continuously gathering and analyzing feedback, DevOps teams can identify areas for enhancement to make incremental changes rather than waiting for major overhauls. The iterative approach ensurers that software and infrastructure are constantly evolving to meet our ever changing requirements and challenges.
Ultimately, small feedback driven in incremental improvements lead to more reliable, efficient, and customer centric solutions. We're aligning our DevOps practices with ever evolving demands in our digital world. Fly fishing back to my love.
We adjust our techniques based on what success we've had in the past. Steelhead are the fish of a thousand casts, and not every catch comes from a cast. Anglers need patience and willingness to try different techniques.
They must adapt. We learn. We learn from what we're doing on the water.
DevOps is all about continuous monitoring. We're testing and we're iterating. No deployment goes smoothly.
No, not every deployment goes smoothly. We face challenges, we work through them, we adjust. The socio tech technical connection here is clear.
We're we're emphasizing these relationships. Without the feedback, we can't improve the system. Now.
Collaboration and shared knowledge are pivotal elements of DevOps. DevOps bridges this, this traditionally distinct worlds of development operations and fosters a culture of collaboration between them. The more open that communication, the better.
This collaboration encourages developers and operations teams to work together seamlessly breaking down the silos and sharing their expertise. The sharing of knowledge and tools and best practices creates a collective intelligence within an organization, a context for learning. By pooling their insights and experiences, teams can solve more problems efficiently, proactively speeding up development cycles and enhancing system reliability.
In essence, collaboration and shared knowledge are the glue that bind DevOps teams together. We enable them to deliver high quality software efficiently and respond swiftly to the ever-changing demand. Fly phishing, we change constantly, and we do that based on collaboration with others.
We may not have Reddit for DevOps, but we have similar tools. We have forums, we have community groups, we have phishing clubs. We have means to share data amongst each other.
The fly tying world is full of collaboration, uh, in in our craft of tying flies and building our own tackle and building our own fishing rods. It's a craft that's been honed over many years. Fishing itself can feel like a solitary activity, but we share tips and we share data.
DevOps is the same. Not every deployment is smooth. We love our continuous monitoring and our iterative approach to collaboration drives us and it bridges our teams together.
How our tools and platforms work together fosters this culture of collaboration and is the sociotechnical connection. Now, adaptability and continuous learning. We mentioned also core tenets of DevOps and in the fast paced and ever evolving world of tech, DevOps teams have to remain agile and adaptable.
They're committed to embracing change, whether it's in the form of new tools, new methodologies, shifting business requirements, growing scale, continuous learning is a cornerstone of this adaptability. DevOps practitioners are dedicated to staying updated with the latest industry trends, technologies, and best practices. They understand that what works today may not work tomorrow, so they're continuously seeking opportunities to enhance their skills and knowledge.
This commitment to adaptability and learning ensures that DevOps teams are well equipped to respond to emerging challenges, innovate effectively, and deliver value to their organization. Now, on a river, we can go from the view on the left to the view on the right. In a matter of hours, change happens with or without you being ready for it.
We must be prepared. We must adapt, and your business is no different. We modify our strategies in fishing constantly based on that.
Sometimes we'll use a more colorful fly. Sometimes we'll use a lighter fly. Sometimes we'll use a sinking line to get down.
Anything we can do to incite that fish, to wanna strike our fly depends on the time of day. All things are continuously changed based on the conditions, and DevOps is the same. Based on that adaptability, we might change, uh, our environment.
We might scale up a system, we might scale down a system. We might delay a deployment, we might accelerate a deployment. Adaptability is our socio-technical connection here.
Resilience through problem solving is a crucial aspect of DevOps philosophy. DevOps teams recognize that failures and issues are inherent parts of complex IT systems, and those failures are not always technical. Sometimes they're human.
Instead of merely trying to avoid problems, we embrace them as opportunities for improvement. DevOps encourages a proactive approach to problem solving by establishing those feedback loops and using automation for early detection and resolution of issues. This resilience mindset involves learning from failure, documenting incidents, and constantly approving our processes to prevent similar things from happening in the future.
In doing so, DevOps not only ensures the robustness of our systems, but also fosters this culture of continuous learning and adaptability. We talked about ultimately enhancing an organization's ability to weather the challenges and deliver reliable high quality software and services. Overcoming challenges like unfavorable weather and elusive fish or equipment malfunctions.
Same thing on DevOps. Anticipating and mitigating quickly recovering from systems failures and bugs. Our socio-technical connection, we're building these robust systems, not just through technical measures, but by leveraging human creativity and problem solving.
Now, I think the most important pillar of DevOps these days, ethics, community, and sustainability. These are increasingly important considerations in the world of DevOps. DevOps practitioners are recognizing their ethical responsibility to build and deploy technology that not only is functional, but considers the broader societal and environmental impact.
DevOps communities are actively sharing knowledge and best practices related to ethical considerations, considerations around data privacy and security. And more importantly now, today, more than ever responsible AI deployment. Moreover, sustainability has emerged as a key concern and with a heavy focus on reducing the carbon footprint of our services and operations.
DevOps practices like automation and efficient resource utilization align with these sustainability goals by reducing waste and energy consumption, not to mention the positive financial incentives for your business. In essence, DevOps is evolving to encompass a holistic approach that incorporates ethics, community collaboration and sustainability principles. We're ensuring that technology development is not just efficient, but also socially responsible and environmentally conscious.
Now, in the fishing world, ethics are at the very forefront. We practice catch and release when we're fishing over stocks that may be, uh, at risk or or require greater management. We minimize the impact on the fish populations.
We minimize the impact on the watershed. We do this because we love this ecosystem and we want it to be there tomorrow for our children and our grandchildren. Sports people are the greatest contributors to conservation in the United States.
By an order of magnitude, we take care of our resources. DevOps people do the same thing. Ethical considerations in the development of our software and teams that respect their operational environment, we ensure minimal downtime.
That environment includes people. Rapid recovery from failure and sustainable work practices apply to our people. We care about the health and wellbeing of our team, our colleagues, and our coworkers.
If we deploy a system that we know is going to continuously wake people up at two in the morning, are we being ethical? And I would say no, we're not. The sociotechnical connection between fly fishing and DevOps is absolutely sound on this one.
The connection between ethics and phishing and ethics and DevOps could not be stronger. So why do I care about all this stuff? Well, for me, I'm the co-founder of a company called Open Context.
We're an auto discovered sociotechnical graph of the systems and software and infrastructure, and most importantly, the people in your tech stack. We're in early access right now, and we need feedback from people like you. We believe we're solving a hard problem, and we'd love to have you try it out.
com to wrap this up. Sociotechnical engineering is everywhere. It permeates so many different aspects of our lives, not just DevOps.
And I really hope this has been entertaining and I've really enjoyed some of sharing some of what I've learned along the way. Sign up for open context and most importantly, go fishing. Thank you.





