Kubernetes projects are organizational projects

Kubernetes projects are organizational projects

In the last couple of years, I spend most of my time with container-based technology, especially implementing Kubernetes, OpenShift, and microservices. But besides the technical implementation, I faced also in each project organizational issues. tl;dr None of these super cool and fancy technologies can bring fully their expected change and value for an organization if the organization doesn’t change either.

How Kubernetes change the game

Some technologies get adopted like nothing happen. Sure, virtualization was at its time a thing, promising like nowadays Kubernetes the perfect resource consumption so you will save some good money and speeding up the time to market. But hand on heart, I haven't met any company in the past ten years which was fast with provisioning you with a virtual server (and for many companies even the cloud doesn't help). And Kubernetes has some deeper impact on how we solve technical challenges today.

Now, Kubernetes and its universe of over 20 graduated/incubated and nearly 20 sandbox projects of open-source tools which it has in town (plus hundreds of other OSS, not under the CNCF umbrella) come into the game and change the way of how to build solutions. This is something no one should underestimate, but mostly it’s simply ignored.

With Kubernetes microservices getting a serious thing, at the same time it increases the complexity, you get additional tools securing your network, some others control your traffic and so on. Your applications need to be truly stateless to be able to scale as you dream of, also that GitOps can work effectively, otherwise if your application is too sensitive to its state you can suddenly (since 2016) build operators which are basically apps managing your apps. And these are just the current hot topics you see at each conference and meetup. With Kubernetes comes new concepts, the responsibilities for the classical roles drift into each other, the complexity reaches another dimension and there are so many details and aspects which we could discuss.

Kubernetes is the next cool thing on market, everyone does, shouldn't be that difficult, just do it, put your application on it and finish.

In the end, it is not that easy. You can use the new stuff as you used the old stuff in the past 20 years. In the best case, this will fail, in the worst case your costs increase, the complexity couldn't be handled and the solutions build are logically a disaster. One main reason for that is missing organizational changes. You also can call it processes or culture. I would refer it to the way individuals work with each other and their contemplated tasks.

The technology used to build solutions, your roles, organization, and processes interact strongly with each other. New fancy technology without a supporting organization and culture will just split this symbiosis and wanna make you cry.

Typical organizational behaviors

Maybe, while reading these lines, you will find yourself in the same situation. That's good because it means that you have the chance to change something. I observed a few typical behaviors of organizations when it comes to new technologies that prevent partly or fully the adoption of things like Kubernetes and is one of the main points why I see that Kubernetes projects are organizational projects:

  1. Dev & Ops no DevOps: Oh boy, everyone and every department are nowadays "DevOps". But are they? In over 80% of the cases, I met, clearly not! Besides the expectation that a system admin is also now a software engineer and vise versa, most organizations also reduce the whole topic to a technical thing called automation or CICD. I'm a huge fan of "you build it, you run it", but this is still not the same as most departments understand with what DevOps is.
  2. 100% automated, except…: In Germany, I see a really big fear of "losing control" which mostly correlates with "I don't understand what happens there". As Cloud Consultant I have one holy grail - automate everything. But I see many departments artificially breaking this automation, for the unrealistic reason of processes and quality control. The point is that automation follows processes, which nowadays can consist of nearly everything; quality checks, policy checks, vulnerability scans and so on. All of these can be automated, so with other words, there is not that much which can't be automated. But somehow CICD (continuous integration and continuous deployment/delivery are nowadays a more technical synonym for automation and how far it goes) is mostly implemented as "Continous interruption, continuous doubts".
  3. Don't fail: Another thing I see quite frequently is the old fashion implementation of 3, 5, 7 staging environments. It doesn't matter how many you have, the main reason for projects and organizations is to prove that you do not fail. This slowly changes, but to give it some more rocket boosts: fail often, fail fast, learn, get better, lose your fear to fail! Two stages are enough if you build qualitatively high solutions and are able to patch fast bugs.
  4. Life long learning until you hit your first job: My personal biggest pain is that corporations often tell about how much they do for their employees, but to give them enough room to learn is not an option. The world of IT is turning that fast that if you don't get time to extend your knowledge you will get lost within 2-3 years and therefore stuck in your competency. That’s for some people nice, but come on there is a life after COBOL and PHP.
  5. OPEX is bad: The most difficult discussions are with procurement and accounting departments. (Sorry guys!) They love CAPEX (capital expenses) and it is a horrible nightmare for them when you come with OPEX (operational expenses). With CAPEX you can do a lot of tricky money magic, while OPEX count here and now. The issue is that 7 out of 10 modern IT products and services are based on pay as you go. You use a service 10 min and you exactly pay for these ten minutes. You get access to a tool for 4 people for a month and don't need to pay a package for hundreds of users for a whole year and so on. I haven't yet found any killer argument for these discussions, have you?
  6. We are not allowed to!: With the growing amount of rules and laws (especially in Germany/Europe), it is getting more and more difficult to get clear answers where you can bring which data. I met so often people who want to use "new" technology (which is mostly 5-10years around like cloud), but most of them are afraid of using it because no one ever checks it from a law perspective. We need here more corporations and lawyers who are brave enough to sit down on this topic, leading the difficult discussions and grow an understanding of it.

What to change?

To make Kubernetes projects successful and not fail because of organizational nonsense (except you have already the right mindset and team) there are two ways which at least will bring the frame to make tech projects successful and to come to a Happy End.

First: You go the long way. You need to change everything and everyone, your managers, your finance people, the tech teams and yourself. Things take years to adapt. As said, you make your Kubernetes project to an organizational project. The main issue with that will be that the majority part of your organization doesn’t need necessarily to change as they drive their apps and systems like before.

Second: Drive your project by exclusion. Start the project in a unicorn environment, set once clear rules on how everything works at the boundaries of the project, treat it like a startup and let it do what it does. Sure you still need to talk with the rest of the organization but the contact points getting manageable. And this means, on the other hand, you get more free space to focus on the project itself and the changes within the team. This will pay off, the better your team gets, the smoother everything runs and the closer you come to technical excellence the more you will influence everything around. You naturally will push the wheel to make changes happen, without forcing them.

However, empower the change! Not just new tools or a fancy approach for doing projects. Get the right people with the right disruptive mindset, allow them to step up and protect them from getting burned in your corporate machinery. Think big, think from one end to the other and what all needs to be changed.

For sure these are not 100% solutions, every situation is individual and that’s good! And yes this all can fit to other trending technologies. But many of these hot topics I would see more on a product site. Kubernetes, on the other hand, is the underlying infrastructure already now and more and more in the future, changing the way of how we design, build and operate all apps/products/services. It is the fundament of this change.

Conclusion

Kubernetes opens a new door with chances, opportunities but also with conflictual situations. These in my point of view relies in the end in a socio-technical problem. Corporations have grown over decades their way of working, their structure and personal identity. In this as well as in the current business economics theory IT is just a supporting process adapting corporate structures. In my opinion, it is the view of blindfold people and doesn’t reflect the impact of IT and digital products nowadays correctly. This loops back to the point of socio-technical problems, because now the technical part in it takes the driver seat and pushing for organizational changes to make it fit for the new technical requirements and way of thinking. Keep changing! Get inspired by technology!

Posted on LinkedIn

Photo by Nicola Ricca on Unsplash

Show Comments