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.