I thought I would share an answer to one of the most common questions that I am asked as a cloud and container specialist. That is “How do I keep up?”. The answer is easy. You don’t. There is no keeping up. The rate and volume of information is both broad and deep and completely defies rational tracking unless…. unless you get specific and disciplined. Here is an example of what I do. My main focus is AWS and Google Cloud along with Ansible, Hashicorp, Kubernetes, Openshift, and Docker. That in a nutshell is a lot. But I follow a specific ritual almost daily or at least 3-4 times per week.
I skim through each section looking for items that I will mark for “read later”
Once I have skimmed to find the most relevant, I move to the Read Later section.
I then add to the board, Articles I want to Do, for those that I will get the most value out of right now for whatever projects I am working on.
Then I switch to Articles I want to do and I do them.
Once done, I switch them to Articles that were done.
I limit myself to one hour a day of this kind of learning so that I can keep up.
No knock against the presenter because I thought there were some salient points. In 2018, here is a point I would add… Kubernetes is still hard for everyone. Especially Operations who has to manage, eat, scale, log, troubleshoot, govern, deploy, monitor, configure, provision, and manage. Why are we talking about developers? One thing I hear is that KOPS, oh KOPS can help get a stable HA’ed autoscaling environment in AWS in minutes. Great. That only solves a portion of the problem. The easy stuff. How are we going to do all the things I just mentioned? Who is going to troubleshoot it when it is down? How will you track performance to SLA? I am not saying that there are not answers to the questions, but stop focusing on how K8s is hard for developers and figure out how to make it easier to operationalize. Delivery of Apps AND the environments they live in is key. That is why Dev, DevOps, and Operations exist.
Recently my thoughts have been wondering about challenging that which I “know” or the patterns that I “expect”. This was driven by a conversation at my relatively new job that started with “But this is how we have always done it….” I am a big fan of tradition as science seems to validate more and more that our grandparents had many things right. But.. But.. I think we need to re-evaluate our patterns and our process frequently to ensure that we are optimizing, experiementing, and diversifying. It works in nature. It works in finance. I can work in business. With people, it makes everything stronger more adaptable, and more resilient. To that end I think that Darwin would not emphasize survival of the fittest, but survival of the most diverse.
I hear this a lot.. if we only had this tool or this skill or this datastore or this program. The issue is that we like tooling because tooling is easy. We like buying technology because it is often consistent and automated and can solve issues that previously was done by people. The answer always centers around people. People who communicate what they need. People who pay you for solving problems. People who implement technology. People who have the answers and perspectives that you need (diversity). To that end, the answer is always the right kind of communication and the right kind of people. The technology is ancillary not primary.
Still talking about DevOps? Seriously. Stop. No one cares about DevOps. No one can even agree as to what it is. Is it cultural? Perhaps tooling is the key? Maybe it is a mindset? A communication style? Stop.
Here is what all businesses are looking for if they have software or a SaaS they want to deliver… They want to deliver their ideas faster, better, and cost-effectively at the minimum level necessary to meet the customers need. That’s it. So when you say… DevOps. What are you talking about?
For me, it has always been about anything that prevents the delivery of or enhances the delivery of software that is compliant, scalable, visible, and peformant. This could be one service or it could be a fleet of services. Who cares? To me that is what DevOps was always about. Enhancing or removing obstacles around delivery of product.
Become an Outcome Engineer
You know what was cool about the 2009 Velocity Conference…you know.. the one where they were talking about 10+ deploys a day? It was the actual reality of the outcome. 10+ number of deploys per day? Yes! My business want that. No one really cared about the cultural implications for that DevOps outcome until they realized that was a factor to get there. What they really wanted was Ricky Bobby syndrome, if you are not first then you are last.
“burn it all to go fast”
Become an outcome engineer. Focus on that outcome. Anything that you need to do that stays within moral and ethical boundaries to get that done… Do it. Anything else needs to be left behind.