Understanding ITOps, DevOps, and NoOps

I’m trying to understand the difference between these three so that I can understand my customers better. It’s not obvious because everyone has a different opinion about where the lines fall between them – or even if there is a line. This is important because you can assume that customers in the different segments have difference needs for an observability solution. Here’s my best take on how they’re different and where those differences matter the most.

In traditional IT organizations, developers and systems administrators have opposing goals. Developers want to build features, innovating and creating new value for customers. On the other hand, System Administrators want to ensure that the deployed software will be reliable, performant, and secure, creating value for the business and customers. Because these two sets of people in an organization have different goals and don’t talk often, there is friction and software is released as smoothly as the business would like. When I think about these organizations that practice traditional IT, I think about my time at NetApp. When we identified a new application we wanted to build, we couldn’t just start writing code and deploying. First, we had a go through a lengthy process to get a VM from IT. They had to get information about how much storage, CPU, and memory was needed before provisioning the VM. Once we had it, we could deploy code to our 1 VM. This is solidly in the ITOps segment of the population. We could do some DevOpsy things to deploy code but we were always sitting on an ITOps framework for getting the necessary infrastructure.

Had we been practicing true DevOps at NetApp, we would have been able to deploy the infrastructure we needed – without asking a separate team. Other than the actual infrastructure being deployed through tickets, we did a lot of the other things necessary to claim DevOps. On DevOps teams, the team is responsible for the development, QA, deployment, infrastructure management, monitoring, and support of the application. The team may contain people with a role specific to one of those tasks or a team of generalists where anyone could manage any of the tasks. Either way, since the team is responsible for the operation of the application, they take on the new set of tasks. I’ve found that this causes the team to consider the impact of changes more and potentially be more careful. Nonetheless, DevOps teams can deploy faster and more dependably, helping to accomplish business objectives faster.

Finally, at some point, DevOps moves into NoOps – where automation and PaaS allows developers to deploy without the need to understand the infrastructure. The line between DevOps and NoOps is a bit murky to me but I think the main point is that the ‘Ops’ in NoOps has been minimized away so that it is trivial for the developer to execute. It’s worth pointing out that even in a NoOps practice, you would still expect some teams in the company to practice DevOps, as seen from Adrian Cockroft’s experience at Netflix. Those teams could be responsible for the platform or the automation that is making NoOps possible for the product developers.

I read a lot of content to try to understand this; here are a few links that I found especially helpful:

500 Word Summary: So Good They Can’t Ignore You

The Passion Hypothesis:
The key to occupational happiness is to find out what you’re passionate about and find a job that matches this passion.

I’ve talked to so many people who struggle to begin to fulfill the passion hypothesis because to start you have to be passionate about something. Most people are passionate about something but it’s usually more of a hobby, not something from which they can earn a living. It’s an incredibly common problem for young people in today’s world. I believe this is an excellent book for people struggling to find their passion.

In “So Good They Can’t Ignore You”, Cal Newport argues against ‘The Passion Hypothesis’ as the primary method by which people should plan their career. He instead proposes a alternative way to plan your career with the primary career goal being that you should love what you do. That proposal is made up of a few rules.

Rule #1: Don’t Follow Your Passion

Most people do not have a passion that defines the work they want to do or they have a passion that they can’t monetize. Passion often comes from working towards something for a long time and becoming excellent at it.

Rule #2: “Be so good they can’t ignore you”

This quote from Steve Martin captures what you need to do in order to build a career that you love. The key to finding work that you love is not to follow your passion but instead to get good at something rare and valuable. Cash in the career capital generated you gain from these skills for the traits that make work great.

Key to this rule is that you should begin with a focus on the value you can offer to the world, not the value that your job can offer you.

Rule #3: Consider saying no to maintain control

Control is one of the primary things that makes work enjoyable. When you have enough career capital to acquire more control, your employer is likely to do something to prevent you from gaining that control. Don’t fall into this trap and accept something (money) instead of gaining control. Also be careful not to acquire control without the appropriate career capital. Control gained this way is not sustainable.

Rule #4: Mission is important to creating work you love

Finally, after acquiring a lot of career capital, you can answer the question, “What should I do with my life?”. Missions are often found at the cutting-edge of a field. If you want a mission, try finding work on the cutting edge.

Mission driven projects are often tough. To make them easier, make little bets to answer questions about the project. Ensure that a project is remarkable enough that others want to talk about it. This is important if you want it to succeed.


I loved this book and the message that you don’t have to identify a passion first and act on it. It’s much better to work on your passion and let it change with you.


First Blog Post

So… First post…

This is weird because I know when I visit a blog I want to know what type of stuff I can read about on this particular blog. Well… I DON’T KNOW WHAT THIS BLOG WILL BE ABOUT OKAY! Maybe it will be funny. Possibly about technology stuff. Potentially I’ll just talk about board games. In reality, I’d be willing to bet people don’t really read the first post. I don’t think I’ve ever gone looking for the first post on a blog to see what the writer originally intended the blog to be. So I guess I can write whatever I want here and it won’t matter! 😀

I started this blog because I want a place where I can write about the things I’m doing. I primarily want to increase interest in things I’m doing at work and practice writing technical content. I also just want to share interesting things. Hopefully I can do all of that in one spot.


PS: I wonder if I can do one of those cool things were music plays when you visit this site… I’ll work on that. I know you’d appreciate it.