Jen Krieger used her first computer in the early 80s and maintained a strong interest in technology ever since. She started her career as a financial analyst and eventually moved into IT where she gained expertise in software development and releases. Jen has worked with many development methods, from waterfall to Agile.
Now, she's an Agile coach at Red Hat for the teams working on Project Atomic, Docker, and Kubernetes. This year, Jen is speaking at DevNation about what it means to be a DevOps engineer, and in this interview she tells us about the challenges of implementing DevOps, shares some advice for engineers, and more.
Tell us a bit about yourself, your background, and how you got involved in DevOps.
I met my first official computer in the early 80s when my dad brought home a brand new Compaq Portable from work. Since then, I have always had my hands in technology in some way. I dabbled in running websites for some folks in the comic book industry and taught myself a few programming languages, but realized I had an aptitude for math, so I became a financial analyst for a company in Miami.
It’s at that company that I blended my finance skills with technology and eventually moved over to their IT department. I learned the basics for developing and deploying software, experienced the reality of what it was like to slog through waterfall projects, and finally, the freedom that I was given through my experience with Agile.
Even though I am seriously grateful for those experiences, my conversations with others in the industry made me realize that something was lacking. The software was too tightly coupled, we had no automated testing, and it still took us way too long to release. Most importantly, we valued closed source software, so every time we looked at a tool to solve a problem, it was another gigantic software bill no one wanted to pay.
In 2012, I found myself taking a job with Red Hat to work in their IT department as an Agile portfolio manager. I did that for a bit of time and then jumped at the chance to be the product owner for a DevOps Enablement team. The team’s mission was to reduce the time it took the department to release software. That is where I bumped into all the software any tech nerd could want. However, most importantly, the moment I realized how fast deploying software with container technology could be—not because someone told me, but because someone showed me that it was possible—transformative.
I’m now an Agile Coach (aka Chief Cat Herder) for the Red Hat Project Atomic teams developing Atomic Host, Docker, Kubernetes, and lots of other software. The work is demanding, but I consider myself incredibly lucky to work with such a talented group of people.
What is DevOps all about?
Ask 10 people this question, and you are going to get 10 different answers. While it was an unending source of frustration for me in the first few months of trying to figure out what it all meant, I now realize why everyone has a different answer. Every IT working environment is going to be different based on the tools being used, the software and infrastructure being developed and supported, and the people who are responsible for those things. Anyone can look up the definition on Wikipedia and get the textbook version of what it means. What does DevOps mean to me? It’s pretty simple: if you are all getting paid by the same company, do your best to act like it.
Does the open source way play a role in DevOps?
Yes, and I wrote a whole blog post about this for Opensource.com. That’s a good starting place for cultural change in DevOps.
"The open source way isn’t an easy button for success. However, what it can do is provide a set of values for an individual and a group to follow that can set your organization on the path towards an effective DevOps community."
How much is culture and change part of DevOps?
To me, it’s 90% about cultural change, 10% about the technology. However, my perspective is shaped by my own experiences with software development and the conversations I have had over the past 15 years. Yes, absolutely, most of those conversations start with a technical problem. The one I reference a lot is a conversation I had with a friend who is an engineer at a closed source company. She was remarking that she wished she had even the possibility of using a continuous integration (CI) system like Jenkins at her workplace, but it would take forever to get it approved. But then she went on to remark that even if she did get it approved, she might aggravate her boss who told her that it wasn’t a priority, and she was concerned about the implications behind that. So it doesn’t matter what tools are on the market, or whether they are free or paid—if the overall culture of your company does not consider internal process improvement as a priority, then there is not a lot any tool is going to do for you.
What is the biggest challenge implementing DevOps at an organization?
People. I can’t say this enough—people are the best and worst part of the situation. They are your wild card, and you can sure bet it is going to be played at the worst possible moment.
What advice would you give to an engineer working in a DevOps environment?
Keep learning, keep being curious, keep questioning how things work. If you find yourself upset with the status quo, do something about it.
But most importantly, don’t ever expect someone to hand you what you want. If it needs to be done, you know it needs to be done, and it doesn’t look like anyone is going to do it? Find a way to influence those around you and get it done. Come hear more about how to do that at my Red Hat DevNation talk, "So you want to be a DevOps engineer?"
Will DevOps become the default in IT engineering?
Maybe. I think smart, forward-thinking companies are going to do their best to embrace the technology as rapidly as they can. But if it does become the default, it's going to take years—similar to the way Agile adoption trends have been. The crux is going to be whether larger enterprises will be able to address the technical and people debt that they have, while at the same time adjusting to the new way of delivering software. Eventually, I believe that the concepts fundamental to a good DevOps experience—rapidly integrating, testing and deploying software via automation; monitoring your environments for rich feedback loops, etc.—are going to be things talented engineers will desire to be successful. Just consider this—an engineer asks "what CI system are you using?" at an interview. They are using the answer to that question to evaluate where they want to work. That's the future of IT. I could argue that it's even happening now.
Any final thoughts to share?
Many of the engineers I’ve worked with in the past tell me that my secret power is always knowing the right person to talk to when they need to figure out what happens next. If you are going to be at Red Hat Summit and DevNation, find me, introduce yourself—I want to hear your stories.
Speaker Interview
This article is part of the Speaker Interview Series for DevNation 2015 an open source conference by and for developers from across the globe.
Comments are closed.