I was recently reviewing kubernetes.io and saw an old article from last year about this..
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.
The DevOps Conversation
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.