2019 DevOpsDays Boston Recap

This week we sent some of our team to DevOpsDays Boston. As usual, the real strength of the event were the talks about culture and the ways we work.

Read on to see what we’ll take with us from the event.

Apps, Stacks, and Frameworks: Avoiding “Shiny Object” Syndrome

When it comes to adopting new technology, there are usually some growing pains. So it’s important to ensure you know as much as possible before you get started and not to make the move unless it’s actually necessary. Angel Rivera shared a story about when his team decided to switch to MongoDB because they were frustrated trying to make their hierarchical data fit into their relational database.

Usually when I worry about “shiny things,” it’s a worry about moving to a new unknown technology for no reason. It’s typically not a good idea to chase the shiny thing when it won’t solve an actual technical problem. However, the developers had genuine problems with their old database system and it was slowing down their work. In that situation, it made sense to consider a new tool.

At first, using MongoDB was great! However, a few months later their customers added enough data that they started to take a performance hit. Angel advised that it’s important to vet new technology before adopting it to understand its benefits and potential pitfalls. Their migration may have gone better if the team understood the potential drawbacks of Mongo and monitored the system closely post-deploy to catch any problems early. Even though they were moving to a new tool for well-considered reasons, they still ran into trouble.

I really liked the above graphic from the talk. It captures the spirit of continual experimentation and learning. This is something we try to practice in our day-to-day work on the Conjur team. It is also one of the Three Ways of DevOps that Gene Kim defined in the DevOps Handbook.

Growing a Learning Organization

Continuing with the learning theme, Joel Tosi’s talk explored how you can make learning a core part of your team’s work life. He noted that, “To learn, it has to be safe to experiment,” and cited the Forgetting Curve to emphasize that for meaningful progress to be made, learning has to be ongoing.

Joel shared that practical experience is a core part of learning. Knowledge transfer isn’t like giving someone a cup of water (“Now you have knowledge!”). Real learning happens through personal experience. As a team leader or manager, it’s never about just giving someone the answer. It’s about helping your team develop the skills to find the answer for themselves.

Joel also discussed formalizing learning by creating dojos and if you’re interested in learning more, his slides are available here. Wrapping up the talk he said, “Everybody talks about hiring the best … why not just make your people better?”

Imposter Syndrome Ain’t Just a River in Egypt

Jesse Butler told the story of his life. From a young age, he played with computers and eventually he got a job at Sun Microsystems. Despite his increasing success, he still felt like he didn’t quite belong. He wondered when his coworkers would discover that he was a fraud. Eventually, he realized that he was experiencing imposter syndrome. In practice this meant that to him “success didn’t feel like success.” He insightfully noted that “imposter syndrome really manifests itself as shame”.

This reminded me of how Brene Brown defines shame:

“The intensely painful feeling or experience of believing that we are flawed and therefore unworthy of love and belonging… Shame creates feelings of fear, blame, and disconnection.”

Compare this to how imposter syndrome is defined:

“A psychological pattern in which an individual doubts their accomplishments and has a persistent internalized fear of being exposed as a ‘fraud’.”

When he starts to feel like an imposter, Jesse now tries to think, “If they hired you, let’s presume that they did that on purpose”. I also appreciated that he said, “Don’t be afraid to not know a thing”. Thinking this way helps you to learn more, because you are free to openly ask questions.

Security in DevOps

There were a couple of talks that touched on security that are worth mentioning.

Anand Tiwari’s “Automating Security in DevOps” workshop was full of tools and ideas for steps to take to improve your ability to write secure applications. In particular he talked about augmenting your CI/CD pipelines with static and dynamic analysis tools, using security plugins for your IDE, and leveraging asset monitoring and vulnerability analysis.

Quintessence Anx also gave a great talk that was particularly focused on securing your logs to prevent leaking sensitive data, an issue very close to our hearts at CyberArk. She had loads of concrete tips in her slides, which you can find on the web here. Read up on her recommendations!! They should be baseline practices for any developer.

Wrapping Up

We really enjoyed the event this year! We are grateful to the organizing committee for continuing to hold such an interesting conference.

Here are a few key takeaways from other talks that are worth mentioning:

  • The speech-to-text reporters were very impressive! They did an amazing job capturing the talk content.
  • We didn’t cover the talk that Taylor Anne Snook and JoAnn Becker gave in our recap (“Influence accessibility outcomes, no matter your role”) – but this one is worth watching once the video becomes available. It really emphasizes the importance of designing accessible websites. In addition, it includes valuable tips for how to improve the accessibility of your website.
  • We learned that kubectl get has a -watch flag! This is going to be really useful in our automated tests in Kubernetes environments. For more info, see the Kubectl documentation (where the flag functionality is defined as “after listing/getting the requested object, watch for changes”)
  • Suzan Mahboob gave an interesting talk on chaos engineering and shared a link to http://principlesofchaos.org/ for people interested in learning more. A key point of her talk was the importance of preparing your organization before starting a chaos engineering program. It’s good to be ready for the experimentation (and sometimes failures) that will ensue!

Did you attend? Do you want to talk about the event more? Join us on Discourse and let’s continue the conversation.