Fine-tuning DevOps for People over Perfection

Rate this content
Bookmark

Demand for DevOps has increased in recent years as more organizations adopt cloud native technologies. Complexity has also increased and a "zero to hero" mentality leaves many people chasing perfection and FOMO. This session focusses instead on why maybe we shouldn't adopt a technology practice and how sometimes teams can achieve the same results prioritizing people over ops automation & controls. Let's look at amounts of and fine-tuning everything as code, pull requests, DevSecOps, Monitoring and more to prioritize developer well-being over optimization perfection. It can be a valid decision to deploy less and sleep better. And finally we'll examine how manual practice and discipline can be the key to superb products and experiences.

This talk has been presented at DevOps.js Conf 2022, check out the latest edition of this JavaScript Conference.

FAQ

Julie is an engineer at Microsoft, part of the FastTrack for Azure program. She specializes in cloud architecture and DevOps automation.

Julie identifies key challenges in DevOps such as managing pull requests effectively, ensuring automated deployments are efficient, and dealing with security issues in code. She also emphasizes the difficulty of cultural transformation and team collaboration in remote working conditions.

Julie focuses on a practical and experience-based approach to DevOps, emphasizing that DevOps is a journey unique to each company and team, involving a focus on people and team dynamics over strict adherence to best practices.

Julie discusses the complexities of managing pull requests, including issues like slow merging processes, abandoned requests, and the necessity of automation to handle the workflow effectively.

Julie suggests that deployment frequency should match the readiness and comfort of the team. She mentions that starting with less frequent deployments, like every two weeks or monthly, is acceptable and can gradually increase as the team becomes more comfortable.

Julie argues that dealing with security vulnerabilities is about balance and understanding the practical impact of vulnerabilities on the application. She suggests that not all security alerts require immediate action, depending on the specific use case and threat scenario.

Julie believes in concise and relevant documentation, cautioning against over-documentation. She emphasizes the importance of documentation that is directly useful and manageable, avoiding excessively lengthy or detailed documents that may not be read or utilized effectively.

Julie Ng
Julie Ng
33 min
25 Mar, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

DevOps is a journey that varies for each company, and remote work makes transformation challenging. Pull requests can be frustrating and slow, but success stories like Mateo Colia's company show the benefits of deploying every day. Challenges with tools and vulnerabilities require careful consideration and prioritization. Investing in documentation and people is important for efficient workflows and team growth. Trust is more important than excessive control when deploying to production.

1. Introduction to DevOps

Short description:

Hi, my name is Julie. I'm here to talk to you today at DevOps JS about DevOps. I want to focus more on people as opposed to just theory and paper. This is my opinion based on my experience, not a complete guide. I'll use examples to illustrate my points.

Hi, my name is Julie. I'm here to talk to you today at DevOps JS about DevOps. And I want to do something a little bit different. I want to focus more on people as opposed to let's just say DevOps in theory and on paper.

So, before we get started, I have to just briefly show a disclaimer that I'm appearing here as myself and much of what I'm going to share with you today is my opinion based on my experience. So, it's also not a complete guide to DevOps for this talk and the time duration. I've decided to pick a couple of examples to kind of illustrate the points I want to make.

2. Experience and Approach to DevOps

Short description:

I've been building for the web for a long time, working at startups, corporate companies, and freelancing. Joined Alianz Germany, moved projects to the cloud. Learned a lot about DevOps at scale. Now an engineer at Microsoft, specializing in cloud architecture and DevOps automation. DevOps is a journey, different for each company. Remote work makes transformation challenging. Best practices are not mandatory. It's about people and success in delivering a product and growing a team.

So, I've been building for the web for a very long time. A bit older than I look, and I've worked at every place from startups to actually full like corporate. I was self-employed for a long time, so I actually was freelancing at various companies and that was my initial exposure to DevOps.

Then I joined Alianz Germany, which is a multibillion-dollar insurance company, and we moved some projects to the cloud in less than a year. It was a crazy ride, but I learned so much not just about DevOps, the skills, but really at scale. I already knew a lot of those practices and especially around Git and automated deployments, but transferring those across the team is a lot harder than it sounds.

Today, I am an engineer at Microsoft, part of the FastTrack for Azure program, where I help customers onboard to Azure. I specialize in cloud architecture and DevOps automation. We don't just help them with best practice guidance. If they run into a big problem or a challenge, we also help unblock them. Some of the content in here is going to be from those customer scenarios as well as internal Microsoft, kind of like my story, my experience, which is why this is my opinion, not a kind of like here's how you should do it.

The reason is because DevOps is a journey. Every company is going to be a little bit different. They're starting in different places. You always have different people with different preferences and just kind of like how they work. So it doesn't matter if you bring in somebody like me who's been doing it for a decade, it depends on the team, the company processes, and you have to kind of make all of this work together.

This is a little bit different from some of the talks I give. Part of it is that this is year two in COVID. Doing a lot of these things that have to do with transformation and cultural transformation is really hard when everything is remote. Sometimes you've never met your team. I've never met my team. So some of the things I'm going to talk about in terms of best practices actually become much more challenging when you don't have that face time to have that kind of nuance and it's like, okay, is she serious, or is she just being her snarky self? And then some of those rules, especially with security, how can I bend some of them and why? So we're going to look at that.

What I want you to get out of today is kind of a lot of these things that are best practices, even if I'm telling you they are, but you don't have to do them. You don't have to do them today. You don't have to do them next week. You have to eventually get there and also you can get there without following some of those best practices. So it's not about tools. It's going to be about people. And people are going to be the difference between success both in delivering a product and as well actually growing a team, investing in a team that will still be with you in a year or 10. So without further ado, let's get started.

QnA