Turning DevOps Inside

Talks

Darren Broemmer

Turning DevOps Inside

by Darren Broemmer

In the video "Turning DevOps Inside", Darren Broemmer discusses a fresh perspective on DevOps, emphasizing its true value lies in understanding customer interactions and integrating that feedback into the development lifecycle. He challenges the conventional understanding that focuses solely on automation and deployment scripts and advocates for a balance between internal software development and external customer experience. This approach enhances feature velocity and overall efficiency.

Key Points:

Shift in Focus: Broemmer asserts that the core of DevOps should be customer-driven insights rather than just automation and deployment. Understanding how customers interact with applications is essential for rapid feature deployment.
Collaboration Between Development and Operations: DevOps necessitates close collaboration between development and operations teams (often the same individuals) to leverage customer feedback effectively.
Metrics and Feedback: Regularly reviewing metrics, ticket queues, and customer behavior can unveil valuable insights into product usability, allowing teams to identify issues and areas for improvement.
Separation of Concerns: The video emphasizes the importance of designing software with flexibility in mind, facilitating easier changes and adaptations based on customer feedback. Broemmer highlights that every design choice should consider the implications for future development.
Tools and Technologies: Specific Rails strategies and gems like Ahoy and Blazer are recommended for monitoring customer behavior and usage patterns, helping developers gain insights into application performance and user interactions.
Incremental Changes: Broemmer discusses transitioning from a monolithic architecture to microservices incrementally, enabling teams to deploy services independently which reduces the risk and impact of bugs during updates.
Proactive Monitoring: It’s vital to shift from reactive bug fixing to proactive monitoring to detect trends in application performance issues, ensuring teams address potential problems before they escalate.
Continuous Feedback Loop: Establishing a feedback loop between operations and development is crucial for enhancing features based on real user feedback, ultimately driving product evolution and improving customer satisfaction.

Conclusion:

Broemmer concludes that embracing a customer-centric approach in DevOps practices increases the velocity of feature adaptations while simultaneously improving the overall product experience. He encourages developers to integrate these strategies for enhanced operational and developmental synergy crucial for success in today’s digital economy.

The talk is framed around maintaining a balance between technology and customer insight, underscoring that genuine value derives from understanding and reacting to customer needs in software development.

00:00:07.519 Hi, my name is Darren, and today I want to talk to you about DevOps. However, I probably won't discuss it in the way you're thinking. I'm going to assert that we've been looking at it the wrong way; more accurately, our focus has not always been in the right place. There are some high-value activities and outputs that come from this, which are centered around the customer, and I believe we can use those to release new features faster.

00:00:21.720 Before we dive into that, let me introduce myself. I'm actually a long-time Java developer. About seven years ago, when I started working at Amazon Web Services, I was introduced to Ruby and Rails, and I have never looked back since. I was hooked! The Ruby community is welcoming, and I feel fortunate that in my current role, I get to work with Ruby and Rails, talk about it, write about it, and share that knowledge with all of you. At some point in my journey, I realized that when I wrote code to perform random tasks—such as cranking through data or running some analysis scripts—I was doing it in Ruby, not in another language. It just clicked, like learning how to ride a bicycle or swim.

00:01:02.780 Suddenly, Ruby became my go-to language, and I have never deviated from it. As in any technology, you apply what you know to solve the problem at hand. While you won't find Ruby at the bottom of the public cloud stack per se, it certainly has its flexibility. Ruby can be used for a myriad of purposes, such as building web applications, testing, configuration management, and Ops tooling—topics we'll explore later.

00:01:51.180 Let's rewind back to when I took on the job at AWS seven years ago. I was joining the EC2 group specifically to work on the VPC, which stands for Virtual Private Cloud. I thought I was being smart by preparing in advance to impress everyone on day one, so I bought a book on software-defined networking. It's a very good book; I recommend it. I also contacted my hiring manager, Mahmoud, who was a fantastic manager at AWS. I asked him how I could prepare for my new role, hoping to align myself appropriately. His advice was surprising: 'Darren, use AWS. Use VPC as a customer. Learn it. Understand what you like about it and what you don’t. Know when to use a private link versus VPC peering. Why do both exist?'

00:02:36.840 I had been focused internally, thinking about how I could gain a skill that I could apply from a technological standpoint, while he was urging me to look externally at how a customer perceives a product or service. This theme will recur throughout our discussion today. By viewing software products and services from an external perspective, we can gain valuable insights that significantly benefit development and operations.

00:03:04.200 We must balance internal concerns—like building and deploying our software—with external concerns—such as how customers utilize our software, their experience, and what works or doesn't. To me, the true value of DevOps lies in integrating these two aspects, allowing us to gain insights we wouldn’t otherwise encounter. These insights are not easily obtained through reading a book or taking a training class, primarily because they are unique to your specific service, its characteristics, and how customers interact with it.

00:03:51.960 So, what is DevOps? What truly serves as the glue that binds these elements together? Many of you already know that it encompasses a variety of factors. DevOps is about facilitating collaboration between development activities and production or maintenance, which historically were often handled by different teams. Today, it’s more common for the same individuals to manage both aspects, and I strongly advocate that this unified approach yields the best insights into customer usage of your service.

00:04:34.320 Additionally, DevOps includes processes, automation, and various tools. While all these are essential components, the key question to ask is: what value do they contribute? In today's landscape, you want to be relentlessly focused on your customer, innovating quickly, adding new features and functionalities, and addressing any issues as they arise. Before the pandemic, we were gravitating toward this goal, but now we find ourselves nearly completely immersed in a digital economy. Everything happens rapidly; competitors can replicate your business model pretty quickly. If you linger complacently for too long, you may find yourself left behind. DevOps can facilitate quicker responses.

00:05:03.600 When we focus our attention on the 'operations' segment, it often becomes synonymous with deployments and CI/CD (Continuous Integration/Continuous Deployment). While those are indeed valuable strategies that save time and effort, the primary focus should remain on operational fine-tuning—learning how customers interact with your service and improving upon that. By analyzing metrics, we can uncover the alarm triggers and identify patterns: when problems emerge and when the system performs optimally. You can derive significant insights into your service simply by examining the ticket queue—what inquiries are being made? What issues are customers encountering and expressing confusion about? Knowing what they believed they would be able to do, only to find things don't work as expected, represents an opportunity to mitigate friction and better the experience for our customers.

00:06:18.780 Engineers often lack this exposure; many colleagues I've worked with would love more direct interaction with customers, or even the product managers who act as a proxy for the customer. Easily, it's possible to remain entrenched within an internal bubble, where coding occurs with Ruby and Rails. However, we want to extend that bubble to encompass not just the development of our applications but also how we operate them and deliver them to our customers, as this is where the real excitement lies. This principle applies to web applications targeting end-user customers. If I’m selling books online or developing tools and frameworks, it's crucial to recognize that different customers have different expectations. Some of your customers may even be other developers.

00:07:09.060 At AWS, for instance, many of the customers were internal services—other AWS offerings. Therefore, it’s important to consider: who is your customer? Sometimes this isn't always straightforward, but it's worth reflecting on. How does this perspective affect our development and operations? Typically, we find ourselves doing two things: fixing problems as they arise and adding new features or capabilities for our customers. To position ourselves effectively for these tasks, we must design our software from the ground up. The primary reason we undertake design is not merely to create visually appealing architectural diagrams or aesthetically pleasing code. These may be great side effects for those of us who appreciate the craft, but ultimately, we design because change is often unavoidable, and we want to implement those changes as quickly, cleanly, and safely as possible.